Library Typedefs are fundamentally broken

[Freddy via Digitalmars-d]

When you have separate 2 typedefs of the exact same type, they
are equal.While this maybe able to be solved with
Typedef!(Typedef!(...)) different modules typedef ing the same
type (most likely build-in types) would have their typedef be
equivalent thereby degrading the purpose of typedef.
---
import std.typecons;

alias meter = Typedef!float;
alias feet = Typedef!float;
static assert(!is(meter==feet));
---
Your thoughts?

[Andrei Alexandrescu via Digitalmars-d]

Post by Freddy via Digitalmars-d
When you have separate 2 typedefs of the exact same type, they
are equal.While this maybe able to be solved with
Typedef!(Typedef!(...)) different modules typedef ing the same
type (most likely build-in types) would have their typedef be
equivalent thereby degrading the purpose of typedef.
---
import std.typecons;
alias meter = Typedef!float;
alias feet = Typedef!float;
static assert(!is(meter==feet));
---
Your thoughts?

Add a sequence number as a uint, defaulted to 0. -- Andrei

[bearophile via Digitalmars-d]

Post by Andrei Alexandrescu via Digitalmars-d
Add a sequence number as a uint, defaulted to 0. -- Andrei

See discussion:
https://d.puremagic.com/issues/show_bug.cgi?id=12100

Bye,
bearophile

[Andrej Mitrovic via Digitalmars-d]

Post by bearophile via Digitalmars-d

Post by Andrei Alexandrescu via Digitalmars-d
Add a sequence number as a uint, defaulted to 0. -- Andrei

https://d.puremagic.com/issues/show_bug.cgi?id=12100

It's a good thing you found GCC and VC implement this. I think it's
another sign that we could use this feature.

[monarch_dodra via Digitalmars-d]

On Wednesday, 17 September 2014 at 07:21:13 UTC, Andrej Mitrovic

On 9/17/14, bearophile via Digitalmars-d

Post by bearophile via Digitalmars-d

Post by Andrei Alexandrescu via Digitalmars-d
Add a sequence number as a uint, defaulted to 0. -- Andrei

https://d.puremagic.com/issues/show_bug.cgi?id=12100

It's a good thing you found GCC and VC implement this. I think
it's
another sign that we could use this feature.

Technically, they implement it via macro, and the macro
re-expands on every use. It's mostly useless outside of ".cpp"
files: The identifiers are unstable cross compilation units. And
if it appears in a .h, it'll be re-expanded to a different value
on every include. If it appears in a macro, it'll be expanded to
something different on every macro use too.

[Walter Bright via Digitalmars-d]

On Wednesday, 17 September 2014 at 07:21:13 UTC, Andrej Mitrovic via

Post by Andrej Mitrovic via Digitalmars-d

Post by bearophile via Digitalmars-d

Post by Andrei Alexandrescu via Digitalmars-d
Add a sequence number as a uint, defaulted to 0. -- Andrei

https://d.puremagic.com/issues/show_bug.cgi?id=12100

It's a good thing you found GCC and VC implement this. I think it's
another sign that we could use this feature.

Technically, they implement it via macro, and the macro re-expands on every use.
It's mostly useless outside of ".cpp" files: The identifiers are unstable cross
compilation units. And if it appears in a .h, it'll be re-expanded to a
different value on every include. If it appears in a macro, it'll be expanded to
something different on every macro use too.

It's implemented as a special macro named __COUNTER__ which expands to an
integer literal, incremented each time.

If such a thing were implemented in D, one could not depend on the values being
globally unique, nor consistent when a module is compiled vs imported, nor
consistent when multiple modules are compiled together vs compiled
independently, nor even any predictable relationship between the values within a
particular module (because semantic analysis is not supposed to be order dependent).

[Walter Bright via Digitalmars-d]

Post by Walter Bright via Digitalmars-d
If such a thing were implemented in D, one could not depend on the values being
globally unique, nor consistent when a module is compiled vs imported, nor
consistent when multiple modules are compiled together vs compiled
independently, nor even any predictable relationship between the values within a
particular module (because semantic analysis is not supposed to be order dependent).

You're probably better off simply using __LINE__ instead.

[Adam D. Ruppe via Digitalmars-d]

I don't think I've used any kind of typedef for a long time. I
prefer to just use a plain struct.

[H. S. Teoh via Digitalmars-d]

I don't think I've used any kind of typedef for a long time. I prefer
to just use a plain struct.

Yeah, I found structs + alias this far more useful than any kind of
typedef. Due to the way alias this lookups work, you can basically
"customize" the underlying type by defining the appropriate struct
methods to shadow the underlying type's, thereby achieving a kind of
"static inheritance".


T

[Piotrek via Digitalmars-d]

On Wednesday, 17 September 2014 at 05:40:22 UTC, H. S. Teoh via

On Wed, Sep 17, 2014 at 03:05:57AM +0000, Adam D. Ruppe via

Post by Adam D. Ruppe via Digitalmars-d
I don't think I've used any kind of typedef for a long time. I
prefer
to just use a plain struct.

Yeah, I found structs + alias this far more useful than any
kind of
typedef. Due to the way alias this lookups work, you can
basically
"customize" the underlying type by defining the appropriate
struct
methods to shadow the underlying type's, thereby achieving a
kind of
"static inheritance".
T

Do you think it's worth to mention it in "Comments" section of
the docs?

Piotrek

[H. S. Teoh via Digitalmars-d]

Post by Piotrek via Digitalmars-d
On Wednesday, 17 September 2014 at 05:40:22 UTC, H. S. Teoh via

On Wed, Sep 17, 2014 at 03:05:57AM +0000, Adam D. Ruppe via Digitalmars-d

Post by Adam D. Ruppe via Digitalmars-d
I don't think I've used any kind of typedef for a long time. I
prefer to just use a plain struct.

Yeah, I found structs + alias this far more useful than any kind of
typedef. Due to the way alias this lookups work, you can basically
"customize" the underlying type by defining the appropriate struct
methods to shadow the underlying type's, thereby achieving a kind of
"static inheritance".
T

Do you think it's worth to mention it in "Comments" section of the
docs?

[...]

Sure. Which page?


T

[Piotrek via Digitalmars-d]

On Wednesday, 17 September 2014 at 21:03:26 UTC, H. S. Teoh via

On Wed, Sep 17, 2014 at 08:49:02PM +0000, Piotrek via

Post by Piotrek via Digitalmars-d
On Wednesday, 17 September 2014 at 05:40:22 UTC, H. S. Teoh via

On Wed, Sep 17, 2014 at 03:05:57AM +0000, Adam D. Ruppe via
Digitalmars-d

Post by Adam D. Ruppe via Digitalmars-d
I don't think I've used any kind of typedef for a long time. I
prefer to just use a plain struct.

Yeah, I found structs + alias this far more useful than any
kind of
typedef. Due to the way alias this lookups work, you can
basically
"customize" the underlying type by defining the appropriate
struct
methods to shadow the underlying type's, thereby achieving a
kind of
"static inheritance".
T

Do you think it's worth to mention it in "Comments" section of
the
docs?

[...]
Sure. Which page?
T

Now this is a good question :)


http://dlang.org/library/std/typecons.html
or
http://dlang.org/library/std/typecons/Typedef.html


Do we have any guideline for users comments?
Moreover, I've just stared wondering if the new layout if
officially released .

Piotrek

[Jakob Ovrum via Digitalmars-d]

Post by Freddy via Digitalmars-d
When you have separate 2 typedefs of the exact same type, they
are equal.While this maybe able to be solved with
Typedef!(Typedef!(...)) different modules typedef ing the same
type (most likely build-in types) would have their typedef be
equivalent thereby degrading the purpose of typedef.
---
import std.typecons;
alias meter = Typedef!float;
alias feet = Typedef!float;
static assert(!is(meter==feet));
---
Your thoughts?

`Typedef` takes a second argument that can make it unique. It's
all in the docs.

[Freddy via Digitalmars-d]

On Wednesday, 17 September 2014 at 03:08:46 UTC, Jakob Ovrum

Post by Jakob Ovrum via Digitalmars-d

Post by Freddy via Digitalmars-d
When you have separate 2 typedefs of the exact same type, they
are equal.While this maybe able to be solved with
Typedef!(Typedef!(...)) different modules typedef ing the same
type (most likely build-in types) would have their typedef be
equivalent thereby degrading the purpose of typedef.
---
import std.typecons;
alias meter = Typedef!float;
alias feet = Typedef!float;
static assert(!is(meter==feet));
---
Your thoughts?

`Typedef` takes a second argument that can make it unique. It's
all in the docs.

Sorry, my mistake.

[Jack Applegame via Digitalmars-d]

You can use module name and line number as unique tag.

[Dicebot via Digitalmars-d]

On Wednesday, 17 September 2014 at 10:00:31 UTC, Jack Applegame

Post by Jack Applegame via Digitalmars-d
You can use module name and line number as unique tag.

This is exactly what I would have expected as default behaviour.
Is anyone aware why this counter appoach was used instead?

[bearophile via Digitalmars-d]

Post by Dicebot via Digitalmars-d
Is anyone aware why this counter appoach was used instead?

It's not sound, it's a hack. Putting unreliable hacks in a
standard library is very bad. It's even worse than the problems
that Walter has listed for __COUNT__ (I didn't ask for that count
in my enhancement request. If you have to copy it's often better
to copy from Lisp/ML/Ada instead of C++).

Bye,
bearophile

[Dicebot via Digitalmars-d]

Post by bearophile via Digitalmars-d

Post by Dicebot via Digitalmars-d
Is anyone aware why this counter appoach was used instead?

It's not sound, it's a hack. Putting unreliable hacks in a
standard library is very bad. It's even worse than the problems
that Walter has listed for __COUNT__ (I didn't ask for that
count in my enhancement request. If you have to copy it's often
better to copy from Lisp/ML/Ada instead of C++).
Bye,
bearophile

It is pretty much default technique used any time new template
instance needs to be forced. Sound or not, I am not aware of any
other even remotely reliable library approaches (it works pretty
good for me actually).

[Andrej Mitrovic via Digitalmars-d]

Post by Dicebot via Digitalmars-d
It is pretty much default technique used any time new template
instance needs to be forced. Sound or not, I am not aware of any
other even remotely reliable library approaches (it works pretty
good for me actually).

Actually, there is just one small issue with it (rare enough to almost
never occur). Two instances on the same line will use the same line,
e.g.:

Foo!() x; Foo!() y;

But there would be a simple way to fix this, by introducing
__COLUMN__. But I don't know, it's using an AK47 to shoot a fly. There
are more important enhancements I guess. :p

[Walter Bright via Digitalmars-d]

Post by Dicebot via Digitalmars-d
Is anyone aware why this counter appoach was used instead?

It's not sound, it's a hack. Putting unreliable hacks in a standard library is
very bad. It's even worse than the problems that Walter has listed for __COUNT__
(I didn't ask for that count in my enhancement request. If you have to copy it's
often better to copy from Lisp/ML/Ada instead of C++).

Even worse? How? (Yes, I know that if you instantiate it twice on the same line,
you'll get the same value.)

[Dicebot via Digitalmars-d]

On Wednesday, 17 September 2014 at 17:16:55 UTC, Walter Bright

Post by Walter Bright via Digitalmars-d
Even worse? How? (Yes, I know that if you instantiate it twice
on the same line, you'll get the same value.)

To address the latter I usually implement it as a string token
that defaults to __MODULE__ ~ ":" ~ to!string(__LINE__) but still
can be manually specified by the user. It makes it possible to
disambiguate single line definitions when necessary.

[Jakob Ovrum via Digitalmars-d]

Post by Dicebot via Digitalmars-d
On Wednesday, 17 September 2014 at 10:00:31 UTC, Jack Applegame

Post by Jack Applegame via Digitalmars-d
You can use module name and line number as unique tag.

This is exactly what I would have expected as default
behaviour. Is anyone aware why this counter appoach was used
instead?

It's a deceivingly bad default. See the comments in the PR that
introduced Typedef[1].

[1] https://github.com/D-Programming-Language/phobos/pull/300

[Dicebot via Digitalmars-d]

Post by Jakob Ovrum via Digitalmars-d

Post by Dicebot via Digitalmars-d
On Wednesday, 17 September 2014 at 10:00:31 UTC, Jack

Post by Jack Applegame via Digitalmars-d
You can use module name and line number as unique tag.

This is exactly what I would have expected as default
behaviour. Is anyone aware why this counter appoach was used
instead?

It's a deceivingly bad default. See the comments in the PR that
introduced Typedef[1].
[1] https://github.com/D-Programming-Language/phobos/pull/300

Yes, this is a problem. But how is that possibly worse than
existing implementation which gives wrong results in 100% of
cases? file/line cookie approach has issues but it is best we can
get with existing language support.

[Jakob Ovrum via Digitalmars-d]

Post by Dicebot via Digitalmars-d

Post by Jakob Ovrum via Digitalmars-d

Post by Dicebot via Digitalmars-d
On Wednesday, 17 September 2014 at 10:00:31 UTC, Jack

Post by Jack Applegame via Digitalmars-d
You can use module name and line number as unique tag.

This is exactly what I would have expected as default
behaviour. Is anyone aware why this counter appoach was used
instead?

It's a deceivingly bad default. See the comments in the PR
that introduced Typedef[1].
[1] https://github.com/D-Programming-Language/phobos/pull/300

Yes, this is a problem. But how is that possibly worse than
existing implementation which gives wrong results in 100% of
cases? file/line cookie approach has issues but it is best we
can get with existing language support.

`Typedef` clearly comes with a big caveat that isn't apparent
from just reading user code. The documentation has to be read,
and the documentation clearly states that the cookie parameter
has to be used to get unique types. It's much less surprising to
have it generate unique types only when explicitly given a cookie
than having it sometimes make unique types and sometimes not
depending on complex conditions.

Maybe `Typedef` could be neatly fixed by making it a mixin
template?

[Wyatt via Digitalmars-d]

Post by Freddy via Digitalmars-d
When you have separate 2 typedefs of the exact same type, they
are equal.While this maybe able to be solved with
Typedef!(Typedef!(...)) different modules typedef ing the same
type (most likely build-in types) would have their typedef be
equivalent thereby degrading the purpose of typedef.
---
import std.typecons;
alias meter = Typedef!float;
alias feet = Typedef!float;
static assert(!is(meter==feet));
---
Your thoughts?

Reading this thread and thinking on it more... I acknowledge this
is probably kind of naive, but it makes aliases feel
not-very-useful to me.

It doesn't give you type checking or function overloading because
as far as the semantic pass is concerned, they're identical. And
that's fine. The documentation on AliasDeclaration is kind of
verbose, but it does clarify that at some point (had to reread it
a couple times to notice, though...). So I get that aliasing is
at least situationally useful (e.g. utility shortening), and I
think it's been stated repeatedly that it's great for
metaprogramming things, but the aggregate makes this situation
suck.

If you want those things to work, you have to wrap it in a struct
and use alias this (which IS a legitimately cool application of
the aliasing semantics, I'll grant). This can be mitigated
somewhat, but it still feels inelegant and not-D-like for
something I'd really like to use easily and often. Also, for the
hardcore among you, I think your cache may hate you for this (I
don't recall if that overhead gets optimised away).

I think you could be forgiven for expecting std.typecons.Typedef
to provide the alternative we need, but it ends up being only
about as useful as typedef in C (or maybe a bit less?). Is there
some better solution I've missed? (I wouldn't consider the
cookie parameter a better solution; I would consider it a wart.)

-Wyatt

[H. S. Teoh via Digitalmars-d]

On Thu, Sep 18, 2014 at 05:48:30PM +0000, Wyatt via Digitalmars-d wrote:
[...]

If you want those things to work, you have to wrap it in a struct and
use alias this (which IS a legitimately cool application of the
aliasing semantics, I'll grant). This can be mitigated somewhat, but
it still feels inelegant and not-D-like for something I'd really like
to use easily and often. Also, for the hardcore among you, I think
your cache may hate you for this (I don't recall if that overhead gets
optimised away).

[...]

Why would your cache hate you for it? A struct that contains, say, a
single int, is at the assembly level identical to the int itself,
because structs are value types and they were basically designed to be
"glorified ints", as Andrei puts it in TDPL. When you write something
like:

struct S {
int x;
alias x this;
// ...
}

S s;
s++;

basically "s++" gets translated to "s.x++", and since S behaves
basically identically to an int, which means it should get enregistered
under the same circumstances, the generated machine code should be
identical to when you wrote "int" instead of "S".

I don't see why this should have any effect on the cache. Unless you
added extra fields to your struct where you shouldn't, and it becomes
too big to fit in registers, then it's not really the compiler's fault.
:-P

The neatest thing about this, is that any operator overloading you
implement for S will, in effect, behave like overloading the built-in
int operators; and if your operator overloads have simple
implementations, they will be inlined and you get basically a "native"
int but with overloaded operators. (This, of course, is the whole point
behind the 'checkedint' type currently used by some internal Phobos /
dmd functions. You basically have a type that's identical to int in
every way, except that some operations will have overflow checks
inserted in front in the machine code.)

This is why 'alias this' is such a total stroke of genius. It brings the
parity between user and built-in types to a whole new level of cool.


T

[Wyatt via Digitalmars-d]

On Thursday, 18 September 2014 at 18:02:08 UTC, H. S. Teoh via

Post by H. S. Teoh via Digitalmars-d
basically "s++" gets translated to "s.x++", and since S behaves
basically identically to an int, which means it should get
enregistered under the same circumstances, the generated machine
code should be identical to when you wrote "int" instead of "S".

Oh, neat. I stand corrected on that point. Thanks.

Post by H. S. Teoh via Digitalmars-d
I don't see why this should have any effect on the cache.

That's my mistake; I thought there was overhead for structs in D.
Should have done my homework!

It's too bad this does nothing for the usability issues. :/

-Wyatt

[Andrei Alexandrescu via Digitalmars-d]

(I wouldn't consider the cookie parameter a better solution; I would
consider it a wart.)

That's the right solution.

Andrei

[bearophile via Digitalmars-d]

Post by Andrei Alexandrescu via Digitalmars-d

(I wouldn't consider the cookie parameter a better solution; I
would consider it a wart.)

That's the right solution.

The cookie parameter is a ugly wart.

Bye,
bearophile

[Marco Leise via Digitalmars-d]

Am Fri, 19 Sep 2014 05:53:00 +0000

Post by bearophile via Digitalmars-d

Post by Andrei Alexandrescu via Digitalmars-d

(I wouldn't consider the cookie parameter a better solution; I
would consider it a wart.)

That's the right solution.

The cookie parameter is a ugly wart.
Bye,
bearophile

We should probably revert to having real typedefs.
I find myself not using Typedef either. Instead I use wrapper
structs with alias this, because they fit the shoe much better
by introducing a unique symbol in a straight forward way :)

Rationale

Typedef is not flexible enough to cover all use cases.
This is better done with a language solution.

[Andrei Alexandrescu via Digitalmars-d]

Post by Marco Leise via Digitalmars-d
Am Fri, 19 Sep 2014 05:53:00 +0000

Post by bearophile via Digitalmars-d

Post by Andrei Alexandrescu via Digitalmars-d

(I wouldn't consider the cookie parameter a better solution; I
would consider it a wart.)

That's the right solution.

The cookie parameter is a ugly wart.
Bye,
bearophile

We should probably revert to having real typedefs.

Should not.

Post by Marco Leise via Digitalmars-d
I find myself not using Typedef either. Instead I use wrapper
structs with alias this, because they fit the shoe much better
by introducing a unique symbol in a straight forward way :)
Rationale
Typedef is not flexible enough to cover all use cases.
This is better done with a language solution.

What's missing?


Andrei

[Marco Leise via Digitalmars-d]

Am Fri, 19 Sep 2014 08:02:30 -0700

Post by Andrei Alexandrescu via Digitalmars-d

Post by Marco Leise via Digitalmars-d
We should probably revert to having real typedefs.

Should not.

Ok, but don't ask me to use
alias ALfloat = std.typecons.Typedef!(float, "yummyCookie23");
when it could be
typedef ALfloat = float;
! :)

Post by Andrei Alexandrescu via Digitalmars-d

Post by Marco Leise via Digitalmars-d
I find myself not using Typedef either. Instead I use wrapper
structs with alias this, because they fit the shoe much better
by introducing a unique symbol in a straight forward way :)
Rationale
Typedef is not flexible enough to cover all use cases.
This is better done with a language solution.

What's missing?
Andrei

That was more of a pun on the original deprecation rationale:
"typedef is not flexible enough to cover all use cases.
This is better done with a library solution."
Frankly though it seems like templates are the improper tool
to create new unique symbols when at the same time we more or
less depend on templates only being instantiated once for the
same arguments.

[Andrei Alexandrescu via Digitalmars-d]

Post by Marco Leise via Digitalmars-d
Am Fri, 19 Sep 2014 08:02:30 -0700

Post by Andrei Alexandrescu via Digitalmars-d

Post by Marco Leise via Digitalmars-d
We should probably revert to having real typedefs.

Should not.

Ok, but don't ask me to use
alias ALfloat = std.typecons.Typedef!(float, "yummyCookie23");
when it could be
typedef ALfloat = float;
! :)

I think this is an entirely palatable idiom:

alias ALfloat = std.typecons.Typedef!(float, "ALfloat");


Andrei

[ketmar via Digitalmars-d]

On Sat, 20 Sep 2014 08:25:17 -0700
Andrei Alexandrescu via Digitalmars-d <digitalmars-d at puremagic.com>

Post by Andrei Alexandrescu via Digitalmars-d
alias ALfloat = std.typecons.Typedef!(float, "ALfloat");

this is ugly. even if we remove "std.typecons." it's still ugly. making
such core feature ugly is the right way to marginalize it. "what? all
this uglyness only for simple typedef? screw it, i'll go with simple
`alias ALfloat = float;`! oh, wait... this gives me nothing and i
already messed some declarations... ah, screw it, will use `float`
then!"

the whole thing with aliasing Typedef is broken. yes, it's smart to use
library for this (see, our language is THAT powerful!), but it's uuugly.

the same thing as with octal literals: we have 0b, we have 0x, yet it's
very smart to banish octals to phobos and use octal!"660" instead of
logical 0o660. phew.

but i know: octal literals are handy, so they will never make their way
to mainline. "typedef" construct is handy, so...
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: not available
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20140920/8b44fcfc/attachment.sig>

[bearophile via Digitalmars-d]

Post by ketmar via Digitalmars-d
but i know: octal literals are handy, so they will never make
their way to mainline. "typedef" construct is handy, so...

A well working Typedef/typedef (named "newtype" in Haskell, where
it's a built-in) is more commonly useful than octal literals.

Bye,
bearophile

[ketmar via Digitalmars-d]

On Sat, 20 Sep 2014 16:36:49 +0000

Post by bearophile via Digitalmars-d
A well working Typedef/typedef (named "newtype" in Haskell, where
it's a built-in) is more commonly useful than octal literals.

i'm not saying that octal literals are in much need, i'm talking about
consistency (again).
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: not available
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20140920/36db8dcc/attachment.sig>

[Andrei Alexandrescu via Digitalmars-d]

Post by ketmar via Digitalmars-d
On Sat, 20 Sep 2014 08:25:17 -0700
Andrei Alexandrescu via Digitalmars-d <digitalmars-d at puremagic.com>

Post by Andrei Alexandrescu via Digitalmars-d
alias ALfloat = std.typecons.Typedef!(float, "ALfloat");

this is ugly.

But not unusable.

Post by ketmar via Digitalmars-d
even if we remove "std.typecons." it's still ugly. making
such core feature ugly is the right way to marginalize it. "what? all
this uglyness only for simple typedef? screw it, i'll go with simple
`alias ALfloat = float;`! oh, wait... this gives me nothing and i
already messed some declarations... ah, screw it, will use `float`
then!"

Are you saying you're giving up on an entire design because you can't
bring yourself to type one string?

Post by ketmar via Digitalmars-d
the whole thing with aliasing Typedef is broken.

s/broken/less convenient than a builtin/ and we agree.

Post by ketmar via Digitalmars-d
yes, it's smart to use
library for this (see, our language is THAT powerful!), but it's uuugly.

uuugly != broken

Post by ketmar via Digitalmars-d
the same thing as with octal literals: we have 0b, we have 0x, yet it's
very smart to banish octals to phobos and use octal!"660" instead of
logical 0o660. phew.
but i know: octal literals are handy, so they will never make their way
to mainline. "typedef" construct is handy, so...

Not sure I understand this last point. At any rate, if your entire line
of reasoning hinges on you being unwilling to type a few more characters
to have a workable solution, I have difficulty taking it seriously.


Andrei

[ketmar via Digitalmars-d]

On Sat, 20 Sep 2014 10:20:28 -0700
Andrei Alexandrescu via Digitalmars-d <digitalmars-d at puremagic.com>

Post by Andrei Alexandrescu via Digitalmars-d

Post by ketmar via Digitalmars-d

Post by Andrei Alexandrescu via Digitalmars-d
alias ALfloat = std.typecons.Typedef!(float, "ALfloat");

this is ugly.

But not unusable.

tying code using my nose is entirely possible too, and it even fun. but
it's far from being "usable technique".

Post by Andrei Alexandrescu via Digitalmars-d
Are you saying you're giving up on an entire design because you can't
bring yourself to type one string?

not just one string. people will use ugly features only when they are
forced to. D makes using typedefs unnecessarily ugly, thus
marginalising them. turn struct declaration to "Declare!struct" and
leave class declaration as-is, and people will start use classes
instead of structs, even when struct is better fit. or remove "string"
alias.

what i'm trying to say is that "typedef" is "core feature" if we are
talking about type safety, and it should be nice or people will not use
it. current "Typedef" is not nice.

Post by Andrei Alexandrescu via Digitalmars-d

Post by ketmar via Digitalmars-d
the whole thing with aliasing Typedef is broken.

s/broken/less convenient than a builtin/ and we agree.

no, it is broken. for such important feature "less convient" means
"broken".

Post by Andrei Alexandrescu via Digitalmars-d
uuugly != broken

"==" for this case.

Post by Andrei Alexandrescu via Digitalmars-d
Not sure I understand this last point. At any rate, if your entire
line of reasoning hinges on you being unwilling to type a few more
characters to have a workable solution, I have difficulty taking it
seriously.

i don't want "workable solution", i want "usable solution". "Typedef"
is barely usable due to being one of fundamental features and uuugly.
make something ugly and people will avoid it as much as they can. if we
don't care about compile-time type safety... ok, let it stay ugly.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: not available
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20140920/49c2c1c5/attachment-0001.sig>

[Andrei Alexandrescu via Digitalmars-d]

Post by ketmar via Digitalmars-d
i don't want "workable solution", i want "usable solution".

Guess a copyediting pass would have caught that one. -- Andrei

[Dicebot via Digitalmars-d]

On Saturday, 20 September 2014 at 17:20:28 UTC, Andrei

Post by Andrei Alexandrescu via Digitalmars-d

Post by ketmar via Digitalmars-d
On Sat, 20 Sep 2014 08:25:17 -0700
Andrei Alexandrescu via Digitalmars-d
<digitalmars-d at puremagic.com>

Post by Andrei Alexandrescu via Digitalmars-d
alias ALfloat = std.typecons.Typedef!(float, "ALfloat");

this is ugly.

But not unusable.

Requiring manual tracing of identity = unusable. With my proposed
implementation it is at least clear when it is going to fail.
This is much worse:

module a;

alias Int1 = Typedef!(int, "MyInt");

module b;

alias Int2 = Typedef!(int, "MyInt");

// oh I didn't know someone else used that cookie too..
static assert (is(Int1 == Int2));

Such solution simply can't be allowed in any project with >1
active programmer unless either type safety is not important or
some additional restrictions on adding new typedefs are added
process-wise (insane).

[bearophile via Digitalmars-d]

Post by Dicebot via Digitalmars-d
module a;
alias Int1 = Typedef!(int, "MyInt");
module b;
alias Int2 = Typedef!(int, "MyInt");
// oh I didn't know someone else used that cookie too..

Sooner or later a dirty semantics will bite your ass. It's an
important rule of language/library design.

Post by Dicebot via Digitalmars-d
unless either type safety is not important

If type safety is not so important in a piece of code, you
probably are already not using a typedef/Typedef/newtype.

Bye,
bearophile

[Andrei Alexandrescu via Digitalmars-d]

Post by bearophile via Digitalmars-d

Post by Dicebot via Digitalmars-d
module a;
alias Int1 = Typedef!(int, "MyInt");
module b;
alias Int2 = Typedef!(int, "MyInt");
// oh I didn't know someone else used that cookie too..

Sooner or later a dirty semantics will bite your ass.

Mine ain't hurting. -- Andrei

[Andrei Alexandrescu via Digitalmars-d]

Post by Dicebot via Digitalmars-d

Post by Andrei Alexandrescu via Digitalmars-d

Post by ketmar via Digitalmars-d
On Sat, 20 Sep 2014 08:25:17 -0700
Andrei Alexandrescu via Digitalmars-d <digitalmars-d at puremagic.com>

Post by Andrei Alexandrescu via Digitalmars-d
alias ALfloat = std.typecons.Typedef!(float, "ALfloat");

this is ugly.

But not unusable.

Requiring manual tracing of identity = unusable. With my proposed
implementation it is at least clear when it is going to fail. This is
module a;
alias Int1 = Typedef!(int, "MyInt");

alias Int1 = Typedef!(int, "a.Int1");

Post by Dicebot via Digitalmars-d
module b;
alias Int2 = Typedef!(int, "MyInt");

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

Post by Dicebot via Digitalmars-d
// oh I didn't know someone else used that cookie too..
static assert (is(Int1 == Int2));
Such solution simply can't be allowed in any project with >1 active
programmer unless either type safety is not important or some additional
restrictions on adding new typedefs are added process-wise (insane).

More hyperbole won't help the weakness of the argument.


Andrei

[Dicebot via Digitalmars-d]

On Sunday, 21 September 2014 at 15:15:27 UTC, Andrei Alexandrescu

Post by Andrei Alexandrescu via Digitalmars-d
alias Int2 = Typedef!(int, "b.Int2");

..and don't forget to keep those updated when module / aggregate
names change via refactoring!

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.

Post by Andrei Alexandrescu via Digitalmars-d
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.

[Andrei Alexandrescu via Digitalmars-d]

Post by Andrei Alexandrescu via Digitalmars-d
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.

Post by Andrei Alexandrescu via Digitalmars-d
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

[Dicebot via Digitalmars-d]

On Sunday, 21 September 2014 at 18:09:00 UTC, Andrei Alexandrescu

Post by Andrei Alexandrescu via Digitalmars-d

Post by Dicebot via Digitalmars-d
On Sunday, 21 September 2014 at 15:15:27 UTC, Andrei

Post by Andrei Alexandrescu via Digitalmars-d
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 via Digitalmars-d]

Post by Dicebot via Digitalmars-d
On Sunday, 21 September 2014 at 18:09:00 UTC, Andrei Alexandrescu

Post by Andrei Alexandrescu via Digitalmars-d

Post by Andrei Alexandrescu via Digitalmars-d
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.

No need. -- Andrei

[ketmar via Digitalmars-d]

On Sun, 21 Sep 2014 08:15:29 -0700
Andrei Alexandrescu via Digitalmars-d <digitalmars-d at puremagic.com>

Post by Andrei Alexandrescu via Digitalmars-d
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!
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: not available
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20140921/1ae851bd/attachment.sig>

[Andrej Mitrovic via Digitalmars-d]

Post by ketmar via Digitalmars-d
On Sun, 21 Sep 2014 08:15:29 -0700
Andrei Alexandrescu via Digitalmars-d <digitalmars-d at puremagic.com>

Post by Andrei Alexandrescu via Digitalmars-d
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!

To be fair we now have __MODULE__. Although it does make the call side
a bit ugly. But then again, nothing is stopping anyone from writing a
helper template around Typedef that hides all this ugliness, e.g.:

-----
// helper alias
alias StrongAlias(T, string mod = __MODULE__, size_t line = __LINE__)
= Typedef!(T, T.init, format("%s.%s.%s", mod, line, T.stringof));

// usage:
alias Int1 = StrongAlias!int;
alias Int2 = StrongAlias!int;
static assert(!is(Int1 == Int2));
-----

This works for me locally. We could add __COLUMN__ to be extra-safe of
course, by then it should be a solved problem.

[Andrei Alexandrescu via Digitalmars-d]

Post by ketmar via Digitalmars-d
On Sun, 21 Sep 2014 08:15:29 -0700
Andrei Alexandrescu via Digitalmars-d <digitalmars-d at puremagic.com>

Post by Andrei Alexandrescu via Digitalmars-d
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

[ketmar via Digitalmars-d]

On Sun, 21 Sep 2014 11:09:28 -0700
Andrei Alexandrescu via Digitalmars-d <digitalmars-d at puremagic.com>

Post by Andrei Alexandrescu via Digitalmars-d

Post by ketmar via Digitalmars-d

Post by Andrei Alexandrescu via Digitalmars-d
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

you still can't grok concept of "ugly == unusable". thank you, i'd
better fsck this miserably attempt on type security, and many other
practical programmers too. we trying to explain you this and each time
you answers "so what? no, it's not." even to people who tried to use
this disgusting "solution" and found it unacceptable and broken.

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

don't make me laugh. this is not just ugly, this is MEGAUGLY. then we
can make some kind of magic template to hide this uglyness, yes. the
uglyness which shouldn't be there in the first place. each time when
such ugly "workaround" proposed we can see the feature as completely
broken.

people trying to tell you that it is broken for single developer (too
much to type for nothing). that it is broken for group developement
(people will forget to mix all the uglyness for necessary result). that
it is just broken.

please, we aren't bunch of kids who just happen to dislike typing extra
chars. our objections backed by trying to use the feature in practice.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: not available
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20140921/7a80e66a/attachment.sig>

[Tourist via Digitalmars-d]

On Sunday, 21 September 2014 at 20:41:22 UTC, ketmar via

Post by ketmar via Digitalmars-d
On Sun, 21 Sep 2014 11:09:28 -0700
Andrei Alexandrescu via Digitalmars-d
<digitalmars-d at puremagic.com>

Post by Andrei Alexandrescu via Digitalmars-d

Post by ketmar via Digitalmars-d

Post by Andrei Alexandrescu via Digitalmars-d
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

you still can't grok concept of "ugly == unusable". thank you,
i'd
better fsck this miserably attempt on type security, and many
other
practical programmers too. we trying to explain you this and
each time
you answers "so what? no, it's not." even to people who tried
to use
this disgusting "solution" and found it unacceptable and broken.
alias Int1 = Typedef!(int, __MODULE__~".Int1");
don't make me laugh. this is not just ugly, this is MEGAUGLY.
then we
can make some kind of magic template to hide this uglyness,
yes. the
uglyness which shouldn't be there in the first place. each time
when
such ugly "workaround" proposed we can see the feature as
completely
broken.
people trying to tell you that it is broken for single
developer (too
much to type for nothing). that it is broken for group
developement
(people will forget to mix all the uglyness for necessary
result). that
it is just broken.
please, we aren't bunch of kids who just happen to dislike
typing extra
chars. our objections backed by trying to use the feature in
practice.

Why don't you capitalize?
Looks like you're a reasonable person, and this makes an outsider
think that your IQ is lower than the average. IMO.

[ketmar via Digitalmars-d]

On Sun, 21 Sep 2014 20:48:34 +0000

Post by Tourist via Digitalmars-d
Why don't you capitalize?

it's my "one man's crusade" against the thing i see as completely
useless.

Post by Tourist via Digitalmars-d
Looks like you're a reasonable person, and this makes an outsider
think that your IQ is lower than the average. IMO.

and my English is bad too (mea culpa; i have to fix it by taking some
courses). but i believe that arguments aren't depend of the speaker.
and i don't care what people think about my personality. if they choose
to ignore everything i'm writing just 'cause they think that i'm dumb...
ah, so be it. it's arguments that counts, not their source.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: not available
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20140922/c36e77db/attachment.sig>

[bearophile via Digitalmars-d]

Post by Tourist via Digitalmars-d
Why don't you capitalize?
Looks like you're a reasonable person, and this makes an
outsider think that your IQ is lower than the average. IMO.

IQs are a flawed unit of measure. ketmar intelligences seem fine.
ketmar reasoning is good here. Why don't you redirect your
efforts against someone else more deserving?

Bye,
bearophile

[Andrei Alexandrescu via Digitalmars-d]

Post by ketmar via Digitalmars-d
On Sun, 21 Sep 2014 20:48:34 +0000

Post by Tourist via Digitalmars-d
Why don't you capitalize?

it's my "one man's crusade" against the thing i see as completely
useless.

Post by Tourist via Digitalmars-d
Looks like you're a reasonable person, and this makes an outsider
think that your IQ is lower than the average. IMO.

and my English is bad too (mea culpa; i have to fix it by taking some
courses). but i believe that arguments aren't depend of the speaker.
and i don't care what people think about my personality. if they choose
to ignore everything i'm writing just 'cause they think that i'm dumb...
ah, so be it. it's arguments that counts, not their source.

I don't mind the capitalization, ad hominem, etc. The arguments against
Typedef are honestly terrible (by all participants), and the attempts at
enhancing them through hyperbole are embarrassing. -- Andrei

[ketmar via Digitalmars-d]

On Sun, 21 Sep 2014 15:22:05 -0700
Andrei Alexandrescu via Digitalmars-d <digitalmars-d at puremagic.com>

Post by Andrei Alexandrescu via Digitalmars-d
I don't mind the capitalization, ad hominem, etc. The arguments
against Typedef are honestly terrible (by all participants), and the
attempts at enhancing them through hyperbole are embarrassing. --
Andrei

this discussion raises some heat, methinks. we all should take some
rest and calm down. sorry for beung rude and so on. nothing
personal. ;-)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: not available
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20140922/a3920b66/attachment.sig>

[Andrei Alexandrescu via Digitalmars-d]

Post by ketmar via Digitalmars-d
On Sun, 21 Sep 2014 11:09:28 -0700
Andrei Alexandrescu via Digitalmars-d <digitalmars-d at puremagic.com>

Post by Andrei Alexandrescu via Digitalmars-d

Post by ketmar via Digitalmars-d

Post by Andrei Alexandrescu via Digitalmars-d
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

you still can't grok concept of "ugly == unusable".

Also I must be missing the distinction between "workable solution" and
"usable solution". Such semantic subtleties seem to be lost on me in
this context.

Post by ketmar via Digitalmars-d
thank you, i'd
better fsck this miserably attempt on type security, and many other
practical programmers too. we trying to explain you this and each time
you answers "so what? no, it's not." even to people who tried to use
this disgusting "solution" and found it unacceptable and broken.

The problem here is inept argumentation. I'm all for a well argued
debate. This argument seems to have trouble getting legs, and foaming at
the mouth is unlikely to add value to it.

Post by ketmar via Digitalmars-d
alias Int1 = Typedef!(int, __MODULE__~".Int1");
don't make me laugh. this is not just ugly, this is MEGAUGLY.

Pretty much by what I mean with "foaming at the mouth" and "vivid
anecdote fallacy". Can you make an argument with words in the dictionary?

Post by ketmar via Digitalmars-d
then we
can make some kind of magic template to hide this uglyness, yes. the
uglyness which shouldn't be there in the first place. each time when
such ugly "workaround" proposed we can see the feature as completely
broken.
people trying to tell you that it is broken for single developer (too
much to type for nothing). that it is broken for group developement
(people will forget to mix all the uglyness for necessary result). that
it is just broken.
please, we aren't bunch of kids who just happen to dislike typing extra
chars. our objections backed by trying to use the feature in practice.

I'm not buying this. The more it goes the less convincing it goes.


Andrei

[ketmar via Digitalmars-d]

On Sun, 21 Sep 2014 15:17:52 -0700
Andrei Alexandrescu via Digitalmars-d <digitalmars-d at puremagic.com>

Post by Andrei Alexandrescu via Digitalmars-d
I'm not buying this. The more it goes the less convincing it goes.

oh. i'm off, i just don't know what else to say. this discussion seems
to go in circles, so it's better to put it on hold for some time. at
least until someone invents better arguments. ;-)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: not available
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20140922/736a7d92/attachment.sig>

[Timon Gehr via Digitalmars-d]

"vivid anecdote fallacy"

FWIW:
https://www.google.ch/?gws_rd=cr&ei=XVYfVIu7IcL1OYi7gMgH#q=%22vivid+anecdote+fallacy%22

[Andrei Alexandrescu via Digitalmars-d]

Post by Timon Gehr via Digitalmars-d

"vivid anecdote fallacy"

https://www.google.ch/?gws_rd=cr&ei=XVYfVIu7IcL1OYi7gMgH#q=%22vivid+anecdote+fallacy%22

Pretty awesome :o). I was referring to "misleading vividness:"
http://en.wikipedia.org/wiki/Misleading_vividness - which shows up once
in a while in this forum... -- Andrei

[Marco Leise via Digitalmars-d]

Am Sat, 20 Sep 2014 08:25:17 -0700

Post by Andrei Alexandrescu via Digitalmars-d

Post by Marco Leise via Digitalmars-d
Am Fri, 19 Sep 2014 08:02:30 -0700

Post by Andrei Alexandrescu via Digitalmars-d

Post by Marco Leise via Digitalmars-d
We should probably revert to having real typedefs.

Should not.

Ok, but don't ask me to use
alias ALfloat = std.typecons.Typedef!(float, "yummyCookie23");
when it could be
typedef ALfloat = float;
! :)

alias ALfloat = std.typecons.Typedef!(float, "ALfloat");
Andrei

Funny that you mention it. I had the exact same thought
yesterday and hoped you wouldn't come around with that ...
excuse. Actually, that works for me. But it could be DRY and
look like

typedef ALfloat = float;

[Andrei Alexandrescu via Digitalmars-d]

Post by Marco Leise via Digitalmars-d
Am Sat, 20 Sep 2014 08:25:17 -0700

Post by Andrei Alexandrescu via Digitalmars-d

Post by Marco Leise via Digitalmars-d
Am Fri, 19 Sep 2014 08:02:30 -0700

Post by Andrei Alexandrescu via Digitalmars-d

Post by Marco Leise via Digitalmars-d
We should probably revert to having real typedefs.

Should not.

Ok, but don't ask me to use
alias ALfloat = std.typecons.Typedef!(float, "yummyCookie23");
when it could be
typedef ALfloat = float;
! :)

alias ALfloat = std.typecons.Typedef!(float, "ALfloat");
Andrei

Funny that you mention it. I had the exact same thought
yesterday and hoped you wouldn't come around with that ...
excuse.

Why would anyone hope a valid idiom were not mentioned?

Post by Marco Leise via Digitalmars-d
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 Leise via Digitalmars-d]

Am Sun, 21 Sep 2014 08:04:39 -0700

Post by Andrei Alexandrescu via Digitalmars-d
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.

Post by Andrei Alexandrescu via Digitalmars-d

Post by Marco Leise via Digitalmars-d
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

[Andrei Alexandrescu via Digitalmars-d]

Post by Marco Leise via Digitalmars-d
Am Sun, 21 Sep 2014 08:04:39 -0700

Post by Andrei Alexandrescu via Digitalmars-d
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

[bearophile via Digitalmars-d]

Post by Andrei Alexandrescu via Digitalmars-d

Post by Marco Leise via Digitalmars-d
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

[Andrei Alexandrescu via Digitalmars-d]

Post by bearophile via Digitalmars-d

Post by Andrei Alexandrescu via Digitalmars-d

Post by Marco Leise via Digitalmars-d
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?

No. -- Andrei

[Dicebot via Digitalmars-d]

Post by Marco Leise via Digitalmars-d
Am Sun, 21 Sep 2014 08:04:39 -0700

Post by Andrei Alexandrescu via Digitalmars-d
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.

[Andrei Alexandrescu via Digitalmars-d]

Post by Dicebot via Digitalmars-d
I am just surprised Andrei insists so hard on defending solution
that is questionable at best.

It's just what the doctor prescribed. A good engineering solution for a
minor problem. -- Andrei

[ketmar via Digitalmars-d]

On Sun, 21 Sep 2014 19:56:48 +0200

Post by Marco Leise via Digitalmars-d
It is after all a convenience feature

easy type safety is just "a convient feature"? O_O

i'm wordless.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: not available
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20140921/e6c1c504/attachment.sig>

[Ola Fosheim Grostad via Digitalmars-d]

On Sunday, 21 September 2014 at 20:49:02 UTC, ketmar via

Post by ketmar via Digitalmars-d
On Sun, 21 Sep 2014 19:56:48 +0200
Marco Leise via Digitalmars-d <digitalmars-d at puremagic.com>

Post by Marco Leise via Digitalmars-d
It is after all a convenience feature

easy type safety is just "a convient feature"? O_O
i'm wordless.

I am waiting for a patch...

[ketmar via Digitalmars-d]

On Sun, 21 Sep 2014 22:07:21 +0000
Ola Fosheim Grostad via Digitalmars-d <digitalmars-d at puremagic.com>

Post by Ola Fosheim Grostad via Digitalmars-d
I am waiting for a patch...

i believe that we should revive 'typedef' keyword, but i'm not fully
convinced yet. so i'll wait a little more. but you guessed it right,
i'm thinking about another patch. ;-)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: not available
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20140922/cd2f27f9/attachment-0001.sig>

[Ola Fosheim Grostad via Digitalmars-d]

On Sunday, 21 September 2014 at 23:00:09 UTC, ketmar via

Post by ketmar via Digitalmars-d
i believe that we should revive 'typedef' keyword, but i'm not
fully
convinced yet. so i'll wait a little more. but you guessed it
right,
i'm thinking about another patch. ;-)

It's a nice small project, if I didn't have backlog I'd give it a
go. Sounds fun.

[bearophile via Digitalmars-d]

Post by Andrei Alexandrescu via Digitalmars-d
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.

Post by Andrei Alexandrescu via Digitalmars-d

Post by bearophile via Digitalmars-d
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

[Andrei Alexandrescu via Digitalmars-d]

Post by Andrei Alexandrescu via Digitalmars-d
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.

Nice to have, but not necessary. -- Andrei

[Andrei Alexandrescu via Digitalmars-d]

Post by bearophile via Digitalmars-d

Post by Andrei Alexandrescu via Digitalmars-d

(I wouldn't consider the cookie parameter a better solution; I would
consider it a wart.)

That's the right solution.

The cookie parameter is a ugly wart.

No. -- Andrei

[Timon Gehr via Digitalmars-d]

Post by Andrei Alexandrescu via Digitalmars-d

Post by bearophile via Digitalmars-d

Post by Andrei Alexandrescu via Digitalmars-d

(I wouldn't consider the cookie parameter a better solution; I would
consider it a wart.)

That's the right solution.

The cookie parameter is a ugly wart.

No. -- Andrei

Yes.

[Andrei Alexandrescu via Digitalmars-d]

Post by Andrei Alexandrescu via Digitalmars-d

Post by bearophile via Digitalmars-d

Post by Andrei Alexandrescu via Digitalmars-d

(I wouldn't consider the cookie parameter a better solution; I would
consider it a wart.)

That's the right solution.

The cookie parameter is a ugly wart.

No. -- Andrei

Yes.

No. :o) -- Andrei

[Timon Gehr via Digitalmars-d]

Post by Andrei Alexandrescu via Digitalmars-d

Post by Andrei Alexandrescu via Digitalmars-d

Post by bearophile via Digitalmars-d

Post by Andrei Alexandrescu via Digitalmars-d

(I wouldn't consider the cookie parameter a better solution; I would
consider it a wart.)

That's the right solution.

The cookie parameter is a ugly wart.

No. -- Andrei

Yes.

No. :o) -- Andrei

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).

I.e. Typedef is fail. Won't use. Declaring a new struct and using Proxy,
perhaps encapsulated using a mixin template is less trouble (quick hack,
results in bad error messages):

import std.typecons;

mixin template WorkingTypedef(string i,T,T init=T.init)/+if(...)+/{
// workaround for https://issues.dlang.org/show_bug.cgi?id=13500
mixin std.typecons.Typedef!(T,init);
mixin(`alias `~i~` =Typedef;`);
}
mixin WorkingTypedef!("Name1",int);
mixin WorkingTypedef!("Name2",int,2);

void main(){
Name1 foo;
Name2 bar;
foo=bar; // error
}


Feel free to disagree, but I don't see how one can.

[Andrei Alexandrescu via Digitalmars-d]

Post by Timon Gehr via Digitalmars-d

Post by Andrei Alexandrescu via Digitalmars-d

Post by Andrei Alexandrescu via Digitalmars-d

Post by bearophile via Digitalmars-d

Post by Andrei Alexandrescu via Digitalmars-d

(I wouldn't consider the cookie parameter a better solution; I would
consider it a wart.)

That's the right solution.

The cookie parameter is a ugly wart.

No. -- Andrei

Yes.

No. :o) -- Andrei

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 but probably not worth fighting. Consider:

alias A = Typedef!float;
alias B = Typedef!float;

By basic language rules, A and B are identical. Making them magically
distinct would be surprising and would require explanation. It's as if
someone writes:

struct Point { int x, y; }
alias A = Point;

and then later in the same module

alias B = Point;

and complains that the compiler didn't automagically distinguish between
the two.

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");

They will be distinct to the human and compiler alone.

Post by Timon Gehr via Digitalmars-d
I.e. Typedef is fail. Won't use.

Typedef is win. Feel free to not use.

Post by Timon Gehr via Digitalmars-d
Declaring a new struct and using Proxy,
perhaps encapsulated using a mixin template is less trouble (quick hack,
import std.typecons;
mixin template WorkingTypedef(string i,T,T init=T.init)/+if(...)+/{
// workaround for https://issues.dlang.org/show_bug.cgi?id=13500
mixin std.typecons.Typedef!(T,init);
mixin(`alias `~i~` =Typedef;`);
}
mixin WorkingTypedef!("Name1",int);
mixin WorkingTypedef!("Name2",int,2);
void main(){
Name1 foo;
Name2 bar;
foo=bar; // error
}
Feel free to disagree, but I don't see how one can.

Your argument has been destroyed.


Andrei

[Vladimir Panteleev via Digitalmars-d]

On Saturday, 20 September 2014 at 04:52:58 UTC, Andrei

[snip]

Um, why not use __FILE__ / __LINE__ (as default values for
template parameters) as cookies?

[Marco Leise via Digitalmars-d]

Am Sat, 20 Sep 2014 06:32:38 +0000

Post by Vladimir Panteleev via Digitalmars-d
On Saturday, 20 September 2014 at 04:52:58 UTC, Andrei

[snip]

Um, why not use __FILE__ / __LINE__ (as default values for
template parameters) as cookies?

It has this nasty imperfection that it breaks as soon as you
define two Typedefs on the same line. Which noone ever does
except maybe for an obfuscated coding scenario, but still it
raises my OCD level.

[Vladimir Panteleev via Digitalmars-d]

Post by Marco Leise via Digitalmars-d
Am Sat, 20 Sep 2014 06:32:38 +0000

Post by Vladimir Panteleev via Digitalmars-d
On Saturday, 20 September 2014 at 04:52:58 UTC, Andrei

[snip]

Um, why not use __FILE__ / __LINE__ (as default values for
template parameters) as cookies?

It has this nasty imperfection that it breaks as soon as you
define two Typedefs on the same line. Which noone ever does
except maybe for an obfuscated coding scenario, but still it
raises my OCD level.

We could introduce __COLUMN__ trivially now that DMD tracks
column numbers :)

[Daniel Murphy via Digitalmars-d]

"Marco Leise" wrote in message

Post by Marco Leise via Digitalmars-d
It has this nasty imperfection that it breaks as soon as you
define two Typedefs on the same line. Which noone ever does
except maybe for an obfuscated coding scenario, but still it
raises my OCD level.

Or inside a template, but that breaks with an explicit cookie as well.

template Foo(T)
{
alias FooIndex = Typedef!(int, "FooIndex");
}

static assert(!is(Foo!int == Foo!string));

[Vladimir Panteleev via Digitalmars-d]

On Saturday, 20 September 2014 at 17:05:40 UTC, Daniel Murphy

Post by Daniel Murphy via Digitalmars-d
"Marco Leise" wrote in message

Post by Marco Leise via Digitalmars-d
It has this nasty imperfection that it breaks as soon as you
define two Typedefs on the same line. Which noone ever does
except maybe for an obfuscated coding scenario, but still it
raises my OCD level.

Or inside a template, but that breaks with an explicit cookie
as well.
template Foo(T)
{
alias FooIndex = Typedef!(int, "FooIndex");
}
static assert(!is(Foo!int == Foo!string));

What if you *want* a Typedef instantiation to be the same for all
instantiations of a parent template?

I think you can have both if Typedef simply takes an "ARGS...",
which defaults to TypeTuple!(__FILE__, __LINE__, __COLUMN__), but
in this case can be overridden to TypeTuple!(Foo, T).

[Jakob Ovrum via Digitalmars-d]

Post by Marco Leise via Digitalmars-d
Am Sat, 20 Sep 2014 06:32:38 +0000

Post by Vladimir Panteleev via Digitalmars-d
On Saturday, 20 September 2014 at 04:52:58 UTC, Andrei

[snip]

Um, why not use __FILE__ / __LINE__ (as default values for
template parameters) as cookies?

It has this nasty imperfection that it breaks as soon as you
define two Typedefs on the same line. Which noone ever does
except maybe for an obfuscated coding scenario, but still it
raises my OCD level.

https://github.com/D-Programming-Language/phobos/pull/300#issuecomment-3329507

[Andrei Alexandrescu via Digitalmars-d]

[snip]

Um, why not use __FILE__ / __LINE__ (as default values for template
parameters) as cookies?

We could, but that would be surprising. I'd say things are good as they
are. -- Andrei

[Dicebot via Digitalmars-d]

On Saturday, 20 September 2014 at 04:52:58 UTC, Andrei

Post by Andrei Alexandrescu via Digitalmars-d
alias A = Typedef!float;
alias B = Typedef!float;
By basic language rules, A and B are identical. Making them
magically distinct would be surprising and would require
struct Point { int x, y; }
alias A = Point;
and then later in the same module
alias B = Point;

But Typedef is not some generic symbol. It is library type
specifically introduced as `typedef` keyword replacement and
advertised as such. I expect it to work as close to `typedef` as
possible being the most priority. Otherwise it is simply useless.

Post by Andrei Alexandrescu via Digitalmars-d

Post by Timon Gehr via Digitalmars-d
I.e. Typedef is fail. Won't use.

Typedef is win. Feel free to not use.

Thanks for permitting, this is exactly what I will do.

[Andrei Alexandrescu via Digitalmars-d]

Post by Andrei Alexandrescu via Digitalmars-d
alias A = Typedef!float;
alias B = Typedef!float;
By basic language rules, A and B are identical. Making them magically
distinct would be surprising and would require explanation. It's as if
struct Point { int x, y; }
alias A = Point;
and then later in the same module
alias B = Point;

But Typedef is not some generic symbol. It is library type specifically
introduced as `typedef` keyword replacement and advertised as such. I
expect it to work as close to `typedef` as possible being the most
priority. Otherwise it is simply useless.

No. -- Andrei

[Dicebot via Digitalmars-d]

On Saturday, 20 September 2014 at 15:26:37 UTC, Andrei

Post by Andrei Alexandrescu via Digitalmars-d

Post by Dicebot via Digitalmars-d
But Typedef is not some generic symbol. It is library type
specifically
introduced as `typedef` keyword replacement and advertised as
such. I
expect it to work as close to `typedef` as possible being the
most
priority. Otherwise it is simply useless.

No. -- Andrei

I don't really care what you think. There is a simple fact -
there is not a single use case I am going to use existing
implementation instead of rolling one of my own. Call me a
pervert but when standard library type can't be used for
something it was initially proposed for it does smell like a
failure.

[Andrei Alexandrescu via Digitalmars-d]

Post by Dicebot via Digitalmars-d

Post by Andrei Alexandrescu via Digitalmars-d

But Typedef is not some generic symbol. It is library type specifically
introduced as `typedef` keyword replacement and advertised as such. I
expect it to work as close to `typedef` as possible being the most
priority. Otherwise it is simply useless.

No. -- Andrei

I don't really care what you think.

You should if I'm right :o).

Post by Dicebot via Digitalmars-d
There is a simple fact - there is
not a single use case I am going to use existing implementation instead
of rolling one of my own. Call me a pervert but when standard library
type can't be used for something it was initially proposed for it does
smell like a failure.

But it can be used. You are quick to claim "failure" just because you
can't bring yourself to use a simple idiom. Type the blessed string and
you're done.

So my understanding is your reasoning goes like this:

alias Dollar = Typedef!double; // fantastic
alias Dollar = Typedef!(double, "Dollar"); // failure

I would agree it's not as convenient as a built-in language feature, but
it's eminently usable and in fact quite nice because it gives you access
to a nice moniker that can be used, e.g.

alias Dollar = Typedef!(double, "$"); // yum

In the latter case you go on your own and write a bunch of code because
you refuse to... type a few characters. I hope you understand why it's
difficult to carry any compelling point with such arguments.


Andrei

[bearophile via Digitalmars-d]

Post by Andrei Alexandrescu via Digitalmars-d
But it can be used.

Have you used it in your real D code three or more times? I have
tried and I have found many problems.

Bye,
bearophile

[Andrei Alexandrescu via Digitalmars-d]

Post by bearophile via Digitalmars-d

Post by Andrei Alexandrescu via Digitalmars-d
But it can be used.

Have you used it in your real D code three or more times?

No, but that doesn't mean much.

Post by bearophile via Digitalmars-d
I have tried
and I have found many problems.

Then fix them. Most of the stuff at
https://issues.dlang.org/buglist.cgi?f1=short_desc&list_id=106755&o1=casesubstring&query_format=advanced&resolution=---&v1=Typedef
is trivially fixable. Should take you all of a morning to fix most or
all of those. Just do it!


Andrei

[bearophile via Digitalmars-d]

Post by Andrei Alexandrescu via Digitalmars-d

Post by bearophile via Digitalmars-d
Have you used it in your real D code three or more times?

No, but that doesn't mean much.

It means that I have more experience than you in using Typedef,
and in my experience their usage is not so good.

Bye,
bearophile

[Andrei Alexandrescu via Digitalmars-d]

Post by Andrei Alexandrescu via Digitalmars-d

Post by bearophile via Digitalmars-d
Have you used it in your real D code three or more times?

No, but that doesn't mean much.

It means that I have more experience than you in using Typedef, and in
my experience their usage is not so good.

Aye. What I meant was "it doesn't mean Typedef is unusable; I just
didn't need for that particular facility".

What I'm saying after skimming
https://issues.dlang.org/buglist.cgi?f1=short_desc&list_id=106755&o1=casesubstring&query_format=advanced&resolution=---&v1=Typedef
is that all or at least most issues are trivial to fix.

My perception of this thread is that there's an abundance of that
misleading vividness fallacy
(http://en.wikipedia.org/wiki/Misleading_vividness). Rhetoric techniques
blow the most trivial matters out of proportion and build to the foaming
co(ncl|f)usion that "less convenient than a baked-in facility" really
means "unusable". I don't care for that kind of argument.

Fix that stuff, go your merry way and use Typedef.


Andrei

[Timon Gehr via Digitalmars-d]

My perception of this thread is that there's an abundance of that misleading vividness
fallacy (http://en.wikipedia.org/wiki/Misleading_vividness). Rhetoric techniques blow
the most trivial matters out of proportion and build to the foaming co(ncl|f)usion
that "less convenient than a baked-in facility" really means "unusable".
I don't care for that kind of argument.

Make sure to not fall prey to
http://en.wikipedia.org/wiki/Argument_from_fallacy though.

I don't mind the capitalization, ad hominem, etc. The arguments against
Typedef are honestly terrible (by all participants), ...

Some participants have pointed out (some more vivdly than others) that
it is less convenient and less sane than a trivial library alternative
using e.g. template mixins. There's currently simply too much incentive
to roll one's own that does the job better if the functionality is at
all required. That's not a "terrible" argument.

[Timon Gehr via Digitalmars-d]

Post by Andrei Alexandrescu via Digitalmars-d

Post by Timon Gehr via Digitalmars-d
....
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?

Post by Andrei Alexandrescu via Digitalmars-d
but probably not worth fighting.

"Then don't bring it up." :o)

Post by Andrei Alexandrescu via Digitalmars-d
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.

Post by Andrei Alexandrescu via Digitalmars-d
Making them magically distinct ...

(Straw man.)

Post by Andrei Alexandrescu via Digitalmars-d
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;
}//)

Post by Andrei Alexandrescu via Digitalmars-d
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.

Post by Andrei Alexandrescu via Digitalmars-d
...
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.)

[bearophile via Digitalmars-d]

Post by Freddy via Digitalmars-d

Post by Andrei Alexandrescu via Digitalmars-d
alias A = Typedef!(float, "dollar");
alias B = Typedef!(float, "euro");
...

import std.typecons;
alias A = Typedef!(float, float.init, "dollar");
alias B = Typedef!(float, float.init, "euro");

See:
https://d.puremagic.com/issues/show_bug.cgi?id=11828

Some other open issues/ERs:
https://issues.dlang.org/buglist.cgi?f1=short_desc&o1=casesubstring&query_format=advanced&resolution=---&v1=Typedef

Bye,
bearophile

[Andrei Alexandrescu via Digitalmars-d]

Post by Timon Gehr via Digitalmars-d

Post by Andrei Alexandrescu via Digitalmars-d

Post by Timon Gehr via Digitalmars-d
....
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?

Post by Andrei Alexandrescu via Digitalmars-d
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.

Post by Timon Gehr via Digitalmars-d

Post by Andrei Alexandrescu via Digitalmars-d
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");
...

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.)

Post by Timon Gehr via Digitalmars-d
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?

Post by Timon Gehr via Digitalmars-d

Post by Andrei Alexandrescu via Digitalmars-d
They will be distinct to the human and compiler alone.
...

alias A = Typedef!(int, -1, "handle");
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.

Post by Timon Gehr via Digitalmars-d
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

[Freddy via Digitalmars-d]

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")

[Freddy via Digitalmars-d]

Post by Freddy via Digitalmars-d
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