C++ Logo

std-discussion

Advanced search

Re: Optional Semicolons

From: Marios Staikopoulos <marios_at_[hidden]>
Date: Thu, 28 Apr 2022 18:10:33 +0000
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_lists.isocpp.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_[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_lists.isocpp.org
https://lists.isocpp.org/mailman/listinfo.cgi/std-discussion

Received on 2022-04-28 18:10:36