I see, so would something like this be problematic?

void f(){std::cout<<“f\n”}

void (*fptr)()=f

void g(){
 int a=0
 a=1
 (*fptr)()
}

WL

> On Apr 28, 2022, at 1:46 PM, Edward Catmur via Std-Discussion <std-discussion_at_[hidden]> wrote:
>
> 
>> On Thu, 28 Apr 2022 at 18:40, Ville Voutilainen via Std-Discussion <std-discussion_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.
>
> Best practice in Javascript is to insert "defensive" semicolons at the start of lines that begin with a problematic token, principally open parenthesis and open bracket.
>
> I think the general attitude in that community is that ASI is a misfeature, although beneficial to absolute beginners and to initial adoption.
> --
> Std-Discussion mailing list
> Std-Discussion_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-discussion