Thread overview
Avoid attribute soup by doing attribute-infering for function(s) of template type
Jan 29
An Pham
Jan 29
An Pham
Jan 30
Kagamin
January 29

Sample below, F.get, get error for class expected but OK for value type (no indirect type). D needs to do attribute inference (const nothrow pure @safe) for function(s) within template type

module X;

@safe:

struct F(T)
{
    T[] data;

    T get(size_t i) const nothrow @safe
    {
        return data[i];
    }
}

struct T1
{
    int x;
}

class T2
{
    int x;
}

void main()
{
    import std.stdio;

    F!T1 t1;
    writeln(t1.get(0));

    F!T2 t2;
    writeln(t2.get(0));
    /*
onlineapp.d(11): Error: cannot implicitly convert expression `this.data[i]` of type `const(T2)` to `X.T2`
onlineapp.d(32): Error: template instance `X.F!(T2)` error instantiating
	*/
}
January 29

On Wednesday, 29 January 2025 at 20:43:47 UTC, An Pham wrote:

>

Sample below, F.get, get error for class expected but OK for value type (no indirect type). D needs to do attribute inference (const nothrow pure @safe) for function(s) within template type

  1. D already does inference of @safe, pure, nothrow, and @nogc for functions within template types. (const, however, is never inferred, under any circumstances.)

  2. I don't see anything wrong in your example. Conversion of value types without indirections from const to non-const is documented in the language spec.

January 29

On Wednesday, 29 January 2025 at 21:10:53 UTC, Paul Backus wrote:

>

On Wednesday, 29 January 2025 at 20:43:47 UTC, An Pham wrote:

>

Sample below, F.get, get error for class expected but OK for value type (no indirect type). D needs to do attribute inference (const nothrow pure @safe) for function(s) within template type

  1. D already does inference of @safe, pure, nothrow, and @nogc for functions within template types. (const, however, is never inferred, under any circumstances.)

  2. I don't see anything wrong in your example. Conversion of value types without indirections from const to non-const is documented in the language spec.

The problem for 'const' is that it is transitive. Without adding it, it has problem using from 'const' caller but adding 'const' will prohibit it used in 'class' type

January 30

On Wednesday, 29 January 2025 at 22:24:56 UTC, An Pham wrote:

>

The problem for 'const' is that it is transitive. Without adding it, it has problem using from 'const' caller but adding 'const' will prohibit it used in 'class' type

You can make it work for classes by making the return type const(T):

const(T) get(size_t i) const nothrow @safe
{
    return data[i];
}

This way, the types match, and no conversion is necessary.

January 30

You probably want inout here, it infers const qualifiers.

     struct F(T)
     {
         T[] data;

         inout(T) get(size_t i) inout nothrow @safe
         {
             return data[i];
         }
     }
February 04

On Wednesday, 29 January 2025 at 21:10:53 UTC, Paul Backus wrote:

>

On Wednesday, 29 January 2025 at 20:43:47 UTC, An Pham wrote:

>

Sample below, F.get, get error for class expected but OK for value type (no indirect type). D needs to do attribute inference (const nothrow pure @safe) for function(s) within template type

  1. D already does inference of @safe, pure, nothrow, and @nogc for functions within template types. (const, however, is never inferred, under any circumstances.)

  2. I don't see anything wrong in your example. Conversion of value types without indirections from const to non-const is documented in the language spec.

I know that it’s not what was meant, but you can use template a this parameter to infer const from the calling object.