You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
There's a lot of redundancy in VB expanded property declarations today. If I consider the backing field I need to specify the type three times. I propose that this broken code today:
PropertyPAsTGetEndGetSet(value)' Error, 'value' parameter must have the same type as property.EndSetEndProperty
Now be compiled to infer the type of the value parameter to match the type of the containing property. Combined with #196 this proposal would eliminate the need to refer to the property type three times (and the name twice).
Technically this sorta works today, if you omit the parameter list of the Set entirely, the compiler implicitly defines a parameter named Value (uppercase! blasphemy) of the property type, very similar to how C# properties work:
We could just stop spitting the parameter list on the setter entirely and start coloring the identifier blue and get all the value of this feature. The only thing we'd lose is the explicitness and it might be less discoverable to a first-time user/reader that the parameter exists and has the name Value but I think I lost the ability to make that argument when I proposed #196. Someone else is free to make it, though.
The text was updated successfully, but these errors were encountered:
I don't see the point in allowing this. There's already two ways that you can define a setter (with an argument list and without an argument list). This would make three. And would this same syntax extend to event accessors (AddHandler, RemoveHandler and RaiseEvent)?
We could just stop spitting the parameter list on the setter entirely and start coloring the identifier blue and get all the value of this feature.
It is reasonable especially because it is consistent with argument type inference for lambdas:
DimstringArrayAsString()={"One","Two"}DimlowerStrings=stringArray.Select(Function(str)str.ToLower())'In the above line, argument 'str' is correctly inferred as a String, 'because .Select() expects a Func(Of String, String).
There's a lot of redundancy in VB expanded property declarations today. If I consider the backing field I need to specify the type three times. I propose that this broken code today:
Now be compiled to infer the type of the
value
parameter to match the type of the containing property. Combined with #196 this proposal would eliminate the need to refer to the property type three times (and the name twice).Technically this sorta works today, if you omit the parameter list of the
Set
entirely, the compiler implicitly defines a parameter namedValue
(uppercase! blasphemy) of the property type, very similar to how C# properties work:We could just stop spitting the parameter list on the setter entirely and start coloring the identifier blue and get all the value of this feature. The only thing we'd lose is the explicitness and it might be less discoverable to a first-time user/reader that the parameter exists and has the name
Value
but I think I lost the ability to make that argument when I proposed #196. Someone else is free to make it, though.The text was updated successfully, but these errors were encountered: