http://d.puremagic.com/issues/show_bug.cgi?id=3449


Walter Bright <bugzilla@digitalmars.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|spec                        |


--- Comment #10 from Walter Bright <bugzilla@digitalmars.com> 2012-01-23 01:39:58 PST ---
(In reply to comment #0)
> When struct members are declared const or invariant, they seem to become
> manifest constants. Example:
>   struct Foo { const int bar = 123; }
>   writeln(Foo.sizeof);   // Prints "1", not "4"
>   Foo foo;
>   auto p = &foo.bar;     // Error: constant 123 is not an lvalue

Taking the address should work. Compiler bug, not a spec issue.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=3449



--- Comment #11 from Kenji Hara <k.hara.pg@gmail.com> 2012-01-23 04:28:52 PST ---
(In reply to comment #9)
> This is as designed. A const field without an initializer can be initialized by a constructor. A const field with an initializer does not need any per-instance storage, and becomes a static member.

> It is not a bug, it is as designed. (const in D and C are different, and conflating the two will cause problems anyway)

(In reply to comment #10)
> Taking the address should work. Compiler bug, not a spec issue.

I think that  the *implicit static* variable is the worst specification in D. 'const/immutable(not modifiable)' and 'static(not per-instance)' is definitely orthogonal concepts, but in your argument, they are scary mixed.

So, if we want to need static variable, language *must* require 'static' storage class for the purpose. Otherwise, it will force us a big (and meaningless) leap of imaging.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=3449



--- Comment #12 from Stewart Gordon <smjg@iname.com> 2012-01-23 05:16:02 PST ---
(In reply to comment #11)
> I think that  the *implicit static* variable is the worst specification in D.  'const/immutable(not modifiable)' and 'static(not per-instance)' is definitely orthogonal concepts, but in your argument, they are scary mixed.

Agreed.  Half the point of structs is that the layout in memory can be guaranteed.  Being able to include immutable values within this memory layout (such as struct size in the case of some Windows API structs, or file format signatures) should be part of this.

In classes, where there is no guarantee of memory layout, it makes sense to optimise immutable members to be static.  In structs, OTOH, const/immutable should do what it says and nothing more.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=3449


Masahiro Nakagawa <repeatedly@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |repeatedly@gmail.com


--- Comment #13 from Masahiro Nakagawa <repeatedly@gmail.com> 2012-05-11 18:30:07 PDT ---
I hit this issue in my new library.

I have a following struct.

  struct Option
  {
    string name;
    string[] fields;
    immutable type = "hoge";
  }

My library automatically converts such struct to JSON.
But "type" field does not exist (tupleof does not return immutable field).

  expect:

  {"fields": ["a'], "unique": false, "type": "hoge"}

  actual:

  {"fields": ["a'], "unique": false}

Currently, I remove immutable keyword temporally but 'type' should be immutable.

Is there a better solution?

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=3449


David Piepgrass <qwertie256@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |qwertie256@gmail.com


--- Comment #14 from David Piepgrass <qwertie256@gmail.com> 2012-07-25 13:42:36 PDT ---
+1 from me. Implicit static and (worse) implicit enum are bad ideas, and the worst part is that whether it's static or not depends on whether there is an initializer or not. (admittedly I am left wondering what the difference is between "const int" and "immutable int", is it relevant?)

However, as a compromise, perhaps if the user writes "const int x = 7;" the compiler could warn: "warning: since x is a constant, it should be declared with static or enum to avoid wasting memory."

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=3449



--- Comment #15 from Stewart Gordon <smjg@iname.com> 2012-07-25 14:55:34 PDT ---
(In reply to comment #14)
> +1 from me. Implicit static and (worse) implicit enum are bad ideas, and the worst part is that whether it's static or not depends on whether there is an initializer or not.

I entirely agree.

> (admittedly I am left wondering what the difference is between "const int" and "immutable int", is it relevant?)

There isn't any real difference on the surface.  But when you take the address of one, you get quite different types.

> However, as a compromise, perhaps if the user writes "const int x = 7;" the compiler could warn: "warning: since x is a constant, it should be declared with static or enum to avoid wasting memory."

How would the programmer suppress this warning because it's deliberate?

Maybe we need a new attribute for this.  This would also enable an immutable value to be part of a struct's layout without breaking existing code.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=3449



--- Comment #16 from David Piepgrass <qwertie256@gmail.com> 2012-07-25 18:55:01 PDT ---
> How would the programmer suppress this warning because it's deliberate?

When I wrote that, I was thinking that the developer can initialize in the constructor if he really wants it to be non-static. But now I remember that structs can't have a default constructor.

Personally I think coders should be able to suppress warnings inside a pragma. But I think I heard Walter doesn't like that. Nevertheless it could easily be a mistake to use "const int Foo = 7;" instead of "enum" or "static const int", and the developer usually won't find out about the mistake without a warning.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=3449



--- Comment #17 from Stewart Gordon <smjg@iname.com> 2012-07-26 06:14:15 PDT ---
(In reply to comment #16)
> > How would the programmer suppress this warning because it's deliberate?
> 
> When I wrote that, I was thinking that the developer can initialize in the constructor if he really wants it to be non-static. But now I remember that structs can't have a default constructor.

Indeed.  Moreover, being able to set the value just once in the code, in the member declaration, could be used to address the ongoing problem with structs and const-safety by deciding that a struct with a const/immutable member can be reassigned as long as said member's value is a compile-time constant (in the absence of other constraints preventing it).

> Personally I think coders should be able to suppress warnings inside a pragma. But I think I heard Walter doesn't like that.

The tradition in C++ has been that typical compiler warnings can be suppressed
by making changes at the code level, for example:
- code has no effect - comment it out or cast it to void
- unreachable code - comment it out
- unused parameter - don't name it
- implicit narrowing conversions - use an explicit cast
- counter-intuitive operator precedence - use brackets

It might be that Walter wants to follow this tradition.  Or down to problems with the design of D pragmas.

> Nevertheless it could easily be a
> mistake to use "const int Foo = 7;" instead of "enum" or "static const int",
> and the developer usually won't find out about the mistake without a warning.

It could just as easily, if not more, be an attempt to use that declaration thinking it'll actually put that member in the structure's memory layout.  An example would be to take a Windows API struct and modify the definition to hard-code that first member that is just the struct's size.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=3449



--- Comment #18 from github-bugzilla@puremagic.com 2012-11-22 03:30:39 PST ---
Commit pushed to master at https://github.com/D-Programming-Language/phobos

https://github.com/D-Programming-Language/phobos/commit/245274b4083cfc26e45111673b6264151f29abbe Merge pull request #965 from 9rnsr/fix3449

Supplemental fix for Issue 3449 - Stop fwdref by the immutable field

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=3449



--- Comment #19 from Andrej Mitrovic <andrej.mitrovich@gmail.com> 2012-12-26 14:27:45 PST ---
*** Issue 4203 has been marked as a duplicate of this issue. ***

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------