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

Inferred Set parameter type #197

Open
AnthonyDGreen opened this issue Nov 1, 2017 · 3 comments
Open

Inferred Set parameter type #197

AnthonyDGreen opened this issue Nov 1, 2017 · 3 comments

Comments

@AnthonyDGreen
Copy link
Contributor

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:

Property P As T
    Get
    End Get
    Set(value) ' Error, 'value' parameter must have the same type as property.
    End Set
End Property

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:

Property P As T
    Get
        Return _P
    End Get
    Set ' Legal today.
        _P = Value
    End Set
End Property

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.

@reduckted
Copy link
Contributor

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.

This part gets my vote.

@AnthonyDGreen
Copy link
Contributor Author

AnthonyDGreen commented Dec 7, 2017

Update: The 11/15/2017 LDM thought this idea was reasonable; it's just removing an unnecessary error.

@bandleader
Copy link

bandleader commented Feb 15, 2018

It is reasonable especially because it is consistent with argument type inference for lambdas:

Dim stringArray As String() = {"One", "Two"}
Dim lowerStrings = 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).

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

3 participants