Things that make writing a clean binding system more difficult

[Jonathan M Davis via Digitalmars-d]

On Friday, July 29, 2016 14:14:49 Dicebot via Digitalmars-d wrote:
> On 07/29/2016 02:05 PM, Jonathan M Davis via Digitalmars-d wrote:
> > On Friday, July 29, 2016 02:55:14 Walter Bright via Digitalmars-d wrote:
> >> On 7/29/2016 1:34 AM, Jonathan M Davis via Digitalmars-d wrote:
> >>> I've always looked at D's ref as being essentially the same as C++'s &
> >>> except that it's not considered to be part of the type, just attached to
> >>> it
> >>> in a way that doesn't propagate. The same with with in or out. I just
> >>> don't
> >>> see how it even makes conceptual sense for ref to be an attribute of the
> >>> function itself.
> >>
> >> C++'s & is a bizarre type constructor in that it has completely wacky and
> >> special cased behavior in just about everything involving types,
> >> including
> >> type deduction, type inference, overloading, etc. For example, you can't
> >> have a pointer to a ref. Or a ref of a ref. Sometimes the ref is
> >> considered
> >> part of the type, sometimes not. Etc.
> >>
> >> With D, making it a sort of storage class completely sidesteps that mess.
> >
> > I understand that part. It's treating it like a function attribute that
> > makes no sense to me. Even if it's not treated as part of the return type
> > exactly, it's still the return type that it's affecting, not the function.
> > ref, in, and out are all in this kind of weird place where they affect a
> > type without being part of the type, and I'm guessing that because of how
> > oddball they are, there really wasn't a good way to deal with ref on the
> > return type, since it wasn't actually part of the type, so in the
> > implementation, it got tied to the function instead rather than trying to
> > add a new concept to the compiler. So, I guess that from an implementation
> > perspective, it makes some sense, but it's still downright weird given
> > that
> > ref really has to do with the return type and not the function itself,
> > even
> > if ref is a storage class rather than actually being part of the type.
>
> What you want it contradictory to the concept of "storage class".

Why? I thought the the whole idea of "storage class" was that it was an
attribute that was applied to a type that wasn't actually part of the type.
Certainly, based on past discussions on the topic, it seems to be that the
term is used for pretty much anything that gets applied to a type that isn't
actually part of the type. And that's definitely what happens with ref.

- Jonathan M Davis