Comment #0 by verylonglogin.reg — 2013-09-23T03:37:55Z
The usage of `hasElaborateAssign` on unassignable types (e.g. `const` ones) which now results in returning `false` is almost definitely an error. So `hasElaborateAssign` has to reject such types.
Comment #1 by verylonglogin.reg — 2013-09-23T03:41:18Z
I don't believe this is a good choice.
I think a trait can be used inside a runtime check, and as such, all traits should always compile.
This is currently the case for every trait we have, be they in std.traits or std.range.
The trait name is "hasElaborateAssign". It should really just answer yes/no. Not yes, no, error.
Comment #6 by github-bugzilla — 2013-10-12T05:17:19Z
Comment #7 by verylonglogin.reg — 2013-10-12T05:44:14Z
(In reply to comment #5)
> I don't believe this is a good choice.
>
> I think a trait can be used inside a runtime check, and as such, all traits
> should always compile.
>
> This is currently the case for every trait we have, be they in std.traits or
> std.range.
>
> The trait name is "hasElaborateAssign". It should really just answer yes/no.
> Not yes, no, error.
See https://github.com/D-Programming-Language/phobos/pull/1623#issuecomment-26196738 for reply:
> So, we are talking about this:
>
> if (isAssignable!SS && !hasElaborateAssign!SS)
>
> Even in the case it would be just rare and uncommon code it is silly to make regular code error-prone (spending programmers time on debugging their mistakes) to support some patterns almost nobody use. But we are talking here about not just rare and uncommon, but almost definitely incorrect construction indicating an error. And you really did the error here [see pull discussion] which my pull shown.
Comment #8 by robert.schadek — 2024-12-01T16:18:52Z