On Mon, 03 Aug 2009 10:14:14 -0400, John C <johnch_a...@hotmail.com> wrote:

Steven Schveighoffer wrote:
On Sun, 02 Aug 2009 15:23:44 -0400, John C <johnch_a...@hotmail.com> wrote:

Andrei Alexandrescu wrote:
Michiel Helvensteijn wrote:
Andrei Alexandrescu wrote:

Then in a later message you mention:

bool empty.get() { ... }
void empty.set(bool b) { ... }

which I like and which does not seem to have difficulties; the names
"get" and "set" will be never used as such.

Yes, those are two notations for the same thing, and they have the same
problem. Let me demonstrate:

--------------------------------------------------
struct S {
    int get() { return 42; }
};

struct T {
    S _s;
    S property.get() { return _s; }
    void property.set(S s) { _s = s; }
}

T t;

auto X = t.property.get();
--------------------------------------------------

What is the type of X? It can be either S or int, depending on how D handles
the situation.

The ambiguity is in the possibility to directly reference the getter and
setter methods. In that other subthread (the older one) I listed some
possible solutions.

The first is to make such a program an error.

The second is not to allow a direct reference to a getter/setter (so X is an
int).

The third is to let the getter/setter overshadow S members (so X is an S).
I see. My view is that .get and .set are simply symbolic placeholders, but indeed some may get confused.
 Andrei

Does the ambiguity go away if we replace the '.' with a space?

Declaration:

bool empty get();
void empty set(bool);

Declaration:

bool empty get() { return empty_; }
void empty set(bool b) { empty_ = b; }
The ambiguity of declaration, not the ambiguity of usage, unless you want to use the space to denote the usage also?
 -Steve

Not sure where the ambiguity is with usage. To keep things simple, 'get' and 'set' should only be valid at the point of declaration. They're not really part of the function name.

Currently, since properties are simply functions, you can take the delegate of a setter.

So the poster who started this trail of the thread is assuming that

t.property.get()

identifies the property getter directly. But what if the return type of t.property.get() contains a method get()? Since t.property is an alis for t.property.get(), Should t.property.get() map to:

t.property

or

(t.property).get() // get the property, then call it's get function.

That is the ambiguity.

-Steve

Reply via email to