I hear you — especially this:

> Some statement may not end in semicolons according to x,y,z rules

I did not consider that this may be extra mental overhead when reading difficult code. You may be right about that.

The other points, though, I disagree with in that I don’t see this as being particularly profound. The language allows the programmer to elide a lot of other syntax (such as `this`, lambda return types, destructors and assignment and move constructors [when the language could have made the programmer specify =default], single-line loop scopes, etc).

I do not necessarily see how this is much of a sea-change. If the interest is there, which it does not appear to be, I would have played around with a libclang implementation to see how feasible it is.

WL

> On Apr 28, 2022, at 2:10 PM, Marios Staikopoulos <marios_at_[hidden]> wrote:
>
> 1. This feature would not be mandatory on the programmer
>>
> Yes, but it will be mandatory to know if you are compiling/linking some third-party project/library. It's going to be another compiler flag in a sea of already disastrous incompatibility.
>
> 2. This may be helpful to the ease of development
>>
> You are going from a state of: "Every statement must end in a semicolon" to "Some statement may not end in semicolons according to x,y,z rules". I do not see how that could make anything easier.
>
> 3. I’m going out on a limb here, but I think many of us can agree that the semicolon is often “mentally elided” when reading C++
>>
> It can be in some cases, but there are times where the precision of the semicolon really matters - macros, templates, etc.
>
> Also consider that C++ gives the programmer plenty of ways to be expressive already [1]. This is in-line with the programmer’s ability to be expressive.
>>
> These are completely different beasts - one is consistent style wise with requiring some form parenthesis (except maybe the inline assembly one) via being a function or via operator(); which is also a function.
>
> Also, all these still must adhere to the c++ grammar guidelines. However, your proposal completely changes c++ from a semicolon based statement language to a potentially(?) whitespace sensitive language or even worse in my opinion, a mixture of both. Whitespace languages while pretty to look at, have always been much harder to edit due to tab/spaces issues (I'm looking at you python), but tab/spaces is probably not the issue here - whitespace sensitivity is.
>
> I just don't see this going anywhere, I don't think any of the 5 major compilers would want to implement this at all (especially with legacy).
>
> -----Original Message-----
> From: Std-Discussion <std-discussion-bounces_at_[hidden]> On Behalf Of William Linkmeyer via Std-Discussion
> Sent: Thursday, April 28, 2022 10:54 AM
> To: Ville Voutilainen <ville.voutilainen_at_[hidden]>
> Cc: William Linkmeyer <wlink10_at_[hidden]>; std-discussion_at_[hidden]
> Subject: Re: [std-discussion] Optional Semicolons
>
> In a vacuum I would agree with you. But consider that:
>
> 1. This feature would not be mandatory on the programmer 2. This may be helpful to the ease of development 3. I’m going out on a limb here, but I think many of us can agree that the semicolon is often “mentally elided” when reading C++
>
> Also consider that C++ gives the programmer plenty of ways to be expressive already [1]. This is in-line with the programmer’s ability to be expressive.
>
> [1]: a function-like object in C++ could look like a class with an overloaded (), a std::function, a lambda, a regular function, some inline assembly with scope, a function pointer (smart or otherwise), etc.
>
> WL
>
>>> On Apr 28, 2022, at 1:40 PM, Ville Voutilainen <ville.voutilainen_at_[hidden]> wrote:
>>>
>>> On Thu, 28 Apr 2022 at 20:34, William Linkmeyer via Std-Discussion
>>> <std-discussion_at_[hidden]> wrote:
>>>
>>> Some things will potentially change meaning — yes. But none of the examples here need to break existing code.
>>>
>>> We could optionally elide semicolons if — and only if — one or both of these conditions are meta:
>>>
>>> 1. A statement could end with a semicolon and be syntactically
>>> acceptable 2. A statement is followed by another statement which also
>>> satisfies (1)
>>>
>>> Perhaps (2) could be modified as “… or by the end of the current scope.”
>>
>> I don't think this helps. In the status quo, it's actually easy to see
>> when code structures will necessarily continue on the subsequent
>> lines, and when they end. While the idea may seem convenient,
>> especially for pascal users and javascript users etc. etc., it's
>> actually going to make C++ iffier to read, whereas currently this part
>> of C++ is very readable.
> --
> Std-Discussion mailing list
> Std-Discussion_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-discussion