https://issues.dlang.org/show_bug.cgi?id=13084

--- Comment #21 from Kenji Hara <k.hara.pg@gmail.com> ---
(In reply to Walter Bright from comment #15)
> (In reply to Kenji Hara from comment #13)
> > All D programmers would assume that unqualified type name T is a mutable type,
> 
> There were some bumps in transitioning to the immutable alias 'string',

Note that, string == immutable(char)[], it is _mutable_ array of immutable
elements. It's different.

--

https://issues.dlang.org/show_bug.cgi?id=13084

--- Comment #22 from David Nadlinger <code@klickverbot.at> ---
I posted a little overview of the situation at the druntime pull request page.

--

https://issues.dlang.org/show_bug.cgi?id=13084

Dicebot <public@dicebot.lv> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |public@dicebot.lv

--- Comment #23 from Dicebot <public@dicebot.lv> ---
> All D programmers would assume that unqualified type name T is a mutable type, and const(T) is const, immutable(T) is immutable.

What? Sounds like total nonsense. I use aliases of qualified types all the time, it is a very useful tool for enforcing certain qualified semantics. Programmers that expect that must have never read the docs.

I think it is a reasonable solution.

--

https://issues.dlang.org/show_bug.cgi?id=13084

--- Comment #24 from Kenji Hara <k.hara.pg@gmail.com> ---
(In reply to Dicebot from comment #23)
> > All D programmers would assume that unqualified type name T is a mutable type, and const(T) is const, immutable(T) is immutable.
> 
> What? Sounds like total nonsense. I use aliases of qualified types all the time, it is a very useful tool for enforcing certain qualified semantics. Programmers that expect that must have never read the docs.
> 
> I think it is a reasonable solution.

In your code, you can have such aliases. But don't add such alias in standard library code. It will introduce much limited situation than benefits.

For example, in the proposal original mutable name _ModuleInfo is private and inaccessible. So if a programmer want to use const ModuleInfo, he should write it like const(Unqual!ModuleInfo). Why Unqual is necessary? In other words, you assumes that most D programmers won't use non-immutable ModuleInfo in their code. I think it's not reasonable assumption.

--

https://issues.dlang.org/show_bug.cgi?id=13084

--- Comment #25 from Walter Bright <bugzilla@digitalmars.com> ---
Let's list a few objective facts:

1. The current situation (this bug report) occurs in the wild in real code in more than one project. Existing code is broken.

2. https://issues.dlang.org/show_bug.cgi?id=13148 has not been shown to occur anywhere in existing code, it is conjecture. A reason to write such code has not been demonstrated.

3. If there is a reason to write 13148 code, it can be fixed with the Unqual!ModuleInfo change.

4. In either solution, using ModuleInfo incorrectly will result in compiler errors, not silent corruption.


Therefore it seems highly likely that there will be far more instances of requiring users to write immutable(ModuleInfo) than Unqual!ModuleInfo. Making ModuleInfo an immutable alias thus breaks far less existing code.

(Inferring that an unadorned type name would necessarily be mutable comes as a surprise to me. This assumption is not stated anywhere in the documentation nor in common usage. A grep of phobos/std shows immutable aliases occurring. It's one of the things alias is for.)

--

https://issues.dlang.org/show_bug.cgi?id=13084

--- Comment #26 from Dicebot <public@dicebot.lv> ---
> In your code, you can have such aliases. But don't add such alias in standard library code. It will introduce much limited situation than benefits.

This is just your preference, there is nothing standard about it. Such solution is introduced exactly to impose limits and make using unqualified type harder. Forcing certain type to be always used as immutable is not unheard of which also means that you don't normally need const version of same type - because, well, it is always meant to be immutable.

On actual topic: is there any reason why ModuleInfo itself needs to be immutable and marking all its data members is not enough? That should still make all the the options from PR #790 valid or am I missing something?

--

https://issues.dlang.org/show_bug.cgi?id=13084

--- Comment #27 from Jacob Carlborg <doob@me.com> ---
(In reply to Dicebot from comment #26)

> On actual topic: is there any reason why ModuleInfo itself needs to be immutable and marking all its data members is not enough? That should still make all the the options from PR #790 valid or am I missing something?

Exactly, I've already asked that but didn't get a reply on that question. Is it possible to write to the pointer that will cause problems?

--

https://issues.dlang.org/show_bug.cgi?id=13084

--- Comment #28 from Walter Bright <bugzilla@digitalmars.com> ---
(In reply to Jacob Carlborg from comment #27)
> (In reply to Dicebot from comment #26)
> 
> > On actual topic: is there any reason why ModuleInfo itself needs to be immutable and marking all its data members is not enough? That should still make all the the options from PR #790 valid or am I missing something?
> 
> Exactly, I've already asked that but didn't get a reply on that question. Is it possible to write to the pointer that will cause problems?

ModuleInfo is a variable sized struct that is decoded at runtime. The two explicit fields are only the start of it. Making the whole thing immutable makes the intent clear.

--

https://issues.dlang.org/show_bug.cgi?id=13084

--- Comment #29 from Dicebot <public@dicebot.lv> ---
Is it possible to apply usual C idiom for variadic length structs? Something like this:

struct ModuleInfo
{
    immutable:
       uint _flags;
       uint _index;
       void[0] payload;
    /* methods */
}

I am not sure it is legal application of immutable qualifier though.

--

https://issues.dlang.org/show_bug.cgi?id=13084

Martin Nowak <code@dawg.eu> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |code@dawg.eu

--- Comment #30 from Martin Nowak <code@dawg.eu> ---
(In reply to Dicebot from comment #26)
> On actual topic: is there any reason why ModuleInfo itself needs to be immutable and marking all its data members is not enough? That should still make all the the options from PR #790 valid or am I missing something?

Well, without breaking the type system, the runtime only has access to an array of immutable pointers to ModuleInfos.

--