September 17, 2014
On 9/17/2014 2:37 AM, Walter Bright wrote:
> 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.
September 17, 2014
You can use module name and line number as unique tag.
September 17, 2014
On Wednesday, 17 September 2014 at 10:00:31 UTC, Jack Applegame wrote:
> 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?
September 17, 2014
Dicebot:

> 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
September 17, 2014
On Wednesday, 17 September 2014 at 16:54:09 UTC, bearophile wrote:
> Dicebot:
>
>> 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).
September 17, 2014
On 9/17/2014 9:54 AM, bearophile wrote:
> Dicebot:
>
>> 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.)

September 17, 2014
On Wednesday, 17 September 2014 at 17:16:55 UTC, Walter Bright wrote:
> 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.
September 17, 2014
On Wednesday, 17 September 2014 at 05:40:22 UTC, H. S. Teoh via Digitalmars-d wrote:
> On Wed, Sep 17, 2014 at 03:05:57AM +0000, Adam D. Ruppe via Digitalmars-d wrote:
>> 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
September 17, 2014
On Wed, Sep 17, 2014 at 08:49:02PM +0000, Piotrek via Digitalmars-d wrote:
> On Wednesday, 17 September 2014 at 05:40:22 UTC, H. S. Teoh via Digitalmars-d wrote:
> >On Wed, Sep 17, 2014 at 03:05:57AM +0000, Adam D. Ruppe via Digitalmars-d wrote:
> >>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

-- 
Why can't you just be a nonconformist like everyone else? -- YHL
September 17, 2014
On Wednesday, 17 September 2014 at 21:03:26 UTC, H. S. Teoh via Digitalmars-d wrote:
> On Wed, Sep 17, 2014 at 08:49:02PM +0000, Piotrek via Digitalmars-d wrote:
>> On Wednesday, 17 September 2014 at 05:40:22 UTC, H. S. Teoh via
>> Digitalmars-d wrote:
>> >On Wed, Sep 17, 2014 at 03:05:57AM +0000, Adam D. Ruppe via Digitalmars-d
>> >wrote:
>> >>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