Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[LRM-2012][lang-compliance][feature-request] Operator overloading #1221

Open
likeamahoney opened this issue Jan 21, 2025 · 3 comments
Open

Comments

@likeamahoney
Copy link
Contributor

likeamahoney commented Jan 21, 2025

Hi, all!

Operator overloading was introduced at SystemVerilog LRM 2012 (section 11.11) and was deprecated by LRM 2017 due to the fact that no one supported this feature in the tools and, accordingly, did not use it.

But it seems to me that this feature is quite convenient for building testbenches that widely use unpacked structures, slang is powerful enough to support it, but not by default, but with some option, like --deprecated-legacy. Is support for this considered or is this not needed in slang?

@likeamahoney likeamahoney changed the title [LRM-2012][lang-compliance] Operator overloading [LRM-2012][lang-compliance]] Operator overloading Jan 21, 2025
@likeamahoney likeamahoney changed the title [LRM-2012][lang-compliance]] Operator overloading [LRM-2012][lang-compliance][feature-request] Operator overloading Jan 21, 2025
@MikePopoloski
Copy link
Owner

As far as I know no other tool ever implemented this. Sure, slang could add support, but who would ever write code using it if they couldn't simulate it or synthesize it or whatever?

@likeamahoney
Copy link
Contributor Author

likeamahoney commented Jan 22, 2025

As far as I know no other tool ever implemented this. Sure, slang could add support, but who would ever write code using it if they couldn't simulate it or synthesize it or whatever?

slang (as possible fronted for other tools) could optionally inline bodies by substituting the function body for the overloaded operator, this would make the overloading implicit for tools (the tools would not even know about its presence), thus automatic support for other tools would be provided

@MikePopoloski
Copy link
Owner

Hmm, I see. I suppose that makes sense, though I think such a project is a fair amount of work and I kind of doubt anyone would ever really use it in practice.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants