`ref T` should be a type!!

Walter Bright newshound2 at digitalmars.com
Mon Apr 1 11:09:01 UTC 2019


On 3/31/2019 6:19 PM, Manu wrote:
> Are you saying that it's impossible to design a solution where ref is
> part of the type and that's less complex than C++?

I couldn't think of a way. I could have simply copied the C++ design. But why 
copy a nightmare of kludges?


> Is the complexity is that ecosystem inherent, or is it somewhat
> informed by backwards-compatibility, and other C++ design constraints?

There was no backwards compatibility issue when ref was designed. It's just a 
poor choice (like volatile).


> The fact that I can write `struct Ref(T)` and that it propagates the
> type system in a natural way suggests to me that the design is not
> impossible.

I have no idea why you want to do such things, but apparently you have a 
solution that works for you, so that's all good.


>> Please show a use case. I can't think of one.
> A use case for propagating ref in the type? You can't imagine why a
> template argument might want to distinguish `int` and `ref int`?

Indulge me. Why would it?


> I don't know how you've never found yourself static-if-ing on ref-ness
> of stuff in every bit of functional meta you've ever written. Ref
> creates an out-of-language (we have no language features to interact
> with 'storage class') suite of conditions that I frequently have to
> wrangle my way through.
> We have strong language mechanisms to reason about the type system,
> there is no language to reason about storage class that's not a kludge
> of awkward hacks and ugly meta utilities.

If I was faced with that, I'd step back and re-assess why the design required 
such machinations.

It reminds me of when I peruse Phobos, I'm disturbed by the overly complex code 
there - something Andrei referred to in the "generality creep" thread.

If C++ does it better, I don't see how. I find the implementation code of the 
STL to be horrifying in its complexity. I don't know how to write such code 
without thinking "something has gone terribly wrong".

If I may, I once talked to a Ferrari mechanic. He said that most engines inside, 
where customers didn't see the innards, were sloppily made. But that the Ferrari 
engine was a thing of beauty inside and a joy to work on. Ironically, Ferraris 
are also known for cheap, poorly done cab interiors. An unusual focus for a car 
company :-) but one that appeals to my inner engineer. The engine in my Dodge 
was built the same way, it's blueprinted with all top quality parts inside it, 
but the outside is plain jane, no chrome parts, no dress-up, etc.



More information about the Digitalmars-d mailing list