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