[Dune-devel] PSA: please avoid implicit conversion integral_constant<bool, ...> to bool
Carsten Gräser
graeser at mi.fu-berlin.de
Tue Feb 21 10:52:56 CET 2017
Hi Jö,
Am 21.02.2017 um 01:54 schrieb Jö Fahlke:
> Am Mon, 20. Feb 2017, 21:12:43 +0100 schrieb Carsten Gräser:
>> Hi Jö,
>>
>> Am 20.02.2017 um 13:10 schrieb Jö Fahlke:
>>> Hi!
>>>
>>> I've seen expression like `std::is_same<T1, T2>()` (or any other type
>>> predicate) where the result is implicitly converted to `bool` pop up
>>> throughout Dune for some time now. Please stop that; they can't work in all
>>> cases, and when they break they lead to hard-to-diagnose errors.
>> the guideline to alway avoid this implicit conversion seems
>> to be a little to general to me. I don't see a problem if
>> you already have an object of type integral_constant<bool, ...>.
>
> The problem with making exceptions to guidelines is that it makes them more
> complicated. The distinction between a type trait and its BaseCharacteristic
> is easy to overlook -- picking your personal favorite and sticking with it for
> all `integral_constant`-like thing seems simpler to me.
this is why I object to this guideline and want to propose
another one. Blaming the very natural and useful cast of
integral_constant<T,k> to T just to avoid problems that
may occur in this context but have an unrelated origin is
not very helpful.
>> By the same argument one would not be allowed to use
>> v[Indices::_0] for e.g. a std::vector v because this
>> involves such an implicit conversion.
>
> If I know it is a `std::vector` I cannot think of any reason to prefer an
> index constant literal over an integer literal for the subscript. So I'm
> assuming you're thinking about code that does not know whether the container
> is a `std::vector` or actually something that needs to be subcripted with an
> index constant.
>
> In that case you were right in calling it a guideline, and the rule about
> guidelines applies: you sometimes need to ignore them. I can see no way
> around relying on the implicit conversion there.
I strongly object to this. Relying on the conversion is
a standard use case and the problem you mentioned is the
exception. This cast is one of the reasons why integral_constant
is to useful. See e.g. hybridutilitiestest.cc where this
is used extensively. Your rule essentially forbids such code.
>> Isn't the real guideline: Never use the conversion if the
>> expression may involve incomplete types?
>
> That would work, but then you have to determine whether the expression may
> involve incomplete types. Most of the time in template code you can't be sure
> that the passed-in types are sufficiently complete.
But you can be sure if you have a type or an object.
In case of the latter there is no problem whereas
you may want to play safe in case of the former.
This will lead to:
As a rule of thumb try to avoid creating an object of type
integral_constant<T,k> just to extract its value.
Best,
Carsten
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 455 bytes
Desc: OpenPGP digital signature
URL: <https://lists.dune-project.org/pipermail/dune-devel/attachments/20170221/dc6810bf/attachment.sig>
More information about the Dune-devel
mailing list