Library Typedefs are fundamentally broken
Timon Gehr via Digitalmars-d
digitalmars-d at puremagic.com
Sat Sep 20 09:07:15 PDT 2014
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)
> Consider:
>
> alias A = Typedef!float;
> alias B = Typedef!float;
>
> By basic language rules, A and B are identical.
I don't see the relevance, but the definition of Typedef is also
important to decide whether they are identical, not just language rules.
> Making them magically distinct ...
(Straw man.)
>
> 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");
// (different issue:
void main(){
A dollars=2;
B euros=2*dollars;
}//)
> 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");
// ---
template Fun(S,T)/+if(...)+/{
alias Hun=Typedef!(S,S.init,"hun");
// (BTW: what do I do if S or T has no default initializer?)
alias Gun=Typedef!(T,T.init,"gun");
// ...
}
Now e.g. Fun!(int,double).Hun is compatible with Fun!(int,string).Hun.
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.
> ...
>
> Your argument has been destroyed.
>...
My argument hasn't been considered. To destroy its relevance without
consideration would need a very compelling case for the beauty of the
cookie parameter, which I haven't seen yet, and it is hard for me to
imagine it being made without addressing the above issues. And besides,
it is probably highly subjective. Apparently you find the cookie
parameter to be pretty because it seems to work for the dollar/euro
example (after fixing), while I have a different set of expectations.
(BTW: Note that I am not arguing for bringing back built-in typedef.)
More information about the Digitalmars-d
mailing list