Am Sun, 21 Sep 2014 08:04:39 -0700
schrieb Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org>:

> Why would anyone hope a valid idiom were not mentioned?

It's just what people do when an argument would be
detrimental to their own position in an argument. :p
Look, I don't feel strongly about it. Just, from an objective
point of view, aliases and templates in their current form are
no good candidates to implement strongly typed typedefs. The
semantics are too different. A proxy struct for example
does more cleanly define a new symbol and type with normal
lookup rules. But let's not waste our energy on this now.
It is after all a convenience feature, not an enabler like
shared libraries, ARC or standard logging facilities.

> > Actually, that works for me. But it could be DRY and
> > look like
> >
> >    typedef ALfloat = float;
> 
> DRY is DRY. Bloating the language is bloating the language.
> 
> 
> Andrei

-- 
Marco

On 9/21/14, 8:28 AM, Dicebot wrote:
> On Sunday, 21 September 2014 at 15:15:27 UTC, Andrei Alexandrescu wrote:
>> alias Int2 = Typedef!(int, "b.Int2");
>
> ...and don't forget to keep those updated when module / aggregate names
> change via refactoring!

alias Int2 = Typedef!(int, __MODULE__ ~ ".Int2");

> Sorry but what you pretend to be a pragmatical solution is just a
> useless crap I  am not going to ever use while I am in sane mind.
> Especially considering that more reliable alternative can be hacked in
> few minutes.
>
>> More hyperbole won't help the weakness of the argument.
>
> Calling daily concerns of others "hyperbole" doesn't help to sell your
> solution as well-thought and reasonable.

Got it. So that's what people say when they run out of arguments.


Andrei

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@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

On 9/21/14, 10:56 AM, Marco Leise wrote:
> Am Sun, 21 Sep 2014 08:04:39 -0700
> schrieb Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org>:
>
>> Why would anyone hope a valid idiom were not mentioned?
>
> It's just what people do when an argument would be
> detrimental to their own position in an argument. :p
> Look, I don't feel strongly about it. Just, from an objective
> point of view, aliases and templates in their current form are
> no good candidates to implement strongly typed typedefs. The
> semantics are too different. A proxy struct for example
> does more cleanly define a new symbol and type with normal
> lookup rules. But let's not waste our energy on this now.
> It is after all a convenience feature, not an enabler like
> shared libraries, ARC or standard logging facilities.

Wise words, thanks! -- Andrei

Is this supposed to happen?
---
import std.typecons;

alias feet=Typedef!(float,0.0,"feet");
alias meter=Typedef!(float,0.0,"meter");

void main(){
	feet a=4.0;
	meter b=5.0;
	meter c=a*b;//opps
	pragma(msg,typeof(c));
}
---
$dmd -o- typetest.d
Typedef!(float, 0.00000F, "meter")

On Sunday, 21 September 2014 at 18:24:53 UTC, Freddy wrote:
> Is this supposed to happen?
> ---
> import std.typecons;
>
> alias feet=Typedef!(float,0.0,"feet");
> alias meter=Typedef!(float,0.0,"meter");
>
> void main(){
> 	feet a=4.0;
> 	meter b=5.0;
> 	meter c=a*b;//opps
> 	pragma(msg,typeof(c));
> }
> ---
> $dmd -o- typetest.d
> Typedef!(float, 0.00000F, "meter")

nevermind the build-in typedef is worse
---
typedef float feet;
typedef float meter;
void main(){
	feet a=cast(feet)4.0;//these are required
	meter b=cast(meter)5.0;
	auto c=a*b;//opps
	pragma(msg,typeof(c));
}
---
$dmd type.d -o-
type.d(1): Deprecation: use of typedef is deprecated; use alias
instead
type.d(2): Deprecation: use of typedef is deprecated; use alias
instead
meter

Andrei Alexandrescu:

>> from an objective
>> point of view, aliases and templates in their current form are
>> no good candidates to implement strongly typed typedefs. The
>> semantics are too different.
>
> Wise words, thanks! -- Andrei

So are you now admitting that Typedef is fundamentally broken?

Bye,
bearophile

On Sunday, 21 September 2014 at 18:09:00 UTC, Andrei Alexandrescu
wrote:
> On 9/21/14, 8:28 AM, Dicebot wrote:
>> On Sunday, 21 September 2014 at 15:15:27 UTC, Andrei Alexandrescu wrote:
>>> alias Int2 = Typedef!(int, "b.Int2");
>>
>> ...and don't forget to keep those updated when module / aggregate names
>> change via refactoring!
>
> alias Int2 = Typedef!(int, __MODULE__ ~ ".Int2");

Yeah now let's add __LINE__ there to make sure no clashes happen
and suddenly we get the same solution as the one proposed but
with manual typing of all special symbols.

This is definitely one of most convincing set of arguments I have
ever seen from you in this NG. Not.

Andrei Alexandrescu:

> DRY is DRY. Bloating the language is bloating the language.

To implement a typedef in library code in D perhaps you need a well implemented __gensym__ that works correctly in presence of separate compilation. It can generate a string that contains a progressive number for each D module, plus a digest of the module path and name.

Phobos contains hundreds of things, but a large percentage of them doesn't attract the amount of critiques that Typedef has received in many threads. This can suggest you that there is something special in Typedef.


>> Sooner or later a dirty semantics will bite your ass.
>
> Mine ain't hurting. -- Andrei

This is not surprising because you say you have not used Typedef much in your code.

Bye,
bearophile

On Sunday, 21 September 2014 at 17:47:57 UTC, Marco Leise wrote:
> Am Sun, 21 Sep 2014 08:04:39 -0700
> schrieb Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org>:
>
>> Why would anyone hope a valid idiom were not mentioned?
>
> It's just what people do when an argument would be
> detrimental to their own position in an argument. :p
> Look, I don't feel strongly about it. Just, from an objective
> point of view, aliases and templates in their current form are
> no good candidates to implement strongly typed typedefs. The
> semantics are too different. A proxy struct for example
> does more cleanly define a new symbol and type with normal
> lookup rules. But let's not waste our energy on this now.
> It is after all a convenience feature, not an enabler like
> shared libraries, ARC or standard logging facilities.

I agree that it is not _that_ important but it feels really bad
to have to reimplement parts of standard library to get semantics
at least somewhat close to promised/expected.

Pretty much only effective difference it makes is that write now
I have a custom Typedef wrapper as part of D1->D2 migration
helpers and initially hoped for forwarding it to
std.typecons.Typedef once migration is over. But considering
Andrei strong position on topic it will stay as in-house mixin
based solution, not a big deal.

I am just surprised Andrei insists so hard on defending solution
that is questionable at best.