Well first what I like about it: The approach function symbols are handled, it is a pretty clear concept:

void f() {
}

f;

f is a function, you can take the address of it and call it and that's it. So if you just write it down, it makes sense that it gets called. Not so for delegates, function objects, ... Sounds sane to me, I like it.

About properties:

In short, I died a little reading it.

I know we have UFCS, but @properties are meant to emulate a field, so the semantics should be as close to a field as possible. Ideally, identical.

Especially the part about module level properties made me crazy:
@property double fun(int x, double y) { assert(x == 42 && y == 43);
return y; }
    42.fun = 43;

reads to me: The integer 42 has a property called fun, which gets assigned 43???

If we special case properties, we might as well disallow UFCS for them, which makes sense, because you can not define a field external to an object either.

So the proposal for module level properties, would be right exactly the
other way round (emulating global variables):
private int myCoolSetting_;
@property int myCoolSetting() {
	return myCoolSetting_;
}
@property void myCoolSetting(int setting) {
	enforce(setting>0 && setting<10, "Invalid setting!");
	myCoolSetting_=setting;
}

myCoolSetting=8; // Ok.

That is what properties are all about.

The part, about taking the address of a property, is fine as long as we allow fields to be declared with @property as I already suggested, with the following semantics:

@property int a;

would be lowered to:

private int __a;

@property void a(int a_) {
	__a=a_;
}

@property int a() {
	return __a;
}

in order to ensure that @property declared fields and properties declared as functions do really have the same semantics.

If you don't think about properties as fields, than I understand Walters suggestion about removing @property completely and we could as well do it.

UFCS with properties, makes little to no sense. Because well the name already suggests: "Uniform Function Calling Syntax", properties are not about calling functions. Allowing UFCS would offer the possibility of adding some kind of dynamic properties/fields to an object, but the code samples with integers and especially the problem with module level properties suggests that this causes more problems than it is worth.

properties -> no UFCS and we have a sane world!

Best regards,

Robert

P.S.: Things like int a = 4.2.truncated;

do make sense, but UFCS and optional parentheses would do the trick too, so no need to abuse properties there.

On Wednesday, 6 February 2013 at 22:10:29 UTC, Robert wrote:
>
>  @properties are meant to emulate a field

You're in the wrong spot of the world. Everywhere else outside the D community, the above assertion is held for true.

In the D community, it is not. Yes, there are places like that, and you are trapped into one of those. For your sake, during your future staying in this place, think of "@properties" as functions with calling particularities.

On Thursday, 7 February 2013 at 14:44:36 UTC, eles wrote:
> On Wednesday, 6 February 2013 at 22:10:29 UTC, Robert wrote:
>>
>> @properties are meant to emulate a field
>
> You're in the wrong spot of the world. Everywhere else outside the D community, the above assertion is held for true.
>
> In the D community, it is not. Yes, there are places like that, and you are trapped into one of those. For your sake, during your future staying in this place, think of "@properties" as functions with calling particularities.

Heh, after that many topics and discussion I have started to think it would have been better if initial proposal to remove them altogether succeeded.

On 2/7/13 9:44 AM, eles wrote:
> On Wednesday, 6 February 2013 at 22:10:29 UTC, Robert wrote:
>>
>> @properties are meant to emulate a field
>
> You're in the wrong spot of the world. Everywhere else outside the D
> community, the above assertion is held for true.
>
> In the D community, it is not. Yes, there are places like that, and you
> are trapped into one of those. For your sake, during your future staying
> in this place, think of "@properties" as functions with calling
> particularities.

I think the sarcasm is uncalled for. We're doing our best here and our intent is indeed to have properties emulate fields.

Properties emulate fields, but they can't behave 100% like fields because if they did they'd be fields.


Andrei

On 2/7/13 10:55 AM, Dicebot wrote:
> On Thursday, 7 February 2013 at 14:44:36 UTC, eles wrote:
>> On Wednesday, 6 February 2013 at 22:10:29 UTC, Robert wrote:
>>>
>>> @properties are meant to emulate a field
>>
>> You're in the wrong spot of the world. Everywhere else outside the D
>> community, the above assertion is held for true.
>>
>> In the D community, it is not. Yes, there are places like that, and
>> you are trapped into one of those. For your sake, during your future
>> staying in this place, think of "@properties" as functions with
>> calling particularities.
>
> Heh, after that many topics and discussion I have started to think it
> would have been better if initial proposal to remove them altogether
> succeeded.

I felt we were getting somewhere.

Andrei

> Heh, after that many topics and discussion I have started to think it would have been better if initial proposal to remove them altogether succeeded.

Same feeling here. But I'll try to be constructive and I hope I find the time to write yet another DIP about properties next week.

UFCS and properties just don't go together.

Properties provide a means of access control to fields. (Range checks, only readable, only writable, triggering a signal on change, ...)

So as posted a few times, taking the address of the ref return value of a property is of no value at all. If you want someone to be able to take the address of a field, you should make it simply public (without @property), because the @property accessor methods won't gain you anything in this case.

Having said this, I think the solution to the & operator is pretty straight forward, it takes the address of the accessor function, which in fact might me useful at times, but it never takes the address of the return value. (This only applies to properties, for functions simply do something like &(func()) to get the address of the return value.)

Tada. Problem solved :-)

I can remember Adam D. Ruppe saying that he would rather have it hidden completely that the property is accessed by methods, so that taking the address of the function would not be possible. I have to say, that this does not feel right for a system programming language and it does not really improve things, especially with @property fields.

Instead of hiding that properties are functions, we hide that there might be a real field behind those properties.

Best regards,

Robert

On 2013-02-07 19:05, Robert wrote:
> taking the address of the ref return value of a property is of no
> value at all. If you want someone to be able to take the address
> of a field, you should make it simply public (without @property),
> because the @property accessor methods won't gain you anything in
> this case.

Once again. Ref returns are commonly used in ranges.
I'd say that being able to take address of someRange.front is good for
example for interoperability with external C libraries.
Temporarily using a pointer here should be fine.


> Having said this, I think the solution to the & operator is pretty
> straight forward, it takes the address of the accessor function [...]
> Tada. Problem solved :-)

Didn't solve the one mentioned above.
So either I am wrong, you are wrong or range.front shouldn't be a @property?

On Thursday, 7 February 2013 at 16:35:17 UTC, Andrei Alexandrescu wrote:
> I felt we were getting somewhere.
>
> Andrei

Both yes and no at the same time.

Last proposals did a great job addressing different issues regarding property syntax and I somewhat like them in that sense. But they miss an important paragraph about what properties are supposed to be in D semantically, when they should be used and what problems they try to solve. So far design feels like it is syntax based as opposed to use case based.

On Thu, Feb 07, 2013 at 07:55:22PM +0100, Dicebot wrote:
> On Thursday, 7 February 2013 at 16:35:17 UTC, Andrei Alexandrescu wrote:
> >I felt we were getting somewhere.
> >
> >Andrei
> 
> Both yes and no at the same time.
> 
> Last proposals did a great job addressing different issues regarding property syntax and I somewhat like them in that sense. But they miss an important paragraph about what properties are supposed to be in D semantically, when they should be used and what problems they try to solve. So far design feels like it is syntax based as opposed to use case based.

Agreed. I've mostly refrained from participating in the myriad of related threads, because I felt like a lot of it was just bikeshedding over what syntax should/shouldn't be allowed, what this or that syntax should/shouldn't mean, but there wasn't much consideration of *why* we're doing this in the first place, and whether / how the various proposals will get us there.

Currently I feel like we're just making a gigantic mountain out of a molehill, whereas more important issues like reviewing Dmitri's std.uni replacement are being overlooked.


T

-- 
Valentine's Day: an occasion for florists to reach into the wallets of nominal lovers in dire need of being reminded to profess their hypothetical love for their long-forgotten.