Andrei Alexandrescu Wrote:
> Marianne Gagnon wrote:
> > Or, alternatively, if you really wish to keep them separate, bool empty= { ... } isn't intuitive, as Andrei pointed out, but is already less error-prone than the empty-body declaration idea I believe
> 
> I think void empty=(bool b) { ... } is a net win, which the forced bool empty=() diminishes. It would be great to keep the setter and find something as nice for a getter.
> 
>

If { ... } becomes the new standard way of declaring a function, that's fine with me; but if { ... } ended up being used only for properties, that would be somewhat inconsistent

Michiel Helvensteijn wrote:
> Andrei Alexandrescu wrote:
> 
>>> You should read my reply to myself, though. It describes an ambiguity in
>>> the approach. Several solutions are discussed. (Just translate them from
>>> grouping to non-grouping solutions.)
>> My reader does not show that message.
> 
> How strange.
> 
> http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D&article_id=94712

Oh, I do see it. But that message predates your other message, the one I was replying too.

To summarize:

bool empty
{
    void set(auto value) { ... }
    bool get() { ... }
}

I would really really prefer to not have two scopes in there. It makes properties unduly arcane to define, particularly read-only properties. They should be about as easy to define as regular methods.

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.


Andrei

Ah, and also :

Andrei Alexandrescu Wrote:

> Marianne Gagnon wrote:
> > Like someone else pointed out, existing keywords could be reused :
> > 
> > bool empty
> > {
> >     in(bool value)
> >     {
> >         _my_empty = value;
> >     }
> >     out
> >     {
> >         return _my_empty;
> >     }
> > }
> > 
> > I like this quite a bit.  I never wrote any compiler, granted, but I don't think it'd be that hard to implement - and doesn't introduce any new keyword.
> 
> Please, please, could we look at something that does NOT go through two scopes to get to the code?
> 

Sure, that was just an exampel of keyword re-use, you can do the exact same without scores :

out int foo()
{
    return  m_foo;
}
in int foo(int value)
{
    m_foo = foo;
}

Many variations possible on this theme ;) So not wanting a new keyword is not a show-stopper for solutions involving the use of keywords, in and out can be used there with no ambiguity i can think of (maybe others will though)

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).

-- 
Michiel Helvensteijn

On 2009-08-02 12:32:16 -0400, Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org> said:

>> The point is not really the grouping of elements within brackets. That just
>> eliminates some redundancy. It can also look like the following:
>> 
>> void empty.set(bool value) { ... }
>> bool empty.get() { ... }
>> 
>> and have the same meaning as my earlier example.
> 
> Yah, I was thinking the same. This is my #1 fave so far.

And as a bonus, it makes this look ridiculous:

	void popFront.get() { ... }

which means it won't get so easily twisted for use by functions with no parameters.

The only thing that can get confusing is getting the address of the setter and getter, because get and set aren't keywords and thus could be defined by the returned object.

	&empty.get; // address of what?

-- 
Michel Fortin
michel.fortin@michelf.com
http://michelf.com/

Walter Bright, el  2 de agosto a las 00:43 me escribiste:
> Having optional parentheses does lead to unresolvable ambiguities. How
> much of a problem that really is is debatable, but let's assume it
> should be resolved.
> To resolve it, a property must be distinguishable from a regular function.
> 
> One way is to simply add a "property" attribute keyword:
> 
>   property bool empty() { ... }
>   property void empty(bool b) { ... }
> 
> The problem is that:
> 
> 1. there are a lot of keywords already
> 2. keywords are global things

What about DIP6 for a more general solution. DIP6 should be:
1) Easy to implement in a first basic stage
2) Backward compatible
3) Doesn't need a new keyword, even more, it will help to reduce the
   number of keywords in the future.

> The alternative is to have a unique syntax for properties. Ideally, the syntax should be intuitive and mimic its use. After much fiddling, and based on n.g.  suggestions, Andrei and I penciled in:
> 
>   bool empty { ... }
>   void empty=(bool b) { ... }
> 
> The only problem is when a declaration but not definition is desired:
> 
>   bool empty;
> 
> but oops! That defines a field. So we came up with essentially a hack:
> 
>   bool empty{}
> 
> i.e. the {} means the getter is declared, but defined elsewhere.
> 
> What do you think?

I think it's a bad idea to ignore all the other proposals in this NG. Why did you dismissed the other proposals? What is better in this proposal comparing it to the others?

I find this very odd, is like saying everybody is wrong except you. What's wrong with the other proposals (other than the "property" keyword proposal)? You have virtually not participated in the discussion and now you came up with a brand new syntax. That's not quite supporting the DIPs, that's more like ignoring them. Even (several) votings were done with alternative property syntax. What should we do now?  Repeat all the voting again adding this one?

Bummer! =(

-- 
Leandro Lucarella (luca) | Blog colectivo: http://www.mazziblog.com.ar/blog/
----------------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------------
I've always been mad, I know I've been mad, like the most of us... very hard to explain why you're mad, even if you're not mad...

Andrei Alexandrescu, el  2 de agosto a las 11:02 me escribiste:
> Jarrett Billingsley wrote:
> >I think it's funny that for a week, Andrei has been arguing against throwing around new syntax to solve this problem, and that's exactly what you guys have come up with.  Really, how much more complicated would this make the parser, compared to adding a new attribute?
> 
> We couldn't find a good solution without adding new syntax, so this is now on the table. Adding syntax or keywords is the next thing to look at. I'd still be unsatisfied if:
> 
> (a) there would be significant syntactic noise to defining a read-only property
> 
> (b) we had to add a keyword

Againg, what about DIP6?

b) won' happen, even more, D could get rid of a *lot* of keywords if it
   works out.

a) this not that bad, right?

   @property bool empty() { return _len == 0; }

   (we can use @prop if @property is too long)

-- 
Leandro Lucarella (luca) | Blog colectivo: http://www.mazziblog.com.ar/blog/
----------------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------------
<o_O> parakenotengobarraespaciadora
<o_O> aver
<o_O> estoyarreglandolabarraporkeserompiounapatita

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

Jarrett Billingsley wrote:
> I think it's funny that for a week, Andrei has been arguing against
> throwing around new syntax to solve this problem, and that's exactly
> what you guys have come up with.

That's in the nature of debating in order to try to figure out the best solution. It's hard to think of all the ramifications, positives, negatives, and corner cases all at the same time.


> Really, how much more complicated
> would this make the parser, compared to adding a new attribute?

Neither of these proposals is a particular problem for the parser.

Andrei Alexandrescu wrote:

> I see. My view is that .get and .set are simply symbolic placeholders, but indeed some may get confused.

In my design, they are actual functions with actual names.

For D this doesn't really work. If you want symbolic placeholders, you may
want to use something other than 'get' and 'set'. For example, 'in'
and 'out' have been suggested by some. They are already keywords.

-- 
Michiel Helvensteijn