M I ambiguity

[Fraser Ross]

struct B1 {
void f();
static void f(int);
int i;
};
struct B2 {
void f(double);
};
struct I1: B1 { };
struct I2: B1 { };
struct D: I1, I2, B2 {
using B1::f;
using B2::f;
void g() {
f(); // Ambiguous conversion of this
f(0); // Unambiguous (static)
f(0.0); // Unambiguous (only one B2)
int B1::* mpB1 = &D::i; // Unambiguous
int D::* mpD = &D::i; // Ambiguous conversion
}
};

In the second last statement there is surely ambiguity? It is not
possible to disambiguate i because of arguably a weakness in the
language.

In the last statement I don't think there is a conversion.

This is from the propsed resolution N1626.

Fraser.

 

[Salt_Peter]

struct B1 {
void f();
static void f(int);
int i;};

struct B2 {
void f(double);};

struct I1: B1 { };
struct I2: B1 { };
struct D: I1, I2, B2 {
using B1::f;
using B2::f;
void g() {
f(); // Ambiguous conversion of this
f(0); // Unambiguous (static)
f(0.0); // Unambiguous (only one B2)
int B1::* mpB1 = &D::i; // Unambiguous
int D::* mpD = &D::i; // Ambiguous conversion

}
};

In the second last statement there is surely ambiguity? It is not
possible to disambiguate i because of arguably a weakness in the
language.

A weakness or a feature? What are accessors employed for?

In the last statement I don't think there is a conversion.

This is from the propsed resolution N1626.

Fraser.

The last two show up as ambiguous here. Which makes sense.
Does N1626 not propose a phrase that states such a situation is ill-
formed anyway?

 

[Fraser Ross]

"Salt_Peter"

A weakness or a feature? What are accessors employed for?

It isn't possible to disambiguate between non-virtual common base
classes. An access specification specifies a class not a subobject.

The last two show up as ambiguous here. Which makes sense.
Does N1626 not propose a phrase that states such a situation is ill-
formed anyway?

Its demonstrating amibiguity when there is no ambiguity with name
lookup.

Fraser.