Steven Schveighoffer wrote:
> On Mon, 03 Aug 2009 11:18:26 -0400, Daniel Keep <daniel.keep.lists@gmail.com> wrote:
>> You can't trivially disambiguate between the getter and the setter with
>> the current system, either.  How is this a new issue?
> 
> You can't *trivially* but you can do it (that's another issue that probably should be addressed in general for overloaded functions).  

Agreed. I don't think this is so much an issue with properties as it's an issue with overloads. A good solution that works really well for overloads will work well for properties too.


>> Besides which, why can't you just add this:
>>
>>   __traits(getter, aggregate.property)
>>
>> Problem solved.
> 
> That works too.  That's probably the most sensable solution I've seen.  Has my vote.
> 
> -Steve

Me too.

--b

Andrei Alexandrescu wrote:
> 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
> 
> 
> Andrei

The nice thing about a keyword (or an @attribute) is that it's greppable. Syntax, not so much.

--b

On Mon, 03 Aug 2009 21:32:25 -0400, Robert Jacques <sandford@jhu.edu> wrote:
> On Mon, 03 Aug 2009 11:42:51 -0400, Michel Fortin <michel.fortin@michelf.com> wrote:
>
>> On 2009-08-03 10:06:23 -0400, "Robert Jacques" <sandford@jhu.edu> said:
>>
>>> On Mon, 03 Aug 2009 00:27:45 -0400, Nick Sabalausky <a@a.a> wrote:
>>>
>>>> "Robert Jacques" <sandford@jhu.edu> wrote in message
>>>> news:op.ux2gvcvi26stm6@sandford.myhome.westell.com...
>>>>>  I agree 1) is an issue, but I view it as a corner case. (I use zero/one
>>>>> arg functions all the time and make use of the 'property' syntax left
>>>>> right and center, but I've never run into the opCall problem) It would  be
>>>>> nice if it were fixed, but we may be cutting off the nose to spite the
>>>>> face, as it were. (Or alternatively, taking the scientific instead of
>>>>> engineering approach)
>>>>>
>>>>  It'll become a major PITA when D gets used for heavy functional-style  stuff.
>>>  Maybe. But how often will people return zero-argument opCalls (function  pointers/delegates/structs) from zero-argument functions? (i.e. how often  do you run into this today?)
>>
>> The compiler isn't as smart as you think. This doesn't compile, it requires an empty pair of parenthesis:
>>
>> 	void delegate(int) func();
>>
>> 	func(1);
>>
>> And I somewhat doubt it should be smart enough for this, because if you then add a overloaded function "func" that takes an int you're silently chaning the meaning of the code.
>>
>> Solve this for fun:
>>
>> 	void delegate() func(int);
>> 	void delegate(int) func();
>>
>> 	func(1); // which one?
>>
>
> Ah. Thank you for the informative post. That is a fairly big deficiency. However, isn't that really a bug? There's a similar one with ref return properties. According to the spec, there's nothing (I think) preventing DMD from doing the right thing.
>
> As for your example, 'void delegate() func(int);' would end up being called. But it's pretty obvious 'void delegate(int) func();' was meant. This particular example looks very pathological, if both funcs are part of the same module. Ultimately, this is just another form of function hijacking. Detecting this would require all combinations of call variations to enter into the lookup tree, but from there it's trivial to detect a collision, and issue an error. That would work for both out of module and in module double definitions. I don't know how difficult that is for the compiler, but it sounds fairly straight-forward.

I just found the related bugs in bugzilla:
http://d.puremagic.com/issues/show_bug.cgi?id=2409
http://d.puremagic.com/issues/show_bug.cgi?id=2152
http://d.puremagic.com/issues/show_bug.cgi?id=2159

Tue, 4 Aug 2009 01:15:45 +0400, Sergey Gromov wrote:

> Mon, 03 Aug 2009 11:06:53 -0400, Steven Schveighoffer wrote:
> 
>> I just thought of another issue with property definitions.  How do you declare a property of an array?  Today it's:
>> 
>> char[] chomped(char[] input);
>> 
>> Note that any getter property contains an argument which is the object you're calling the property on (normally implied because the definition is inside an aggregate definition).  But with arrays it's explicit.
>> 
>> So how does this fit in Walter's proposed syntax?
>> 
>> char[] chomped {...}
>> 
>> Where does the input go?
> 
> I proposed a keyword, 'inject', a year ago.  Or it could be an annotation.  I suppose such a keyword might significantly simplify implmentation of external functions and properties:
> 
> @inject @property char[] chomped(char[] arr) {...}
> @inject void sort!(alias pred, T)(T[] arr) {...}
> 
> Though prepending 'this' to the first parameter may also work, C# style.

Or, this can work with Walter's syntax:

@extension!char[] char[] chomped {...}

On Sun, 02 Aug 2009 03:43:43 -0400, Walter Bright <newshound1@digitalmars.com> wrote:

> 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
>
> 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 stated it elsewhere, but I'll bring it up to the front.

I don't think the getter syntax is viable without parentheses, since that precludes array properties, e.g.:

string asUpper(string s);

usage:

string s = "abcde".asUpper;

It wouldn't be possible to define this as a property using your syntax, unless you want to introduce a syntax for extending types...

-Steve