Library Typedefs are fundamentally broken
Andrei Alexandrescu via Digitalmars-d
digitalmars-d at puremagic.com
Mon Sep 22 07:56:30 PDT 2014
On 9/22/14, 2:39 AM, Don wrote:
> On Sunday, 21 September 2014 at 18:09:26 UTC, Andrei Alexandrescu wrote:
>> On 9/21/14, 8:29 AM, ketmar via Digitalmars-d wrote:
>>> On Sun, 21 Sep 2014 08:15:29 -0700
>>> Andrei Alexandrescu via Digitalmars-d <digitalmars-d at puremagic.com>
>>> wrote:
>>>
>>>> alias Int1 = Typedef!(int, "a.Int1");
>>>> alias Int2 = Typedef!(int, "b.Int2");
>>> ah, now that's cool. module system? wut? screw it, we have time-proven
>>> manual prefixing!
>>
>> Use __MODULE__. -- Andrei
>
>
> Yes, but you're advocating a hack.
Oh but I very much disagree.
> The original premise does seem to be
> correct: library Typedefs are fundamentally broken. The semantics of
> templates does not match what one expects from a typedef: ie, declaring
> a new, unique type.
>
> If you have to pass __MODULE__ in, it's not really a library solution.
> The user code needs to pass in a nasty implementation detail in order to
> get a unique type.
How many libraries did you use that came with no idioms for their usage?
> 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?
> 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/.
> Having said that, though, the success of 'alias this' does raise some
> interesting questions about how useful the concept of a typedef is.
> Certainly it's much less useful than when Typedef was created.
>
> My feeling is that almost every time when you want to create a new type
> from an existing one, you actually want to restrict the operations which
> can be performed on it. (Eg if you have typedef money = double; then
> money*money doesn't make much sense). For most typedefs I think you're
> better off with 'alias this'.
When control is needed, yah. I had some thoughts on adding policies to
Typedef (convert to base type etc) but as it seems it's already
unusable, I won't bring them up :o).
Andrei
More information about the Digitalmars-d
mailing list