dotnet / vblang

The home for design of the Visual Basic .NET programming language and runtime library.
289 stars 65 forks source link

[Proposal] Using [] for indexes, ranges, and limiting type ranges #556

Open VBAndCs opened 4 years ago

VBAndCs commented 4 years ago

Dealing with Small Basic, I became a fan of using [] for indexing collections (a[0]), and I want this to be optional in VB.NET besides () (a(0)). This will allow us also to use ranges: Dim a = [1 To 5] ' a = {1, 2, 3, 4, 5} If x in [1 To 5] Then' Which is optimized to: If x >= 1 AndAlso x <= 5 Then' And even restrict value types range

Dim x as Integer[100 To 1000]`
x = 1001 ' Exception

Which will be lowered to

Dim x as Integer
Sub Set_[LOCALID]_x(value as integer, )
   If 1001 >= 100 AndAlso 1001 <= 1000) Then 
       x = 1001
   else
      Throw New OutOfRangeException()
   EndIf
End Sub

Any assignment to x will be replaced with such checks. If x is paced byref, then we will pass a temp var instead, then do the same check before assigning the temp val to x.

We can do the same for function params, and property setters.

pricerc commented 4 years ago

I used to think it strange that VB doesn't have a discrete 'index' syntax (like C#'s []).

But then I realised that in a high level language, an 'index' is just a 'parameter', and the implementation should be a detail that is irrelevant to the caller. It should not be necessary for me to know that I'm working with an index and not just a parameter. Having a common syntax for both also allows for an implementation to change between the two without require source code changes for callers.

Your example, however is more about dealing with a small set. And I'm pretty sure there was a previously a proposal similar to that.

And then I also can't immediately think of a reason why parentheses or braces wouldn't work as well:

Dim a = (1 To 5) ' a = {1, 2, 3, 4, 5}
If x in (1 To 5)

or

Dim a = {1 To 5} ' a = {1, 2, 3, 4, 5}
If x in {1 To 5}

In fact, braces would be more consistent with the mathematical notation for sets (Sets @ wikipedia), and thus be more consistent with BASIC, which had its foundation in mathematics. Using that argument, this might be a better syntax:

Dim a = {1 ... 5} ' a = {1, 2, 3, 4, 5}
If x in {1 ... 5}

or, ideally, but probably trickier to implement: {1, 2, 3, ..., 100}

VBAndCs commented 4 years ago

VB is anti symbolic syntax, so, I definitely against {1 ... 5} and with using To instead regardless of the surrounding symbol. I mentioned Small Basic, as it is the only hope left to get a new generation of VB programmers, so, they will come with the [] indexing taste, and we should embrace that. Besides, there is already confusions when we deal with default index of an array resulting from a method call: as Foo(0) can be Foo()(0) or Foo(0) where Foo has 2 overloads, one without params! So, I thank SB team to enforce this correction, and hope we embrace the upcoming new generation of VB programmers before they sucked into C# sinkhole!

CyrusNajmabadi commented 3 years ago

I personally think VB's way of doing things here is far superior to C# and VB should not be trying to copy C# here.

zspitz commented 3 years ago

But then I realised that in a high level language, an 'index' is just a 'parameter', and the implementation should be a detail that is irrelevant to the caller. It should not be necessary for me to know that I'm working with an index and not just a parameter. Having a common syntax for both also allows for an implementation to change between the two without require source code changes for callers.

I think there is merit in distinguishing the specific case of "give me the item within the collection which corresponds to this value" from the general case of "method which uses the passed in values to modify the object state and/or returns some calculated value relative to the object". It's true that any method could be written as an indexer, while any indexer could be written as a method; but having an indexer outside of this narrow specific case is a misuse of indexers.

Much like properties as opposed to Get/Set methods.

That said, I understand this is quite unlikely to change.