On Wednesday, 29 December 2021 at 01:11:13 UTC, Stanislav Blinov
wrote:
Because opIndexAssign cannot distinguish at compile time
between initialization and assignment:
```d
Stuff[Key] aa;
aa[key] = Stuff(args); // ostensibly, initialization
aa[key] = otherStuff; // assignment to existing
On Wednesday, 29 December 2021 at 02:33:08 UTC, frame wrote:
On Wednesday, 29 December 2021 at 01:11:13 UTC, Stanislav
Blinov wrote:
Because opIndexAssign cannot distinguish at compile time
between initialization and assignment:
```d
Stuff[Key] aa;
aa[key] = Stuff(args); // ostensibly,
On Wednesday, 29 December 2021 at 01:11:13 UTC, Stanislav Blinov
wrote:
Because opIndexAssign cannot distinguish at compile time
between initialization and assignment:
```d
Stuff[Key] aa;
aa[key] = Stuff(args); // ostensibly, initialization
aa[key] = otherStuff; // assignment to existing
On Tuesday, 28 December 2021 at 22:46:16 UTC, frame wrote:
On Tuesday, 28 December 2021 at 10:02:13 UTC, tsbockman wrote:
// Should be a compile-time error, because it might reassign:
test[key] = S(value);
This might be a typo in your example but why should it be a
compile-time error,
On Tuesday, 28 December 2021 at 10:02:13 UTC, tsbockman wrote:
// Should be a compile-time error, because it might reassign:
test[key] = S(value);
This might be a typo in your example but why should it be a
compile-time error, it cannot know if the key already exists in
compile time on
On Tuesday, 28 December 2021 at 14:48:24 UTC, Era Scarecrow wrote:
Probably better to make data private vs making it const. I
tend to use const far more as input arguments to help denote it
won't change references and less for elements in a struct. That
or make it a class? I'm not sure.
On Tuesday, 28 December 2021 at 07:51:04 UTC, frame wrote:
On Tuesday, 28 December 2021 at 01:45:42 UTC, Era Scarecrow
wrote:
Success!
So i summarize, either work with a pointer, or drop the
const...
Of course casting the const away was the first thing I did but
I think this is not
On Tuesday, 28 December 2021 at 07:54:56 UTC, frame wrote:
On Tuesday, 28 December 2021 at 06:38:03 UTC, Tejas wrote:
The workaround is okay, but I think we should file a bug
report for this.
This is very ~~stupid~~ undesirable behaviour
I agree. I'll just wait if somebody can explain why
On Tuesday, 28 December 2021 at 01:45:42 UTC, Era Scarecrow wrote:
Success!
So i summarize, either work with a pointer, or drop the
const...
Of course casting the const away was the first thing I did but I
think this is not very clean :D
On Tuesday, 28 December 2021 at 06:38:03 UTC, Tejas wrote:
On Tuesday, 28 December 2021 at 01:45:42 UTC, Era Scarecrow
wrote:
On Monday, 27 December 2021 at 19:38:38 UTC, frame wrote:
[...]
const/immutable members are to be set/assigned instantiation.
Most likely the problem is a bug and
On Tuesday, 28 December 2021 at 01:45:42 UTC, Era Scarecrow wrote:
On Monday, 27 December 2021 at 19:38:38 UTC, frame wrote:
[...]
const/immutable members are to be set/assigned instantiation.
Most likely the problem is a bug and sounds like
[...]
The workaround is okay, but I think we
On Monday, 27 December 2021 at 19:38:38 UTC, frame wrote:
I feel stupid right now: One cannot assign a struct that
contains const member to AA?
Error: cannot modify struct instance ... of type ... because it
contains `const` or `immutable` members
This is considered a modification?
```d
I feel stupid right now: One cannot assign a struct that contains
const member to AA?
Error: cannot modify struct instance ... of type ... because it
contains `const` or `immutable` members
This is considered a modification?
```d
struct S
{
const(int) a;
}
S[string] test;
test["a"] =
13 matches
Mail list logo
