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

[Manu]

On Thu, 15 Aug 2024 at 21:05, Jonathan M Davis via Digitalmars-d <
digitalmars-d at puremagic.com> wrote:

> On Thursday, August 15, 2024 4:34:49 AM MDT Richard (Rikki) Andrew
> Cattermole
> via Digitalmars-d wrote:
> > On 15/08/2024 9:05 PM, IchorDev wrote:
> > > Yeah, I feel you. When I first started writing in D I’d also use `const
> > > ref`, but I agree that interleaving the storage class and the type is
> > > not right. I’m not alone in having started with `const ref`, and then
> > > having moved to using `ref const` as I understood the language better.
> > > I think part of the reason some gravitate to `const ref` because of
> > > ignorance when coming from C++, but I never used C++ because I was
> aware
> > > of its reputation. Instead, I found the ordering to violate English
> > > adjective ordering. `ref const T` sounds wrong in the same way as ‘red
> > > big balloon’. In English you can have a ‘constant reference integer’
> but
> > > not a ‘reference constant integer’; it sounds like an imperative
> > > instruction.
> >
> > +1
> >
> > Perhaps not an error in practice, but a warning is certainly warranted
> > as it shows a lack of understanding in the language.
>
> 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?

I understand const perfectly fine
> and yet I always use const ref unless I have to use ref const, because ref
> const is just plain ugly -


Subjective; and I feel the opposite way. However there is definitely one
that is *more correct*, and it's undeniably the way I argue here.

and it doesn't add any value except in cases
> where you can't use it anyway.
>

I reckon there's immense value in representing the language in such a way
that you can learn and feel the semantics by osmosis. `storage class` seems
to be a complex matter that takes a long time to get a proper feel for even
if you do read the spec. I am absolutely convinced that for a majority of
newcomers, seeing type declarations separated into distinct parts helps to
separate the concepts.

I have had detailed conversations stimulated by this exact confusion on
many occasions... writing `const ref` gives people the wrong impression
every time and a long detailed conversation necessarily follows, and it's a
conversation that's never flattering towards D. In my experience, it's one
among a series of small but meaningful-in-aggregate such psychological
blows against D whenever I introduce it to new people. It's among a subtle
suite of issues that undermine people's confidence that D knows what it's
doing very early on.

I agree that having function attributes be legal on both the left-hand and
> right-hand side of a function is problematic, but I see no value in forcing
> their order, and in general, making their order matter is just going to be
> annoying to deal with.
>

I see no value in *not *forcing their order. I made my case, apparently you
weren't persuaded... make your case, I'd like to hear it. Something like
"yeah, I just kinda like to mix it up however I want" is definitely not
going to persuade me.

Either way, warnings are a terrible idea in general. When you're dealing
> with warnings, you end up in one of two situations:
>
> 1. You ignore the ones that don't actually need fixing, in which case, the
> number of warnings will eventually grow to the point that you can't
> actually
> see the ones that matter, making the warnings borderline useless.
>
> 2. You "fix" all of the warnings so that none are buried, meaning that
> you're effectively treating all warnings as errors even though many of them
> don't actually indicate a real problem, making the difference between
> warnings and errors effectively pointless.
>
> The fact that dmd even has warnings was a huge mistake IMHO. Either they
> should be errors, or they should be left up to linters, and we should avoid
> adding new warnings like the plague (honestly, I think that we should
> really
> consider getting rid of them entirely).
>
> And warnings in D are even worse than they are in most languages, because
> -w
> is unfortunately a thing, meaning that adding a warning can result in an
> error, which can not only make perfectly valid code cease to compile with a
> compiler update, but it affects conditional compilation, because it affects
> checks for whether a particular piece of code compiles, which is used
> _heavily_ in templated code. So, you can end up with template constraints
> which suddenly fail - or even worse, the code ends up compiling but using a
> different branch, and you silently end up with worse performance (or maybe
> even altered behavior in some cases).
>

Yes, totally agree; definitely not a warning. Either a spec change, or a
convention should be established in the major libraries so people see a
consistent pattern they will follow in their own code.



> If you want to have a linter of some kind warn about random stuff like
> const
> ref, then I really don't care, but adding anything of the sort to the
> compiler is a terrible idea.
>
> - Jonathan M Davis
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20240815/6cd2a0aa/attachment.htm>