On Thu, 07 Feb 2013 13:05:50 -0500, Robert <jfanatiker@gmx.at> wrote:

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

@property ref T front(T[] arr) { return arr[0];}

Not being able to take an address of an array's front element is not a viable solution.  The array range's business is not to restrict access to the first element, it's simply to conform to a certain API.

This all comes down to an incorrect belief that properties are simply front ends for private variables.  They are not, even when many languages make such things necessary or easy to implement (objective C comes to mind).

There are plenty of different uses of properties, and redirecting access to another variable (as does the above function) is certainly a valid use.  I don't think we should make rules that are focused on specific use cases while discarding or diminishing others.

-Steve

Good point, but I think that this is pretty much a corner case where it occasionally might be useful, but it does not rectify the consequences: The moment you are allowed to take the address, you are stuck with the ref returning accessor and can not change it later to a get/set pair.

An easy solution:

	auto a=myrange.front;
	someCFunc(&a);
	myrange.front=a;

It is a little more to write, and maybe a tad slower (depending on the smartness of the compiler), but we maintain the property guarantees, which seems to me to be a very valuable goal.


Best regards,

Robert

On Thu, 2013-02-07 at 19:43 +0100, FG wrote:
> 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.
> 

On Thursday, 7 February 2013 at 16:33:46 UTC, Andrei Alexandrescu wrote:
> On 2/7/13 9:44 AM, eles wrote:
>> On Wednesday, 6 February 2013 at 22:10:29 UTC, Robert wrote:
> I think the sarcasm is uncalled for. We're doing our best here and our intent is indeed to have properties emulate fields.

At least it caught a bit of attention... but I agree. Sorry.

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

That's no reason to make them functions instead. Or something so far from fields that becomes cumbersome.

The basic idea is: "properties are (a little more) that fields with validation and directional access control". That's all.

Notice that in the brackets above there is "more", but also it is prefixed by "a little".

On 2/7/13 2:13 PM, Steven Schveighoffer wrote:
> On Thu, 07 Feb 2013 13:05:50 -0500, Robert <jfanatiker@gmx.at> wrote:
>
>> 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.
>
> @property ref T front(T[] arr) { return arr[0];}
>
> Not being able to take an address of an array's front element is not a
> viable solution. The array range's business is not to restrict access to
> the first element, it's simply to conform to a certain API.

I think the point we're making here with T* vs ref T is that most good work could and should be done with references that have provable scoping. Needing the actual address of something should not be casual.

Andrei

It depends on how we are going to define properties and with all the arguments in the discussions it seems to me that the only sane way to design properties is as simple front ends for private fields (which is my understanding of properties anyway).

But with optional parantheses the @property would also not be necessary for this case. So such use cases would need to be handled by normal functions. It would simply not be a property by definition.

Redirecting access would not be the purpose of properties but for functions returning refs. And you are free to take the address then with &arr.front().


> @property ref T front(T[] arr) { return arr[0];}

Do you have any other UFCS examples, where @property would seem to be appropriate?

> 
> This all comes down to an incorrect belief that properties are simply front ends for private variables.  They are not, even when many languages make such things necessary or easy to implement (objective C comes to mind).
> 
> There are plenty of different uses of properties, and redirecting access to another variable (as does the above function) is certainly a valid use.  I don't think we should make rules that are focused on specific use cases while discarding or diminishing others.

It all depends on definitions. If you define an integer as an integral type, you would not expect it to do floating point arithmetic. Although there are use cases for floating point operations, but an integer is just the wrong tool for it.

Just to be clear here, with DIP23 in place, the syntax at the caller side for:

@property ref T front(T[] arr) { return arr[0];}

would not change if you remove the @property. So little code breakage here and the code that breaks is easily fixed by removing @property.

On Thu, 07 Feb 2013 15:14:22 -0500, Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org> wrote:

> On 2/7/13 2:13 PM, Steven Schveighoffer wrote:
>> On Thu, 07 Feb 2013 13:05:50 -0500, Robert <jfanatiker@gmx.at> wrote:
>>
>>> 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.
>>
>> @property ref T front(T[] arr) { return arr[0];}
>>
>> Not being able to take an address of an array's front element is not a
>> viable solution. The array range's business is not to restrict access to
>> the first element, it's simply to conform to a certain API.
>
> I think the point we're making here with T* vs ref T is that most good work could and should be done with references that have provable scoping. Needing the actual address of something should not be casual.

That is fine, as long as it is possible, and NOT overly-complex.  Think of it like casting.  Casting is essentially a no-op for performance, but is possible, explicit (well, *mostly* explicit), and straightforward.

I don't see the problem with restricting address-taking of ref parameters or return values to @system code.  Well, other than making it less attractive to code in @safe mode, but then again, I don't see myself using it much the way it is now.

Most certainly, we should not outlaw taking the address of ref parameters because it's "hard" to solve the problem of getting property delegates (but only as long as people insist that adding to __traits is taboo).  That was MY point.  Your "solving" a problem by ignoring it, and also causing 10 problems elsewhere.

-Steve

On Thu, 07 Feb 2013 15:57:56 -0500, Robert <jfanatiker@gmx.at> wrote:

> Just to be clear here, with DIP23 in place, the syntax at the caller
> side for:
>
> @property ref T front(T[] arr) { return arr[0];}
>
> would not change if you remove the @property. So little code breakage
> here and the code that breaks is easily fixed by removing @property.

int delegate()[] arr;

arr.front();

-Steve

On Thu, 2013-02-07 at 16:08 -0500, Steven Schveighoffer wrote:
> int delegate()[] arr;
> 
> arr.front();

That's part of the mess we are trying to clean up here? As of DIP 23,
you would have to do arr.front()() in order to actually call the
delegate.

The current behaviour is also that you have to do arr.front()() in order to actually call the function. So with DIP23 in effect you would actually have to remove @property in order to be backwards compatible.

On 2/7/13 4:07 PM, Steven Schveighoffer wrote:
> Most certainly, we should not outlaw taking the address of ref
> parameters because it's "hard" to solve the problem of getting property
> delegates (but only as long as people insist that adding to __traits is
> taboo). That was MY point. Your "solving" a problem by ignoring it, and
> also causing 10 problems elsewhere.

I agree that shouldn't be a motivator. To me it's like, "hey, a perk!"

Andrei