I understand that most of the people here are either used to the syntax or appreciate it.
However I want to thank you all for considering my idea for so long.

Cheers, Filip

> Wiadomość napisana przez Marcin Jaczewski via Std-Proposals <std-proposals_at_[hidden]> w dniu 10 lut 2025, o godz. 14:23:
>
> pon., 10 lut 2025 o 13:05 Tiago Freire <tmiguelf_at_[hidden]> napisał(a):
>>
>>
>>> Using the same logic I can't assume that the reference is to `int` and not to `std::string` as you can mess up dynamic types too.
>>> Or reference point to some uninitialized memory.
>>
>> What? Where did you get that conclusion?
>> We can and we do assume that the reference to an int references an int, even tough that is not always true.
>>
>
> From your insisting on that refs "can be null". Because if you say
> "can be null" the conclusion would be
> that we can check this like `&ref != nullptr` but the compiler will
> happily remove it as "refs can't be null".
>
> From C++ perspective refs can never be null. In our code they can but
> then I would consider this is not C++ anymore,
> or at least partially is not C++. Similar when you link your code with
> code compiled from different languages,
> they could have "nullable refs" or "rebindable refs", but this do not
> change that C++ do not have them,
> even when code is run and some C++ refs get mutate and set to null.
>
> I simply think we should not consider side effects of broken programs
> when discussing semantics of C++
> (aside from cases that prevent writing them in the first place). and
> nullable reference is one of the side effects
> of broken C++ programs. Otherwise we should consider return-oriented
> programming as part C++ :D
>
>
>
>>> If you have null ref then it means your code is broken elsewhere, if you have null ptr then you need to consider if it should be or not be null here in the first place.
>>
>> Yes! That's what everybody does. That's the implicit contract that is taken when using references.
>> It's not that it can't be null. It is that when I write code I'm going to assume that it isn't invalid, and if there's something the check the user of the interface has done that check.
>>
>> That's why the argument of using (.) to dereference a pointer is bad, it has negative value.
>>
>> If "var" is a reference and then changed to a pointer, code like:
>> var.member
>> should fail to compile, and that is a good thing, because you changed the contract.
>> Because you have to re-write it as
>> var->member
>> you have to opt-in, "this code assumed that references can't be null, but now it uses a pointer which can easily be null, I have looked at this code and accepted that I have done the necessary checks to dereference it".
>> Had "." been allowed to dereference a pointer, this would have gone unnoticed.
>>
>> That was the argument, this syntactical change not only doesn't have a positive value to change, it has a negative value if you do.
>
> Probably most people here agree with this.
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals