Solidity: Feature Request: Remove semicolon obligation like JS does

[Jorropo]

Abstract

Simply allow user to chose to use semicolon like js does.

Motivation

I was formed to programation with python so for me using () and {} for loops is an heresy but I understand why people like that and I think it add somethings to the style so I want not remove it evrywhere.

But: ;

This is just useless except if you would do inline code.
A code without isn't less clear (its even more for me).
But that need you to think about somethings useless and makes you less productive.
So I think like javascript we should stop forcing user to use ; at end of line.

Specification

Code should be writable in multiple way (these 3 contract should also produce the same bytecodes except the name):

pragma solidity >=0.6.0

contract WithSemicolon {

  struct thisIsUselessButNeededForExample {
    string hey;
    bytes[16] iDoNotKnowWhatToWriteHere;
  }

  mapping(
    address =>
    mapping(uint256 => string)
  ) db;

  function (uint256 id, string data) {
    db[id] = data;
  }
}


contract WithoutSemicolon {

  struct thisIsUselessButNeededForExample {
    string hey
    bytes[16] iDoNotKnowWhatToWriteHere
  }

  mapping(
    address =>
    mapping(uint256 => string)
  ) db

  function (uint256 id, string data) {
    db[id] = data
  }
}


contract MixedSemicolon {

  struct thisIsUselessButNeededForExample {
    string hey;bytes[16] iDoNotKnowWhatToWriteHere
  }

  mapping(
    address =>
    mapping(uint256 => string)
  ) db;

  function (uint256 id, string data) {
    db[id] = data
  }
}

Backwards Compatibility

Nothing to do here, we just add more choice to the user.

[chriseth]

The semicolon has several advantages: It provides better clarity about where a statement ends and where the next starts. Furthermore, it allows a recovering parser to get into a clear state more easily.

Example:

contract C {
  function (uint) a function b() returns (uint) { return a }
}

Furthermore, I would not so easily assume that just because removing semicolons in JS does not generate too many ambiguities (there is actually at least one where it makes a difference to put a semicolon or not) this is the same in a typed language like Solidity which has a rather different syntax.

[Jorropo]

@chriseth I'm not saying totaly removing semicolon, I'm saying depending of the context considering \n as a semicolon (I think your example shouldn't compile).

[chriseth]

For JavaScript, it does not matter which whitespace you use, as far as I know. Also, having a rule that \n can but does not have to terminate a statement is also rather dangerous, I would say.

[Jorropo]

console.log() console.log()

```
SyntaxError: unexpected token: identifier

This is dangerous ?
If that for storage I'm in fact quite okay with that, and I will continue to use semicolon in storage, but for instruction I don't see why this is dangerous ?
If your instruction is complete it shouldn't makes a problem.
So yes with what I propose this will not be possible any more:
```solidity
return a
  , b

but who does that ?
if you would pass multiple value in multi line you do:

return a,
  b

[chriseth]

Ok right, I confused something there a out newlines and whitespace. I read up a little more on automatic semicolon insertion, and I am more convinced that we do not want to go down that road :)
The thing is, already in javascript there are certain confusing cases and it probably takes a while to find all of them. I believe that in Solidity there are even more such cases and people already try to find ways to make Solidity code confusing.

I'm not saying that this is an impossibility, but such a proposal certainly needs to be way more grounded on what actually has to change, how, where ambiguities are hidden and it also needs more support from the community. We certainly don't want that kind of war between semicolon haters and lovers as there is/was in the JavaScript world.

[Jorropo]

We certainly don't want that kind of war between semicolon haters and lovers

I'm sorry if I have been a bit to rude, and at this point you are totaly right.

but such a proposal certainly needs to be way more grounded

Okay, I'll try to understand how solidity have been made to try to do a beta, (I'll probably finish to write a python or go parser and do that here because my C experience is near 0).

[chriseth]

Closing as having a too large cost/benefit ratio.