Remember that includes are copy-pasted into headers - if a library uses this new "style" then anything attempting to link to it that has inline header methods, or even template code, would have to be aware of this new syntax, which means it would have to be directly tied to a new c++ revision, and it would definitely not link with any linker/compiler that couldn't understand the new syntax. At the end of the day, you would probably be forced to only use it in source files compiled into a library, and those source files would have their own compiler flag to allow it - it just seems like build hell at this point...

-----Original Message-----
From: William Linkmeyer <wlink10_at_gmail.com>
Sent: Thursday, April 28, 2022 11:23 AM
To: Marios Staikopoulos <marios_at_staik.net>
Cc: std-discussion_at_lists.isocpp.org
Subject: Re: [std-discussion] Optional Semicolons

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_staik.net> 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_lists.isocpp.org> On
> Behalf Of William Linkmeyer via Std-Discussion
> Sent: Thursday, April 28, 2022 10:54 AM
> To: Ville Voutilainen <ville.voutilainen_at_gmail.com>
> Cc: William Linkmeyer <wlink10_at_gmail.com>;
> std-discussion_at_[hidden].org
> 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_gmail.com> wrote:
>>>
>>> On Thu, 28 Apr 2022 at 20:34, William Linkmeyer via Std-Discussion
>>> <std-discussion_at_lists.isocpp.org> 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_lists.isocpp.org
> https://lists.isocpp.org/mailman/listinfo.cgi/std-discussion