On Sat, 7 Jan 2023 22:35:03 +0000
Lénárd Szolnoki <cpp_at_[hidden]> wrote:

> On Sat, 7 Jan 2023 22:10:46 +0000
> Edward Catmur <ecatmur_at_[hidden]> wrote:
>
> > On Sat, 7 Jan 2023 at 21:16, Lénárd Szolnoki via Std-Discussion <
> > std-discussion_at_[hidden]> wrote:
> >
> > > Hi,
> > >
> > > [over.best.ics.general]:
> > >
> > > "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."
> > >
> > >
> > > https://timsong-cpp.github.io/cppwp/n4868/over.match#over.best.ics.general-2
> > >
> > > My reading is that the intent of this paragraph is to specify that
> > > viable and best viable functions are selected based on only type +
> > > cv + value category of arguments, and disregard any other
> > > property. (This probably only applies to expression arguments, as
> > > initializer list arguments have non of these properties, but this
> > > is just a tangent.)
> > >
> > > One example is that a call like `foo(some_obj.bit_field)` could
> > > find `foo(int&)` as viable, and later become ill-formed if this
> > > turns out to be the best viable function for the call.
> > >
> > > However this same paragraphs rules out to consider whether the
> > > argument is a null-pointer constant or not. Based on this a call
> > > like `foo(0)` shouldn't find `foo(void *)` viable, as there is no
> > > implicit conversion sequence from a prvalue of type int to `void
> > > *`,
> >
> > Yes, by https://wg21.link/conv.ptr#1 .
> >
> >
> > > Is this a defect in the standard?
> > >
> >
> > Probably, yes. This could almost be an editorial fix, hedging just a
> > little:
> >
> > > Implicit conversion sequences are concerned <del>only</del> with
> > > the type, cv-qualification, and value category of the argument
> > > and how these are converted to match the corresponding properties
> > > of the parameter.
> > > <https://eel.is/c++draft/over.best.ics.general#2.sentence-1>[*Note
> > > 1 <https://eel.is/c++draft/over.best.ics.general#note-1>*:
> > > <add>Most</add> other properties, such as the lifetime, storage
> > > class, alignment, accessibility of the argument, whether the
> > > argument is a bit-field, and whether a function is deleted
> > > <https://eel.is/c++draft/dcl.fct.def.delete>, are ignored.
> > > <https://eel.is/c++draft/over.best.ics.general#2.sentence-2>
> > >
> > > So, although an implicit conversion sequence can be defined for a
> > > given argument-parameter pair, the conversion from the argument to
> > > the parameter might still be ill-formed in the final analysis.
> > > <https://eel.is/c++draft/over.best.ics.general#2.sentence-3>
> > > — *end note*]
>
> I think with removing "only" from the normative part is too huge a
> change. In the normative part you want to communicate that for ICS you
> consider cv type, value category and whether the argument is a null
> pointer constant or not, but you don't consider whether it's a
> bit-field or not.
>
> With just removing "only", the paragraph reads like "ICS are concerned
> (among other things) with type, cv-qualifications, and value category
> of the argument..." which is either vague or meaningless.
>
> > Still, best to run it past CWG. Are you OK to open an issue at
> > https://github.com/cplusplus/CWG/issues ?
>
> Yes, I will do that.

https://github.com/cplusplus/CWG/issues/212

I meant to send the previous email to the list as well.

Cheers,
Lénárd