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