-
Notifications
You must be signed in to change notification settings - Fork 4k
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
Overloaded operators need to be smarter #49095
Comments
Because the language isn't spec'ed to do taht. If you want it to do that, please file a suggestion over at dotnet/vblang. This has been mentioned to you in the past. Please do not ask the compiler to deviate from the language spec. |
You are welcome to raise an issue/proposal on vblang asking for this. Roslyn is not the place for this. |
The language specification requires it. If you want that changed, you need to file a language change request. In the meantime, the IDE can help you by generating tihs all on your behalf. Source generators will likely help here in the future as well. |
@CyrusNajmabadi What I am descrying here is an ancient VB behavior that can't be prevented by any specifications what ever! If fact, C# does it right: class Foo
{
int value = 0;
public static implicit operator int(Foo f) => f.value;
} static void Main(string[] args)
{
var f = new Foo();
var x = f + 1;
} So, since when the strictly famous C# does conversions that VB prevents by specifications? Class Foo
Dim Value As Integer = 0
Public Shared Widening Operator CType(f As Foo) As Integer
Return f.Value
End Operator
End Class
Sub main()
Dim f As New Foo
Dim x = f + 1 ' Error
End Sub Definitely this is a bug in the operator resolution in Roslyn, as it for some reason fails to see the |
@VBAndCs I'm not getting pulled into another discussion with you where you ignore what is said. I have told you how to properly proceed here. Language change requests go through vblang. |
from https://docs.microsoft.com/en-us/dotnet/visual-basic/reference/language-specification/expressions
Note that the Now this is the second rule in resolutin rules:
So, the source of this bug (that clarely violates the specs) is :
|
So, to @CyrusNajmabadi 's point, at a minimum you're asking for a specification clarification. The spec may be wrong, or the spec might say what you think it says and intend to do so. But before any action can be taken on the implementation side the intent of the spec should be clarified, so we should discuss it in vblang. I could write some long pontification about the philosophy of conversions and why I think this particular pattern of behaviors is not allowed, but the place for that missive to live is on vblang and not buried here amongst clearer yes/no product defects. Traditionally, if this question were raised internally (in either language) it would be sent to the LDM first to make a determination before it would be actionable. As for you points about the required operator pairings that is definitely a vblang suggestion and should be filed there and separately from the question about using widening conversion operators in this way. |
@AnthonyDGreen |
I have a project to auto-generate a class that can be used as a flag with many methods to support flag operations. The flag is exactly a wrapper around Integer, which is saved internally in a
Value
field. I added a widening and Narowing Ctype operators to go back and forth between my Flag classes and Integer:I supposed this will be enough, but VB refused to do any arithmetic or logical operation involving Flag and Integer!
Dim x = MyFlag.X + 1
My first question:
Why can't VB convert the Integer operand to the flag type, or convert the flag operand to Integer?
Note that when I added the
+
operator, I could use it to add a Byte to the Flag. VB casts Byte to integer so it can use the operator. So, whey can't it cast the flag to Integer to use theInteger.+
?Note that this is also not working:
Dim x = 1 + MyFlag.X
It has nothing to do with the order of the operands.
Secondly: Why can't I mark the Value field with some attribute say
<UnderlyingType>
pr mark the class itself< UnderlyingType(GetType(Integer), "Value">
, so that VB use this filed in all operation (treating them all as immutable operators), or at least use the given CType operators to substitute Integer with the Type or vice versa?And finally:
Why do I had to override unnecessary operator?
=
doesn't need<>
>
doesn’t need<
and if the class has
=
and<
, it doesn’t also need<=
nor>=
!So, why we are wasting our lives writing all that?
In current language design, I had to add all this non-sense code:
The text was updated successfully, but these errors were encountered: