On Thu, 15 Aug 2024 at 21:05, Jonathan M Davis via Digitalmars-d <digitalmars-d@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