`const ref T` or `ref const T`?

[Jonathan M Davis]

On Thursday, August 15, 2024 7:33:51 AM MDT Manu via Digitalmars-d wrote:
> On Thu, 15 Aug 2024 at 21:05, Jonathan M Davis via Digitalmars-d <
> > Not really. Unless you actually need to use parens, const ref is perfectly
> > valid, and I really don't see the problem.
>
> Really? I just explained it... you weren't even mildly persuaded?

No. The attributes in general are independent from one another. Forcing them
to be in a particular order is therefore arbitrary, and it forces everyone
to learn whatever that arbitrary order is. I see no value in that, and I
don't see any problem with the order being arbitrary. It's far less hassle
to be able to just write them out and not care one whit about the order when
they're independent from one another.

Changes are being made to force auto ref to be in that order, because
auto ref is basically a single attribute that probably should have been a
new attribute rather than combining two existing attributes, but that would
have meant adding a new keyword, so that's not what was done. The same is
not true for const ref or ref const at all. They're independent attributes
being applied.

The reason that allowing function attributes be on the left-hand side is a
problem is because then you get confusing inconsistencies like const not
applying to the return type, because it doesn't have parens even though
parens aren't required anywhere else unless you're applying const to only
part of the type. By requiring that the function attributes go on the
right-hand side, you solve that problem - and it still doesn't require that
the attributes be in a specific order. It just requires that the attributes
being applied to the function be one one side, and the attributes being
applied to the return type be on the other.

That being said, when it comes to attributes like public and static, which
can't apply to the return type, it arguably is better to allow them on the
left (particularly since most folks put them there, and they go on the left
for all other declarations), so maybe we should only restrict which side
function attributes go on if they could apply to the return type. But that
then creates inconsistencies where specific function attributes can go on
the left whereas others can't, which could also create confusion, which
IIRC, is why Walter has never been in favor of the idea. But I don't think
that he's ever really seen problems with

    const int foo() {...}

before either even though most everyone is going to read it wrong unless
they're very used to that particular quirk of the language.

Either way, I think that allowing const, immutable, or shared on the
left-hand side to apply to the function rather than the return type was a
mistake. And maybe the solution is to just require parens in those cases,
which would be kind of annoying too, but it would catch a bug without being
all that onerous.

In any case, the situation with ref const vs const ref is very different
from both auto ref and attributes on functions. The order is arbitrary, and
unless you're bringing parens into it, the order doesn't need to be defined.
I don't recall ever seeing anyone complain about const ref vs ref const
before, and I've never seen it as a problem myself. It just seems needlessly
strict to me to require that attributes in general be listed in a specific
order, and I don't want to have to worry about learning such rules -
particularly since I see no value in forcing a particular order. You're free
to disagree, and I don't think that it's particularly surprising if neither
of us finds the other's arguments particularly compelling. Clearly, you find
some kind of value in forcing the order that I do not understand, whereas I
see it as purely an unnecessary complication that would be a hassle to deal
with.

Either way, the person to convince would be Walter, and based on past
discussions of this sort, I doubt that he'll be convinced, but who knows. It
can sometimes be quite surprising what he does or doesn't agree with, and
it's not like he never changes his mind.

- Jonathan M Davis