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?

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.

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

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

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.)

On 09/10/2016 10:23 AM, 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?

Bug, or at least a very reasonable enhancement request. Inferred attributes should work just like explicit ones.