<div dir="ltr"><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, 29 Aug 2024 at 01:21, Nick Treleaven via Digitalmars-d <<a href="mailto:digitalmars-d@puremagic.com">digitalmars-d@puremagic.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Wednesday, 28 August 2024 at 11:47:12 UTC, Manu wrote:<br>
> For instance, the evidence here: <br>
> __traits(getParamterStorafeClasses,<br>
> function, paramterByIntegerIndex)<br>
> How would you expect to detect if something is ref, or scope, <br>
> or whatever?<br>
<br>
__traits(isRef, x)<br>
<br>
I expect a trait for isScope could be added if needed.<br></blockquote><div><br></div><div>Did you miss my point? The language can't <i>express </i>these things... we need backdoor information to hold the concept in any sort of expression.<br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
> Of course, what you expect is a STRING LITERAL, which you can <br>
> compare to a<br>
> string of the name of the storage class.<br>
> There's no stronger evidence that storage classes are <br>
> themselves such a<br>
> broken idea that exist way outside of the language than passing<br>
<br>
Just because you can't e.g. alias a storage class doesn't mean it <br>
is 'outside' the language. It's part of a declaration.<br></blockquote><div><br></div><div>You didn't miss my point. Hmmm.<br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
> around<br>
> string literals to tell you a fact about some declaration.<br>
> C++ puts these things in the type, and while that creates some <br>
> awkward<br>
> cases, it's infinitely better than what we have in D in terms of<br>
> expressiveness and flexibility in terms of meta programming.<br>
<br>
I've heard that C++ references are a complete swamp of special <br>
cases (regardless of lvalue vs rvalue reference).<br></blockquote><div><br></div><div>You've "heard"? I'm sorry, but your qualification to comment on the topic is definitely problematic from here on...</div><div><br></div><div>Anyone who holds the opinion that C++ references are a swamp of special cases <i>by contrast </i>has clearly not had any comparable experience with D references (and additional *suite* of storage classes). Nobody with experience in this matter can honestly say with a straight face that C++ is complicated and edgy by direct comparison.</div><div>Nothing in D is more awkward or poorly expressed.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
> What's kinda funny, is that your link to the cool ref-local <br>
> feature (finally!) above will be shortly followed with "how do <br>
> I detect if a local is a reference?" ... there's no <br>
> __traits(getLocalVariableStorageClass, ...)<br>
<br>
__traits(isRef, x)<br>
<br>
Example with `auto ref` in the changelog.<br></blockquote><div><br></div><div>Okay, fair; I had my mind on the general query relating to storage class like the one that returns a list of strings for each parameter. But it's like you say "one could be added for scope"; which actually demonstrates my point equally well.<br></div><div>... and why do we have 2 ways that do exactly the same thing?</div><div><br></div><div>C++ just doesn't have any of this nonsense. My biggest sense of loss from C++ to D is this fundamental area of the language in D that exists outside the language, and requires hacks and general weird-shit to access.<br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
> So I still don't really know; what IS a ref?<br>
<br>
It's a pointer that is automatically dereferenced on use, and <br>
never does pointer arithmetic.<br></blockquote><div><br></div><div>No, that's what it <i>does</i>. Write me an expression that embodies the concept? Write me an expression that copies ref-ness from one declaration to another declaration, for instance; I might be synthesising a parameter list for a shim with information from a given function...</div><div>It can't be expressed in the language. It's just an internal compiler concept that's unbelievably awkward to reason about, and can only be reasoned with back-door information.</div><div><br></div><div>Have you had a look at core.lifetime recently? Take a look at C++'s implementation of `std::forward`, `std::

move`, `emplace` (aka placement new)... tell me the situation in D is superior... core.lifetime is a war zone; you'll get a really good signal of just how far off the mark we have landed when comparing those fundamental language primitives.</div><div>There's basically nothing lower in the concept stack than core.lifetime; so why is it a complete mess? The reason is because none of our core concepts fit together; D is made out of parts with seriously jagged edges, and it needs a flood of hacky special-case reasoning to resolve the problems at the lowest level.</div><div><br></div><div>D's advantage is that a lot of things ARE POSSIBLE, but they come at a massive intellectual cost, and it doesn't need to be that way. It <i>shouldn't</i> be that way.<br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
> It's astonishing that s.tupleof is a sequence of ref's as you <br>
> say...<br>
<br>
BTW that was just how I understand `.tupleof`. I see it as (a <br>
superset of) a sequence of implicit ref declarations.<br></blockquote><div><br></div><div>Okay, so you might be wrong? Whether you are or aren't is irrelevant though, this is further evidence of the problem... it's not a "reasonable" design in fundamental terms. It's actually quite literally anti-reasonable. It's just internal compiler magic; the whole thing is a big special case, which creates edge cases at almost every single point of contact.</div><div>If you need a __traits to know a fundamental primitive fact like ref, something already went wrong.<br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
> does anything else in the language have a semantic like that?<br>
> How could I synthesise something like that from anything else <br>
> if I wanted to?<br>
<br>
If you mean synthesize `tupleof`, I already showed how (without <br>
introspection support), the first example here:<br>
<a href="https://forum.dlang.org/post/fctetiyhbiyhadlmcyzr@forum.dlang.org" rel="noreferrer" target="_blank">https://forum.dlang.org/post/fctetiyhbiyhadlmcyzr@forum.dlang.org</a><br>
<br>
That example literally works with dmd recent git.<br></blockquote><div><br></div><div>I'm very keen to play with ref locals when it lands; it's been such a long time coming.<br></div><div>That's not quite the same thing though; you've declared 2 local variables; does that infer they allocate stack space? Do I rely on the optimiser now to remove them? It looks like yet-another-workaround/hack to me.<br></div></div></div>