inferred vs. annotated attributes

[Q. Schroll via Digitalmars-d-learn]

On Saturday, 10 September 2016 at 09:38:15 UTC, Lodovico Giaretta 
wrote:
> On Saturday, 10 September 2016 at 08:23:35 UTC, Q. Schroll 
> wrote:
>> Is there a difference between inferred and annotated 
>> attributes?
>> Example:
>>
>>     struct X(T)
>>     {
>>         this(S)(in S[] arr) // inferred pure
>>         { }
>>     }
>>
>>     void main() pure
>>     {
>>         X!uint mut = [ 1, 2 ]; // proves inference (cf. main 
>> is pure)
>>         // immutable X!uint imm1 = [ 1, 2 ];
>>         // auto imm2 = immutable X!uint([1, 2]);
>>     }
>>
>> The commented lines yield error messages claiming the 
>> constructor cannot deduce function from argument types 
>> !()(int[]) immutable, however it can, if "pure" is explicitly 
>> annotated.
>>
>> Is this a bug or did I get something wrong about inference / 
>> unique expressions?
>
> A method (included ctors) that is not annotated const, nor 
> immutable, nor inout, is implicitly mutable. This implies that 
> your ctor is mutable, and as such it cannot create immutable 
> instances.

IIRC, a pure ctor can construct any objects (including immutable 
and shared).

> If you add another ctor marked immutable, everything works. An 
> alternative is to mark the ctor as inout.

Technically I know. The minimal example only explains the 
problem/bug. My real constructor does do things where I don't 
want inout attributes if I can avoid.

> I tested this solution and it works, but I'm not sure if it is 
> by design.

Sure. It did for me, too.

The question is: Why does annotating an inferred attribute make a 
difference? (Or it doesn't and I don't see it all the time.)