Date: Wed, 15 Apr 2020 19:09:38 +0300
On Wed, 15 Apr 2020 at 19:05, Daniel Krügler <daniel.kruegler_at_[hidden]> wrote:
> > I would expect *correct* implementations to make the code ill-formed,
> > as those operations
> > are specified to invoke operations of the hash specialization, and
> > those operations
> > are ill-formed for a disabled hash.
>
> The working paper does not provide this guarantee. Presumably we need
> another round of "Mandating" papers to realize that.
Then the working paper is broken. The intent behind
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0513r0.pdf
and its related issues was to make these things ill-formed, portably.
They are supposed to SFINAE, and any
potential UB is unacceptable for that goal.
> That being said: I would be seriously surprised if someone can point
> to an implementation that doesn't diagnose this.
Likewise, some implementations implement the design intent correctly. :D
> > I would expect *correct* implementations to make the code ill-formed,
> > as those operations
> > are specified to invoke operations of the hash specialization, and
> > those operations
> > are ill-formed for a disabled hash.
>
> The working paper does not provide this guarantee. Presumably we need
> another round of "Mandating" papers to realize that.
Then the working paper is broken. The intent behind
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0513r0.pdf
and its related issues was to make these things ill-formed, portably.
They are supposed to SFINAE, and any
potential UB is unacceptable for that goal.
> That being said: I would be seriously surprised if someone can point
> to an implementation that doesn't diagnose this.
Likewise, some implementations implement the design intent correctly. :D
Received on 2020-04-15 11:12:44