On Sun, 8 Jan 2023 at 22:56, Phil via Std-Discussion <
std-discussion_at_[hidden]> wrote:

> 
>
> ... because literal 0 and literal 1 have the same type, cv and value
> category.
>
>
> I agree in that point.
>
> So `foo(0, 1)` would be expected to behave the same as `foo(1, 1)`.
>
>
> I don’t think so.
>
> [over.best.ics.general/2] states: "Implicit conversion sequences are
> concerned only with the type, cv-qualification, and value category of the
> argument **and how these are converted to match the corresponding
> properties of the parameter.**" (emphasis mine). In my understanding, the
> term „concerned“ means that other (restricting) properties might not affect
> the fact whether there is a valid conversion from one type into another.
> But it does not state that the conversion itself is limited to or
> determined just and only by „the type, cv-qualification, and value
> category“ - especially since the rules for the conversion itself are
> described in a completely different section [conv].
>
> So, regarding the „implicit conversion sequences“, they are „concerned“
> whether there is (at all) any legit conversion based on the type,
> cv-qualification, and value category of arguments and parameters. But the
> conversion itself is not limited, restricted, or „ concerned only with
> the type, cv-qualification, and value category“.
>
> Going back to the example, this means the „implicit conversion sequences“
> are „concerned“:
>
> - for the first argument: from `cv-unqualified prvalue int` to
> `cv-unqualified lvalue void*` (overload 1) or from `cv-unqualified
> prvalue int` to `cv-unqualified lvalue short` (overload 2), respectively.
>
> - for the second argument: from `cv-unqualified prvalue int` to
> `cv-unqualified lvalue int` (overload 1) or from `cv-unqualified prvalue
> int` to `cv-unqualified lvalue short` (overload 2), respectively.
>
> It is not concerned whether the respective values are accessible or the
> like, it just cares about whether there is a potentially legit implicit
> conversion available „from -> to“.
>
> So back to the first argument, for the first overload (1), it happens that
> there is indeed a legit implicit conversion available from `cv-unqualified
> prvalue int` to `cv-unqualified lvalue void*`. That is the „Pointer
> conversion“ - which happens to be available due to [conv.ptr/1]. But that
> conversion itself is in now way limited by or even related to [over.best.ics.general/2].
> The pointer conversion has rank „Conversion“.
>
> For the second overload (2), there is no need for an implicit conversion
> from `cv-unqualified prvalue int` to `cv-unqualified lvalue int`, since
> it is of category „Identity“ and has rank „Exact Match“.
>
> At this point, the second overload (2) is only just the more viable
> overload.
>
> Now, the second argument is evaluated.
>
> For the first overload (1), there is a legit implicit conversion
> available from `cv-unqualified prvalue int` to `cv-unqualified lvalue
> short`. That is the „Integral conversion“ with rank „Conversion“.
>
> For the second overload (2), there is a legit implicit conversion
> available from `cv-unqualified prvalue int` to `cv-unqualified lvalue
> short`. That is the „Integral conversion“ with rank „Conversion“.
>
> So, at the end of the day, we have:
> - for overload (1): Conversion-Exakt
> - for overload (2): Conversion-Conversion
>
> So, overload (1) is the „winner“ and more viable.
>
> So again, in my understanding of the current wording, the conversion
> itself is in now way limited by or even related to [over.best.ics.general/2].
> I think this paragraph is just there - as the related note suggests - to
> make it clear that the viability does not depend on whether the values are
> accessible or other properties, but just whether there is a known and legit
> implicit conversion from one (type, cv-qualification, and value category)
> „tuple“ into another.
>
> Again, maybe I still miss the point but I don’t see any problem with the
> wording regarding how nullpointers are handled according to the
> specification. It is all clear in my understanding. Hope I could project my
> view somehow understandable.
>

Not really. What would you say happens for `foo(1, 1)` and where does that
diverge from the process for `foo(0, 1)`? Let's forget about the second
argument for now.


> Kind Regards
> --
> Std-Discussion mailing list
> Std-Discussion_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-discussion
>