Library Typedefs are fundamentally broken

Andrei Alexandrescu via Digitalmars-d digitalmars-d at puremagic.com
Sat Sep 20 10:15:02 PDT 2014


On 9/20/14, 9:07 AM, Timon Gehr wrote:
> On 09/20/2014 06:52 AM, Andrei Alexandrescu wrote:
>> On 9/19/14, 8:14 PM, Timon Gehr wrote:
>>> ....
>>> To substantiate: It does the wrong thing (same typedef for same base
>>> type) by default and doing the right thing (emulating nominal typing)
>>> may require quite some effort in general (e.g. concatenate the mangled
>>> names of all enclosing template instantiations) while remaining
>>> non-modular (those cookie strings are global identifiers).
>>
>> This is wrong
>
> Well, how?
>
>> but probably not worth fighting.
>
> "Then don't bring it up." :o)

Fair enough. It's just that... the tanks are coming and I'm to worry 
about the bayonet needing some grease instead of setting up the shaped 
charges. It's misplaced focus.

>> Human-readable cookies are exactly the solution: distinct human-readable
>> moniker that distinguish the types.
>>
>> alias A = Typedef!(float, "dollar");
>> alias B = Typedef!(float, "euro");
>> ...
>
> This doesn't compile. This, IMHO more _ugly_, code compiles:
>
> import std.typecons;
> alias A = Typedef!(float, float.init, "dollar");
> alias B = Typedef!(float, float.init, "euro");

Uhm, apparently I haven't tried the code :o). (Well prolly I'd want to 
use 0.0 as initializer there, too.)

> // (different issue:
> void main(){
>      A dollars=2;
>      B euros=2*dollars;
> }//)

Ew, that looks like a bug. How does that conversion go through? Could 
you please file an issue?

>> They will be distinct to the human and compiler alone.
>> ...
>
> Library A:
> alias A = Typedef!(int, -1, "handle");
>
> Library B:
> alias B = Typedef!(int, -1, "handle");
>
> // ---

Yup, yup, say no more. I get your point. Clearly there's some due 
diligence necessary here, i.e. prefix the name with the module name etc.

> This was my argument. IMO this state of affairs is ugly. Disagree that
> this makes the cookie parameter an 'ugly wart', but don't call the
> argument factually wrong without substantiation, please.

OK, fair enough. Thanks.


Andrei



More information about the Digitalmars-d mailing list