dotnet / dotnet/vblang

Suggestion: Allow a statement after a method declaration (Remove BC30040)

Open
#477 25 comments 7 reactions 0 assignees View on GitHub
Dominant language
No language data
Stars
328
Forks
71
PR merge metrics
No merged PRs in 30d

Description

Currently, this is valid:
```vb
Sub WriteFoo()
Console.WriteLine("foo")
End Sub
```
and this is valid:
```vb
Sub WriteFoo()
Console.WriteLine("foo") : End Sub
```
but this is an error:
```vb
Sub WriteFoo() : Console.WriteLine("foo") : End Sub
```
If a method only has one short line of code in its body, why not make it possible to shorten
the whole method to one line?

More often I notice this, though, with properties, where there is validating code in the ```Set``` accessor, meaning I cannot use an autoproperty, but I still need to use 2-3 lines of code for the ```Get``` accessor, because while this is valid:
```vb
Property Bar As Integer
Get
Return _Bar
End Get
Set
If Value < 0 Then Throw New Exception
_Bar = Value
End Set
End Property
```
and this is valid:
```vb
Property Bar As Integer
Get
Return _Bar : End Get
Set
If Value < 0 Then Throw New Exception
_Bar = Value
End Set
End Property
```
this is an error:
```vb
Property Bar As Integer
Get : Return _Bar : End Get
Set
If Value < 0 Then Throw New Exception
_Bar = Value
End Set
End Property
```

```Sub``` and ```Function``` declarations can be long, so I can see a side-scroll reduction benefit to disallowing statements after them, but requiring ```Get```, which can only be that one word, to be on a line by itself seems a bit much.

If expression-bodied members (#61) don't make the cut for VB, this seems like a reasonable compromise.

Are there any specific reasons for the current behavior? Is it required to make parsing work correctly (or is it an artifact of making parsing work correctly pre-Roslyn), or is there a language-design rationale for it?

Contributor guide

No contributing guide indexed for this repository

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.