On Thu, Aug 08, 2013 at 06:47:48PM -0400, Jonathan M Davis wrote:
> On Thursday, August 08, 2013 15:40:25 H. S. Teoh wrote:
> > Are we going to fix this anytime soon (or at all)? If not, we'd better start documenting this, since currently enums are being sold as manifest constants, and most people would understand that as meaning it's only allocated once at compile-time/startup-time. It would leave a very bad impression if new users unknowingly end up with a lot of unwanted allocations just from using a language feature as-advertised.
> 
> There's nothing to fix. It's by design. That _is_ what a manifest constant is as far as D is concerned. And if you search for manifest constants online, you end up running into stuff that talks about #define in C, which does the same thing. So, I don't think that we're doing anything abnormal here. We just have to make sure that it's clear in the documentation that that's how manifest constants work. I don't know what the documentation currently says though.
[...]

Seriously, I think we should hire a tech writer. The way we manage our docs just ... leaves a lot to be desired. It's very unclear to newcomers, and even to someone who's been working with D for a while, like myself.

In fact, I'm going to update http://wiki.dlang.org/Declaring_constants right now, to reflect this caveat. Maybe I'll submit a pull for the language docs.

But honestly, I can totally understand why many people find D docs very frustrating. In fact, I found the online docs so unhelpful when I first found D, that it delayed my adopting D for at least half a year until one day I saw TDPL in a local bookstore and decided to buy it. A friend of mine has told me, in private, that after trying out D he liked the language, but one of the things he decidedly did NOT like was the docs. I think the only real solution to this is to hire a full-time tech writer to do the documentation, and do it *properly*. We're doing a great language a great disservice by documenting it so poorly.


T

-- 
Having a smoking section in a restaurant is like having a peeing section in a swimming pool. -- Edward Burr

On Thursday, August 08, 2013 16:05:24 H. S. Teoh wrote:
> On Thu, Aug 08, 2013 at 06:47:48PM -0400, Jonathan M Davis wrote:
> > On Thursday, August 08, 2013 15:40:25 H. S. Teoh wrote:
> > > Are we going to fix this anytime soon (or at all)? If not, we'd better start documenting this, since currently enums are being sold as manifest constants, and most people would understand that as meaning it's only allocated once at compile-time/startup-time. It would leave a very bad impression if new users unknowingly end up with a lot of unwanted allocations just from using a language feature as-advertised.
> > 
> > There's nothing to fix. It's by design. That _is_ what a manifest constant is as far as D is concerned. And if you search for manifest constants online, you end up running into stuff that talks about #define in C, which does the same thing. So, I don't think that we're doing anything abnormal here. We just have to make sure that it's clear in the documentation that that's how manifest constants work. I don't know what the documentation currently says though.
> 
> [...]
> 
> Seriously, I think we should hire a tech writer. The way we manage our docs just ... leaves a lot to be desired. It's very unclear to newcomers, and even to someone who's been working with D for a while, like myself.
> 
> In fact, I'm going to update http://wiki.dlang.org/Declaring_constants right now, to reflect this caveat. Maybe I'll submit a pull for the language docs.
> 
> But honestly, I can totally understand why many people find D docs very frustrating. In fact, I found the online docs so unhelpful when I first found D, that it delayed my adopting D for at least half a year until one day I saw TDPL in a local bookstore and decided to buy it. A friend of mine has told me, in private, that after trying out D he liked the language, but one of the things he decidedly did NOT like was the docs. I think the only real solution to this is to hire a full-time tech writer to do the documentation, and do it *properly*. We're doing a great language a great disservice by documenting it so poorly.

A lot of the problem stems from the fact that most of the devs don't do anything with the documenation. We tend to focus on the code and forget about the documentation. Maybe we need someone to champion the documentation and at least organize what needs to be done with it if not take the time themselves to fix it.

The other big issue would probably be the fact that it's also treated as the spec for the language, and you don't write the same kind of documentation when you're writing a spec as when you're writing something to teach people (not that D's docs are quite what a spec requires either, as they don't tend to be precise enough, but they tend to lean heavily in that direction and aren't even vaguely meant as tutorials).

- Jonathan M Davis

On Fri, Aug 09, 2013 at 01:19:44AM +0200, bearophile wrote:
> Ali Çehreli:
> 
> >More than that. :) enums are manifest constants.
> >
> >Imagine that enum as being pasted into source code as is. This used to have surprising effects for AAs, as an enum AA would be instantiated from scratch everywhere that AA enum was used in the code.
> 
> I think that some time ago Don has proposed to disallow the 'enum' tag for things like AAs, on the base that such behavour is not efficient, surprising, and maybe even not useful... I don't know where his proposal has gone later.
[...]

I think we should disallow it. It's surprising behaviour for someone who doesn't know how it's implemented.


T

-- 
It always amuses me that Windows has a Safe Mode during bootup. Does that mean that Windows is normally unsafe?

On Thu, Aug 08, 2013 at 10:00:08PM -0400, Jonathan M Davis wrote:
> On Thursday, August 08, 2013 16:05:24 H. S. Teoh wrote:
[...]
> > But honestly, I can totally understand why many people find D docs very frustrating. In fact, I found the online docs so unhelpful when I first found D, that it delayed my adopting D for at least half a year until one day I saw TDPL in a local bookstore and decided to buy it. A friend of mine has told me, in private, that after trying out D he liked the language, but one of the things he decidedly did NOT like was the docs.  I think the only real solution to this is to hire a full-time tech writer to do the documentation, and do it *properly*. We're doing a great language a great disservice by documenting it so poorly.
> 
> A lot of the problem stems from the fact that most of the devs don't do anything with the documenation. We tend to focus on the code and forget about the documentation. Maybe we need someone to champion the documentation and at least organize what needs to be done with it if not take the time themselves to fix it.

Yeah, that's why I said we should hire a full-time tech writer. We coders are notoriously bad at writing docs. We're too familiar with the code, and unconsciously make unstated assumptions that others don't know about, so the little docs that we *do* write tend to be hard for newbies to understand. I don't see any other way to solve this problem... it's a common malady among opensource projects.


> The other big issue would probably be the fact that it's also treated as the spec for the language, and you don't write the same kind of documentation when you're writing a spec as when you're writing something to teach people (not that D's docs are quite what a spec requires either, as they don't tend to be precise enough, but they tend to lean heavily in that direction and aren't even vaguely meant as tutorials).
[...]

When is the Akeron project coming to fruition? ;-)

One of these days, we need to go back through the D-learn archives and collect frequently-encountered problems by newbies, and write suitable tutorials for them (say on the wiki or something).


T

-- 
Having a smoking section in a restaurant is like having a peeing section in a swimming pool. -- Edward Burr

So if I want to have a string constant it is a lot better to declare it as:

static immutable string MY_STRING = "Some string";

Because it won't be duplicated?

On 08/19/2013 03:18 AM, Borislav Kosharov wrote:> So if I want to have a string constant it is a lot better to declare it as:
>
> static immutable string MY_STRING = "Some string";
>
> Because it won't be duplicated?

enum is fine with strings.

It is a common space optimization of the compilers not to duplicate identical strings. The following program includes just one "hello world" in the compiled object file:

import std.stdio;

enum atModuleLevel = "hello world";

void foo()
{
    writefln(atModuleLevel);
}

void main()
{
    enum s = "hello world";
    writeln(s);
    writeln(s);
    writeln(atModuleLevel);
    foo();
}

Ali

On Monday, August 19, 2013 12:18:36 Borislav Kosharov wrote:
> So if I want to have a string constant it is a lot better to declare it as:
> 
> static immutable string MY_STRING = "Some string";
> 
> Because it won't be duplicated?

Even if you copy-pasted "Some string" in your code thousands of times, only one string is allocated, which is one of the advantages of strings being immutable (the compiler can get away with allocating memory for string literals only once). But other array literals _do_ result in a new array allocated every time that they're in the code, and when you use an enum, its value is copy-pasted every place that it's used, resulting in a new allocation every time that it's used.

So, using string enums is fine, but using other arrays as enums is usually a bad idea.

- Jonathan M Davis

On Monday, 19 August 2013 at 23:14:12 UTC, Jonathan M Davis wrote:
> On Monday, August 19, 2013 12:18:36 Borislav Kosharov wrote:
>> So if I want to have a string constant it is a lot better to
>> declare it as:
>> 
>> static immutable string MY_STRING = "Some string";
>> 
>> Because it won't be duplicated?
>
> Even if you copy-pasted "Some string" in your code thousands of times, only
> one string is allocated, which is one of the advantages of strings being
> immutable (the compiler can get away with allocating memory for string
> literals only once). But other array literals _do_ result in a new array
> allocated every time that they're in the code, and when you use an enum, its
> value is copy-pasted every place that it's used, resulting in a new allocation
> every time that it's used.
>
> So, using string enums is fine, but using other arrays as enums is usually a
> bad idea.
>
> - Jonathan M Davis

I think one exception to this is when you index an enum. EG:
enum vals=[1, 2, 3, 0];

auto a = vals[i];

Here, the compiler will not make an allocation (at least, it didn't last time I tested)

On Tuesday, 20 August 2013 at 09:38:35 UTC, monarch_dodra wrote:
> On Monday, 19 August 2013 at 23:14:12 UTC, Jonathan M Davis wrote:
>> On Monday, August 19, 2013 12:18:36 Borislav Kosharov wrote:
>>> So if I want to have a string constant it is a lot better to
>>> declare it as:
>>> 
>>> static immutable string MY_STRING = "Some string";
>>> 
>>> Because it won't be duplicated?
>>
>> Even if you copy-pasted "Some string" in your code thousands of times, only
>> one string is allocated, which is one of the advantages of strings being
>> immutable (the compiler can get away with allocating memory for string
>> literals only once). But other array literals _do_ result in a new array
>> allocated every time that they're in the code, and when you use an enum, its
>> value is copy-pasted every place that it's used, resulting in a new allocation
>> every time that it's used.
>>
>> So, using string enums is fine, but using other arrays as enums is usually a
>> bad idea.
>>
>> - Jonathan M Davis
>
> I think one exception to this is when you index an enum. EG:
> enum vals=[1, 2, 3, 0];
>
> auto a = vals[i];
>
> Here, the compiler will not make an allocation (at least, it didn't last time I tested)

is there an allocation in this?

enum vals=[1, 2, 3, 0];

int[4] a;
a[] = vals[];

On Tuesday, August 20, 2013 11:38:34 monarch_dodra wrote:
> I think one exception to this is when you index an enum. EG: enum vals=[1, 2, 3, 0];
> 
> auto a = vals[i];
> 
> Here, the compiler will not make an allocation (at least, it
> didn't last time I tested)

It probably does an optimtization based on constant folding or somesuch. And I'm sure that there are other cases where the compiler could theoretically optimize some array allocations, but in general, I wouldn't bet on dmd being that smart at this point.

- Jonathan M Davis