Things that make writing a clean binding system more difficult

[Dicebot via Digitalmars-d]

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".