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
<[email protected]>
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. 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.
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. 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.
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'.
