Library Typedefs are fundamentally broken

[Don via Digitalmars-d]

On Tuesday, 23 September 2014 at 16:01:35 UTC, Andrei 
Alexandrescu wrote:
> On 9/23/14, 7:43 AM, Don wrote:
>> On Monday, 22 September 2014 at 14:56:26 UTC, Andrei 
>> Alexandrescu wrote:
>>> On 9/22/14, 2:39 AM, Don wrote:
>>>> Yes, but you're advocating a hack.
>>>
>>> Oh but I very much disagree.
>>
>> Now you are scaring me. It worries me that this kind of 
>> "solution" can
>> be viewed as acceptable. It's the kind of hacky code I left 
>> C++ to
>> escape from.
>
> Hmm... doesn't strike me as similar to C++-specific hacks, but 
> I understand the sentiment.
>
>> People in this thread said it was "ugly" and you dismissed 
>> that.
>
> Nononononono. I totally agree some may find it ugly! It's 
> "unusable" I have a problem with.

I think that "unusable" has been used with two meanings in this 
thread.
That's why I've been using the word "hack".

>> But
>> this isn't just a matter of personal aesthetics.
>> If you want something objective, it's not DRY, and it's 
>> verbose in a
>> non-trivial way. The hacky design leads to error-prone code.
>> eg you can easily get a copy-paste bug because it's not DRY.
>>
>> alias HMENU = Typedef!(void*, __MODULE__ ~ ".HMENU");
>> alias HFONT = Typedef!(void*, __MODULE__ ~ ".HMENU"); // oops
>
> mixin(makeTypedef!("HMENU", void*));
> mixin(makeTypedef!("HFONT", void*));
>
> I said and I repeat: I do agree it's less convenient than a 
> baked-in facility. Even with the proper default arguments and 
> all. But I stand by Typedef as an adequate abstraction.

You need a very, very good reason to require a string mixin in 
user code. I'm not seeing that here. The cure is worse than the 
disease.

>>> How many libraries did you use that came with no idioms for 
>>> their usage?
>>
>> Describing this as an "idiom" is extremely generous. My 
>> standards are
>> higher.
>
> Well "extremely generous" is not "deluded" so I'll take that 
> :o).
>
>>>> And it does seem to me, that because it isn't possible to do 
>>>> a proper
>>>> library typedef, you've attempted to redefine what a Typedef 
>>>> is supposed
>>>> to do. And sure, it you remove the requirement to create a 
>>>> unique type,
>>>> Typedef isn't broken.
>>>
>>> You're two paragraphs away from "library Typedefs are 
>>> fundamentally
>>> broken". Now which one is it?
>>
>> Phobos' Typedef is fundamentally broken, and that your claim 
>> that it is
>> not, relies on moving the goalposts.
>
> I disagree. I'm not one to dismiss good arguments. But there 
> aren't many here. There's gotta be a point at which you'll 
> agree the whole argument against Typedef has no legs. It's 
> working as designed (I forgot who designed it),
>the design fits the purpose, the semantics never surprised me, 
>and when people
> now come with the pitchforks that it's broken, all I can do is 
> send them to the manual. IT WORKS.

The argument is that if you use Typedef for real-world use cases, 
your code is broken unless you use an unintuitive hack. The OP 
was proof that this is actually happening.

I think your starting point is wrong. The design does *not* fit 
the purpose. We got Typedef to appease objections to 'typedef' 
being removed from the language. And it did had the effect of 
silencing the critics. We all expected Typedef to be a drop-in 
replacement for typedef, not something with dangerously different 
semantics.

Now, if, right from the beginning, you never expected Typedef to 
replace typedef, then I can see why you think that Typedef is not 
broken. (But in that case I have no idea what you thought Typedef 
would be used for). Typedef solves the wrong problem, and solves 
it well. But when you try to use it to solve the right problem, 
you have to use an unintuitive hack.

>>>> But then it isn't very useful, either. You can't,
>>>> for example, use it to define the various Windows HANDLEs 
>>>> (HMENU, etc),
>>>> which was one of the most successful use cases for D1's 
>>>> typedef.
>>>
>>> alias HMENU = Typedef!(void*, __MODULE__ ~ ".HMENU");
>>>
>>> So please s/can't/can't the same exact way built-in typedef 
>>> would have
>>> done it/.
>>
>> No. You can hammer nails in using a rock, but I'm not prepared 
>> to accept
>> a rock as a kind of hammer. It's not a tool that belongs in 
>> any toolbox.
>>
>> My assertion is, there are no use cases for Phobos's Typedef.
>> You're always better off doing something else.
>
> But your evidence destroys your own assertion. Let me explain.
>
> You bring the typo example as the smoking gun. So I take it 
> it's a biggie that, if fixed, would make you happy.

Not really. I showed that example simply to illustrate that the 
complaint "this is ugly" is more than an personal preference. 
It's ugly because it's a hack.

> But there are a number of trivial fixes to it, such as my 
> defineTypedef above. So it looks like (a) Typedef can be used 
> as long as you are careful to not type the wrong name, (b) with 
> only trivial work, Typedef can be used without even the 
> slightest repetition.
>
> So how come Typedef is unusable when it's usable by your own 
> testimony?

I have never said it couldn't be used. I said that it's usable, 
in the same way that a rock is usable as a hammer. As a 
substitute for a built-in typedef, it's not a library solution, 
it's a library-supported hack.

And we should remove it before it leads more people astray.