Walter Bright wrote:

> Jason House wrote:
>> Has the const/invariant/enum documentation been updated yet?
>> Looking at http://www.digitalmars.com/d/const3.html, there is no mention
>> of
>> enum.  It does discuss manifest constants...
>> 
>> Can you please update the docs to reflect the new design?
> 
> See http://www.digitalmars.com/d/enum.html for the enum stuff.

... so you're saying that I can define manifest constants in several different ways?  Quoting the online docs:

"The simplest invariant declarations use it as a storage class. It can be
used to declare manifest constants.
invariant int x = 3;    // x is set to 3"

I thought manifest constants were going to be made more explicit.  That way, it's known when taking an address of something is valid.  Afterall, the docs also say:

"Invariant used as a storage class is equivalent to using invariant as a
type constructor for the entire type of a declaration:
invariant int x = 3;   // x is typed as invariant(int)
invariant(int) y = 3;  // y is invariant"

... after all the discussion about const/invariant/manifest, I think the docs should be very clear on this topic.  I don't want to see more long threads about manifest constants.

Jason House wrote:
> Walter Bright wrote:
> 
>> Jason House wrote:
>>> Has the const/invariant/enum documentation been updated yet?
>>> Looking at http://www.digitalmars.com/d/const3.html, there is no mention
>>> of
>>> enum.  It does discuss manifest constants...
>>>
>>> Can you please update the docs to reflect the new design?
>> See http://www.digitalmars.com/d/enum.html for the enum stuff.
> 
> ... so you're saying that I can define manifest constants in several
> different ways?  Quoting the online docs:
> 
> "The simplest invariant declarations use it as a storage class. It can be
> used to declare manifest constants.
> invariant int x = 3;    // x is set to 3"
> 
> I thought manifest constants were going to be made more explicit.  That way,
> it's known when taking an address of something is valid.  Afterall, the
> docs also say:
> 

Yes, I saw that too.  I'm guessing that Walter was saying here that an invariant /also/ can be used as a sort of manifest constant declaration. .. not of the formal sort like that of the "anonymous enum"; but people might like to take advantage of the invariants immutability for such a purpose... and so the same with "const".

I wager these are the 4 ways to do manifests that Walter was referring to in earlier posts: invariant, const, named enum, and anonymous enum - the last being the "true" manifest constant.  That's why he felt he shouldn't have to add another keyword to replace the anonymous enum version if he could just stretch enum a bit more at the seams. (incidentally, notice that the four ways still exist).

But are these four ways equivalent and the link level?  I don't think so. My question is whether this "type" of manifest constant takes up any symbol space in the program...you know: the way the libraries used to get bloated with D's old constants (something that seemed to circumvented with anonymous enums).  Do all these consts (when used like manifests) truly mirror the weightless "#define".  I think only the "enum" version does...unless the compiler is indeed smart enough here.

But yes, the docs do tend to mix things up a little.  Probably best to avoid referring to manifest constants in the discussion on immutables in that context.

Other than that, I was surprised that I actually seemed to be able to grasp the const/invariant section this time around.  It is fairly understandable and simply presented.  Perhaps the complexities and problems will show up in actual practice, but for now the explanations seemed well done.

-JJR

Walter Bright wrote:
> Jarrett Billingsley wrote:
>> "Walter Bright" <newshound1@digitalmars.com> wrote in message news:flebgf$1pmb$1@digitalmars.com...
>>
>>> C cx;
>>> if (someCondition)
>>> cx = new C(1);
>>> else
>>> cx = new C(2);
>>> const(C) c = cx;
>>>> ... 
>  Note that this isn't any different from what you'd write for a const int:
> 
>     int ix;
>     if (someCondition)
>     ix = 1;
>     else
>     ix = 2;
>     const(int) i = ix;
> 
> or const of any type.

It's also the same sort of rigmarole you have to go through to conditionally initialize a reference in C++ since they cannot be rebound except at initialization.  C++ programmers manage to get by with that.

But that still doesn't mean it's the ideal way to do such initializations.  In particular it looks pretty inefficient if we're talking about a BigStruct instead of an int. (I'd probably just switch to using a const pointer to refer to the BigStruct under the current rules.)

At any rate, the lack of this capability doesn't seem a big enough problem to justify scrapping the new const.  Or even to try "fixing" it with new syntax so soon before we've had the chance to get used to the new system.  If the above does turn out to be a big deal in practice, perhaps some new initializer syntax could be added to make that sort of thing easier, but it doesn't look like a deal-breaker either way.


--bb

Walter Bright pisze:
> Marcin Kuszczak wrote:
>> There is something wrong with linux libphobos2 library.
> 
> I just uploaded it again. I think I inadvertently posted the old one.

Great! Now it works perfectly.

BTW. Thanks for nice release. Personally I like new enum design. The old, traditional enum was too limited, and IMHO there was a great need for something better.

BR
Marcin Kuszczak
(aarti_pl)

Walter Bright Wrote:

> New const/invariant/enum in 2.009!
> 
> http://www.digitalmars.com/d/1.0/changelog.html http://ftp.digitalmars.com/dmd.1.025.zip
> 
> http://www.digitalmars.com/d/changelog.html http://ftp.digitalmars.com/dmd.2.009.zip

Hello and Happy New Year!

The example in the D Programming Language 2.0 root web page (http://www.digitalmars.com/d/) doesn't compile with dmd.2.008, I haven't been able to try it with the last version though.  This is one of those things whose update may be missed easily.  Exactly this same example was the first compilation I tried with the dmd compiler and I think it should welcome new developers.

Cheers!

Walter Bright wrote:
> のしいか (noshiika) wrote:
> 
> Replace:
> 
>>     const(C) c;
>>     c = new C(1); // error
> 
> with:
> 
>     const(C) c = new C(1);

Oh, then, I have to declare a variable each time I want to assign a new
value of const(class) object or a generic type, now...

John Reimer Wrote:
> I wager these are the 4 ways to do manifests that Walter was referring to in earlier posts: invariant, const, named enum, and anonymous enum - the last being the "true" manifest constant.  That's why he felt he shouldn't have to add another keyword to replace the anonymous enum version if he could just stretch enum a bit more at the seams. (incidentally, notice that the four ways still exist).
> 
> But are these four ways equivalent and the link level?  I don't think so. My question is whether this "type" of manifest constant takes up any symbol space in the program...you know: the way the libraries used to get bloated with D's old constants (something that seemed to circumvented with anonymous enums).  Do all these consts (when used like manifests) truly mirror the weightless "#define".  I think only the "enum" version does...unless the compiler is indeed smart enough here.
> 
> But yes, the docs do tend to mix things up a little.

That's really my whole point.  There's plenty of room for confusion and assumptions when reading the docs.  I feel like I keep posting stuff like "please add this to the docs", or "please clarify this in the docs".  Being a developer, I understand the pain of documentation, but it truly is important... especially for D when there's lots of people (like me) who refuse to use D 2.x until they're convinced the design is both sane and stable.  Actually, I might hold off on porting my code until the Tango + Phobos merger is (nearly?) complete.

Charles D Hixson wrote:
> Jarrett Billingsley wrote:
>> ""Jérôme M. Berger"" <jeberger@free.fr> wrote in message news:fleb1b$1ol5$1@digitalmars.com...
>>
>>> const (C) c = (someCondition) ? (new C (1)) : (new C (2)),
>>
>> OK.  I guess the point I was trying to make before is that you can't generally combine declaration and initialization.  I'm sure you can all imagine a more complex example that would be prohibitive/stupid to try to initialize in a single expression.
>>
> General solution? (untested)
> 1) define a function to return a value of the desired type and value.
> 2) use it to assign a value to a constant.
> 
> I suspect that this function might need to be static, but I seem to remember that const is intentionally limited to rom-able values, so that shouldn't be too restrictive.
> 
> It's still not as pleasant as being able to assign once.
I just re-checked the documentation, and it doesn't say that it can't be changed after compile time at all...in fact it says that it *CAN* be changed, just not via the const reference.

Fixed.

のしいか (noshiika) wrote:
> Walter Bright wrote:
>> のしいか (noshiika) wrote:
>>
>> Replace:
>>
>>>     const(C) c;
>>>     c = new C(1); // error
>>
>> with:
>>
>>     const(C) c = new C(1);
> 
> Oh, then, I have to declare a variable each time I want to assign a new
> value of const(class) object or a generic type, now...

Right. Just as if C were an int:

	const(int) i;
	i = 3;   // error

	const(int) i = 3;  // ok