[Issue 15782] [Reg 2.071-devel] something about the const/non-const types in TypeTuples changed

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=15782

--- Comment #6 from Martin Nowak  ---
(In reply to John Colvin from comment #5)
> Apologies for not noticing the changes, I didn't notice the bug in the old
> implementation.

No problem, it took me 20 minutes to find the change (b/c it's more or less a
compiler bug, see issue 11480).

> What is the way forward here? The old behaviour was unexpected (why remove
> qualifiers?), inconsistent (didn't happen for builtins) and undocumented. I
> would argue that it's a straightforward bug and we should just say it's now
> fixed, perhaps adding a warning and a special changelog entry.

But it's been like that since ages and might now subtly break metagen code
(e.g. serialization frameworks). The amount of time necessary to debug that
some binary protocol no longer works b/c the semantics of Replace were fixed
justifies that we put some more effort into this.

I'd try sth. along this line, though it might raise too many errors.

deprecated("message about Alias")
template Alias(T) if (isAffected!T && !is(T == Unqual!T))
{
alias Alias = Unqual!T;
}

template Alias(T) if (!isAffected!T || is(T == Unqual!T))
{
alias Alias = T;
}


--

[Issue 15782] [Reg 2.071-devel] something about the const/non-const types in TypeTuples changed

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=15782

--- Comment #5 from John Colvin  ---
Apologies for not noticing the changes, I didn't notice the bug in the old
implementation.

What is the way forward here? The old behaviour was unexpected (why remove
qualifiers?), inconsistent (didn't happen for builtins) and undocumented. I
would argue that it's a straightforward bug and we should just say it's now
fixed, perhaps adding a warning and a special changelog entry.

--

[Issue 15782] [Reg 2.071-devel] something about the const/non-const types in TypeTuples changed

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=15782

--- Comment #4 from Martin Nowak  ---
I think it would be OK to make the change if it were only for Alias (which was
package protected and undocumented anyhow), but I don't like that those
breakages just happen, and it's definitely not OK to change all the other
functions in std.meta w/o a proper deprecation.

Also see issue 11480

--

[Issue 15782] [Reg 2.071-devel] something about the const/non-const types in TypeTuples changed

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=15782

--- Comment #3 from John Colvin  ---
https://issues.dlang.org/show_bug.cgi?id=11577

--

[Issue 15782] [Reg 2.071-devel] something about the const/non-const types in TypeTuples changed

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=15782

John Colvin  changed:

   What|Removed |Added

 CC||john.loughran.colvin@gmail.
   ||com

--- Comment #2 from John Colvin  ---
If that test had used builtin types it would never have passed, it was a bug in
Alias when dealing with qualified user-defined types.

I understand that it's frustrating to have old code break, but having templates
like Alias & NoDuplicates strip qualifiers for user-defined types but not
builtins is definitely not an option. So we have 2 choices: it always strips or
it never strips. The second seems vastly preferable to me.

--

[Issue 15782] [Reg 2.071-devel] something about the const/non-const types in TypeTuples changed

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=15782

Kenji Hara  changed:

   What|Removed |Added

  Component|dmd |phobos

--- Comment #1 from Kenji Hara  ---
Introduced in:
https://github.com/D-Programming-Language/phobos/pull/3985

Now the Alias template properly holds the aliased type qualifier. It would
affect to staticIndexOf, Erase, EraseAll, NoDuplicates, Replace, ReplaceAll,
and DerivedToFront behaviors at least.

--