Sergey Gromov <snake.scaly@gmail.com> wrote:
> foo(double x) {...}
> property double distance() {return ...}
> 
> foo(distance);   // OK
> foo(distance()); // OK
> foo = distance;  // error

Or even forbid to use the `double()' syntax for properties, and forbid to overload properties with non-property functions.  In other words:

foo(distance()); // error, can't use call syntax for properties
double distance(int precision) {...} // error, can't overload a property
-- 
SnakE

Matti Niemenmaa wrote:
> Robert Fraser wrote:
>> I agree with you on that particular syntax. I think when it's a member of some sort, that syntax should be allowed, though (to allow a property syntax), but for free functions it's a bad idea.
> 
> The argument for class properties applies equally well to global variables.
> 

Oops, forgot about those... alright, well I guess then people just need to be careful with this syntax.

Sergey Gromov wrote:
> Sergey Gromov <snake.scaly@gmail.com> wrote:
>> foo(double x) {...}
>> property double distance() {return ...}
>>
>> foo(distance);   // OK
>> foo(distance()); // OK
>> foo = distance;  // error
> 
> Or even forbid to use the `double()' syntax for properties, and forbid to overload properties with non-property functions.  In other words:
> 
> foo(distance()); // error, can't use call syntax for properties
> double distance(int precision) {...} // error, can't overload a property

From my limited experience with C#, I know there's some kind of special property syntax. Maybe something like this would be a better solution?

private double myDistance;
public property distance
{
   double __get { return myDistance; }
   void __set(double val) { myDistance= val; }
   double* __addressOf { return &myDistance; }
}

double x = distance;    // x = distance.__get();
distance = 50.0;        // distance.__set(50.0);
double* p = &distance;  // p = distance.__addressOf();

And maybe add more property-properties as needed. This would make them first-class, fully interchangeable with variables.

Robert Fraser:
>  From my limited experience with C#, I know there's some kind of special
> property syntax. Maybe something like this would be a better solution?

If you take a look at my last post of notes (the 4th) you can see I suggested something even better, coming from C# 3.x ;-)

Bye,
bearophile

Robert Fraser <fraserofthenight@gmail.com> wrote:
>  From my limited experience with C#, I know there's some kind of special
> property syntax. Maybe something like this would be a better solution?
> 
> private double myDistance;
> public property distance
> {
>     double __get { return myDistance; }
>     void __set(double val) { myDistance= val; }
>     double* __addressOf { return &myDistance; }
> }
> 
> double x = distance;    // x = distance.__get();
> distance = 50.0;        // distance.__set(50.0);
> double* p = &distance;  // p = distance.__addressOf();
> 
> And maybe add more property-properties as needed. This would make them first-class, fully interchangeable with variables.

Yes, this would be far more consistent of course.  I've just tried to keep to the current syntax and semantics as close as possible.
-- 
SnakE

Robert Fraser wrote:
> Matti Niemenmaa wrote:
>> Robert Fraser wrote:
>>> I agree with you on that particular syntax. I think when it's a member of some sort, that syntax should be allowed, though (to allow a property syntax), but for free functions it's a bad idea.
>> 
>> The argument for class properties applies equally well to global variables.
>> 
> 
> Oops, forgot about those... alright, well I guess then people just need to be careful with this syntax.

I've actually used that when making bindings for a C library which has got some volatile globals.  Just property wrappers with volatile statements in them.  At least it made the examples easier to port. Whether this syntax is good or bad in general, I'm not sure.

Sergey Gromov wrote:
> Are you sure this is to the better ?  I'm not quite fond of D's freedom in syntax.  It already allows to write an unreadable code like this:
> 
> use(context) in (GL gl) {draw(gl);}
> 
> auto GetEven = stackthread = (int delegate() read, void delegate(int) yield) {...}
> 

I just don't like "});". The less closing parens the better. :)


Semantically, read it as "auto GetEven = stackthread
                                       = (int delegate() read, void delegate(int) yield) { ... };]".

 --downs

Sergey Gromov wrote:
> I wonder why .sizeof is implemented as a property while typeof() and
> typeid() are functions.  I can see no reasons for such inconsistency.
> It's not that obvious for typeof() because it yields a type instead
> of a value, but even then, why not ?

Because expression.identifier always yields an expression, whereas typeof() always yields a type. It makes parsing easier and more consistent.

Walter Bright wrote:
> Sergey Gromov wrote:
>> I wonder why .sizeof is implemented as a property while typeof() and
>> typeid() are functions.  I can see no reasons for such inconsistency.
>> It's not that obvious for typeof() because it yields a type instead
>> of a value, but even then, why not ?
> 
> Because expression.identifier always yields an expression, whereas typeof() always yields a type. It makes parsing easier and more consistent.

typeid yeilds an expression...

On Wed, 06 Feb 2008 18:51:49 -0800, Walter Bright wrote:

> Sergey Gromov wrote:
>> I wonder why .sizeof is implemented as a property while typeof() and
>> typeid() are functions.  I can see no reasons for such inconsistency.
>> It's not that obvious for typeof() because it yields a type instead of
>> a value, but even then, why not ?
> 
> Because expression.identifier always yields an expression, whereas typeof() always yields a type. It makes parsing easier and more consistent.

From a users perspective, my first thought is always that it should be
used similar to a type alias in a struct/class.
.typeof feels also more consistent with .length, .sizeof or .stringof.

typeof() looks like a build-in compile time function, but the feeling to access the AST is definitely nicer.

Thought, I don't know if typeof() is worth the gains on the parsing side.