`ref T` should be a type!!

Manu turkeyman at gmail.com
Thu Apr 4 07:21:34 UTC 2019


On Mon, Apr 1, 2019 at 3:40 AM Walter Bright via Digitalmars-d
<digitalmars-d at puremagic.com> wrote:
>
> On 3/31/2019 6:30 PM, Manu wrote:
> >> A C++ ref can only appear at the top of a type AST, which is unlike any other
> >> type. Which exactly matches the only place a storage class can be!
> >
> > So, what you're saying is, C++ was able to implement storage class
> > semantics, but without distinguishing storage class from the type,
> > thereby making it accessible to any type construction or introspection
> > machinery that the language has available?
> >
> > Apparently C++ was genius in this way; why would you invent storage
> > class specifically to exclude ref from the ability to interact with
> > type construction and introspection machinery? ref sucks because it
> > can't interact with type construction or introspection. Every
> > meta-interaction with ref is via kludgey hacks.
>
> Um, have you looked at the special, kludgey rules for refs that permeate the C++
> spec? Just about every rule for types has a special case for refs. For example,
> C++ does type inference in various contexts. Sometimes the ref is inferred,
> sometimes it is skipped. Can you describe when it is inferred and when it isn't,
> and why?

I understand the rules are complex.
But I'm saying that 1; I don't believe we *must* implement the
complexity exactly the same way if ref were part of the type.
and 2; if you're being honest, you need to balance that complexity you
describe against the complexity introduced by the _idea_ of storage
class, every single detail relating to its implementation, and the
loss of language to interact with type construction and introspection.
Storage class and all related implementation and semantics are
*hugely* complicated, and I think it's worse because it's a parallel
system with an unrelated set of rules that you have to remember
distinctly, and no language for meaningful interaction. You can't
choose to ignore details about meta-interaction with storage class as
part of that complexity, they are major.
Whereas C++ ref rules are founded in type construction, which, while
needing to understand some special cases, don't require understanding
a whole parallel ecosystem.

I find it hard to judge that the storage class solution can be
considered simpler than the complexity that you refer to from C++, and
I also think it's a false comparison, because I suspect we could paint
the rules simpler than C++ if we tried.

Storage class == text mixin, and the worst kinds of text mixins,
because they usually affect the function signature. Because text
mixins must form a complete expression, if you ever need to do
text-mixin on a function signature, the **entire function** must be
written as a string which is unreasonably hideous.

Storage class is the worst thing in D. I love to make over-inflated
claims, but I say this with absolute conviction. There is nothing
about D more upsetting than storage class; it is functionally
incompatible with introspection and generative meta, and that's D's
strongest value proposition. How can you say a feature that's
fundamentally incompatible with meta-programming is great?

> > You mention the complexity of ref in C++, but that needs to be
> > balanced against the entire concept of 'storage class' in D, and
> > literally every single rule relating to it, since that's the
> > counter-weight. If you take the aggregate of all rules and semantics
> > related to 'storage class' in D, especially when including
> > consideration that we have lost the ability to do type construction or
> > introspection in storage classes, is that REALLY simpler than C++?
>
> Yes. Keep in mind that I implemented ref in C++, every last gory detail. I've
> earned my opinion of it.

The goal is to make language painless and enjoyable for authors, not
necessarily for compiler developers, that's just a nice bonus.

I'm not saying it *must* be like C++ (I suspect a less-complex set of
rules is possible), I'm just saying it's better. What it should NOT
be, is a completely separate mechanism outside of the language like
storage class.

Perhaps you can invent another meta-language for interacting with
storage-class... I've tried to imagine it, but I really struggle to
picture something satisfying.


More information about the Digitalmars-d mailing list