Things that make writing a clean binding system more difficult

[Jonathan M Davis via Digitalmars-d]

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.

- Jonathan M Davis