Library Typedefs are fundamentally broken

[Andrei Alexandrescu via Digitalmars-d]

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.

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

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

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


Andrei