From eiderdaus at gmail.com  Wed Sep  2 06:45:49 2026
From: eiderdaus at gmail.com (SimonN)
Date: Wed, 02 Sep 2026 06:45:49 +0000
Subject: [Dlang-internal] Const or invariant key in dynamic array
In-Reply-To: <oojhqppsvkhzzlpanbsl@forum.dlang.org>
References: <skjoteuzznulepjuggfb@forum.dlang.org>
 <fmzxhrqyxuactuhwskgx@forum.dlang.org> <oojhqppsvkhzzlpanbsl@forum.dlang.org>
Message-ID: <hxfaroljoevibbdsjsjj@forum.dlang.org>

On Monday, 24 August 2026 at 02:55:16 UTC, Valentino Giudice 
wrote:
> What I am suggesting is that if the key is a simple value or a 
> POD, then I should be able to use a constant or immutable key 
> value without getting a warning, as I don't see how it can lead 
> to any issue.

This deprecation warning during @safe was a bug in DMD 2.111 and 
DMD 2.112.

A fix has been available since December 2025:
https://github.com/dlang/dmd/pull/22208

The fix will make it into DMD 2.113.0. Now, the compiler will not 
print a deprecation warning anymore for this compiler-generated 
cast. It's perfectly fine for usercode to index like that in 
@safe code. Keep your code. :-)

With DMD 2.112 or older, you can work around this message by 
hiding all deprecation warnings. Pass `-d` to DMD, or set the 
`DFLAGS` environment variable to `-d` (on Linux: `export 
DFLAGS=-d`) and then build with DMD or dub.

-- Simon

From valentino.giudice96 at gmail.com  Sun Sep  6 03:21:56 2026
From: valentino.giudice96 at gmail.com (Valentino Giudice)
Date: Sun, 06 Sep 2026 03:21:56 +0000
Subject: [Dlang-internal] Corner case about inheritance and template
	functions
Message-ID: <rswqqpfnnwqazoapcutd@forum.dlang.org>

Hi all.

I am not certain this is the right forum.

If there is something big I'm missing, this should have been a 
post for "Learn". If I found a bug, it should have been a post 
for "Bugs". I'm making a guess that neither is true in this case, 
and this a suggestion about language development, so I'm posting 
here. I apologize if I got this wrong.

Consider the following snippet:

```D
import std.conv : text;
import std.stdio : writeln;

abstract class Class1
{
     void action(T)(T a)
     {
         action(text(a));
     }

     abstract void action(string a);
}

class Class2 : Class1
{
     alias action(T) = demo2.Class1.action!T; // This shouldn't be 
necessary.

     override void action(string a)
     {
         writeln(a);
     }
}

void main()
{
     Class2 o = new Class2();
     (cast(Class1) o).action("2");
     (cast(Class1) o).action!int(2);
     (cast(Class1) o).action(2);
     o.action("2");
     o.action!int(2);
     //o.action(2); // This should be allowed.
}
```

In my view, all lines should print "2".

The two comments in the code are pretty self-explanatory and 
reflect how I feel about this matter.

I think, in essence, that `Class1` and `Class2` in this example 
should provide the same API.

The last line of main, `o.action(2)`, is not allowed and leads to 
a compilation error. The previous line, `o.action!int(2)`, is 
only allowed if the alias is present in `Class2`, which I think 
shouldn't be required thanks to inheritance.

If I comment out `o.action!int(2)`, uncomment the last line and 
remove the alias, then the compier, when failing to compile 
`o.action(2)`, suggests adding the alias. So it is weird that 
adding it doesn't actually solve the problem for the last line. 
The suggestion is not given for the previous line (the one that 
actually does require the alias).