November 21, 2012
On Wed, 21 Nov 2012 06:07:51 -0000, deadalnix <deadalnix@gmail.com> wrote:

> Le 20/11/2012 12:18, Timon Gehr a écrit :
>> On 11/20/2012 02:49 PM, Regan Heath wrote:
>>> On Tue, 20 Nov 2012 13:26:15 -0000, Adam D. Ruppe
>>> <destructionator@gmail.com> wrote:
>>>
>>>> On Tuesday, 20 November 2012 at 12:44:44 UTC, Jacob Carlborg wrote:
>>>>> Should this be allowed for functions that isn't marked with @property:
>>>>>
>>>>> foo = 3;
>>>>
>>>> Yes. We should *only* be changing the way @property is implemented.
>>>> (Namely, actually implementing it!)
>>>>
>>>> Don't want to break existing code. The new changes must be opt in.
>>>
>>> Usually I'd agree but this is a case of a wart we should just remove
>>> IMO. The fix for breaking cases is simple, add @property.
>>>
>>>> If there's both an @property setter and a regular function, the
>>>> property should be used here.
>>>
>>> Agreed. But it's waay clearer whats going on if @property is required
>>> to call functions using this syntax.
>>>
>>> R
>>>
>>
>> Not really.
>>
>> @property T front(T)(T[] arr) { return arr[0]; }
>>
>> [1,2,3,4].front;
>>
>> front = [1,2,3,4];
>>
>
> I conclude that @property should be limited to member function or UFCS calls. Otherwize, we get really weird stuffs going on.

Such was my assumption in this case :p

R

-- 
Using Opera's revolutionary email client: http://www.opera.com/mail/
November 21, 2012
On Wednesday, 21 November 2012 at 07:44:36 UTC, Jacob Carlborg wrote:
> On 2012-11-21 07:55, deadalnix wrote:
>
>> Note the map(reverse) and not map(&reverse)
>
> I said "fairly similar" not "exactly the same" :)

I don't understand why dropping () is that a big deal when dropping & isn't.
November 21, 2012
On 11/21/2012 06:53 PM, deadalnix wrote:
> On Wednesday, 21 November 2012 at 07:44:36 UTC, Jacob Carlborg wrote:
>> On 2012-11-21 07:55, deadalnix wrote:
>>
>>> Note the map(reverse) and not map(&reverse)
>>
>> I said "fairly similar" not "exactly the same" :)
>
> I don't understand why dropping () is that a big deal when dropping &
> isn't.

Relative frequencies. Amount of visual noise. People are used to it.
November 21, 2012
On 2012-11-21 18:53, deadalnix wrote:

> I don't understand why dropping () is that a big deal when dropping &
> isn't.

Now I'm really confused. What did you mean when you original wrote:

"Note the map(reverse) and not map(&reverse)"

-- 
/Jacob Carlborg
November 22, 2012
On Wednesday, 21 November 2012 at 18:07:42 UTC, Jacob Carlborg wrote:
> On 2012-11-21 18:53, deadalnix wrote:
>
>> I don't understand why dropping () is that a big deal when dropping &
>> isn't.
>
> Now I'm really confused. What did you mean when you original wrote:
>
> "Note the map(reverse) and not map(&reverse)"

I meant that because of the fact that function isn't called implicitly, it is possible to pass it directly without having the & . The & is a source of noise as the () are and introduce really complicated rules in the language to know if funName have to be executed or not.

Scala's design is consistent on this point. D's isn't because we pursue conflicting goals. Those have been conflated in a messy implementation defined behavior ATM.

We have to accept to break some code here or to stick with current implementation and accept that is is inconsistent and messy (and sometime leading to very weird possibilities like Timon Gehr demonstrated).
December 02, 2012
On 11/20/12, Jonathan M Davis <jmdavisProg@gmx.com> wrote:
> I suspect that the
> best that we can hope for at this point is for lax property enforcement -
> that is that it's enforced that @property functions are used as properties but
> there is no enforcement that non-@property functions be called with parens.

Here's a good reason why the latter isn't the best idea: http://d.puremagic.com/issues/show_bug.cgi?id=2159

The reporter made the mistake of issuing a function call instead of taking an address of a function, which in turn invoked a different function overload with the temporary result.
December 02, 2012
On Sunday, December 02, 2012 01:16:40 Andrej Mitrovic wrote:
> On 11/20/12, Jonathan M Davis <jmdavisProg@gmx.com> wrote:
> > I suspect that the
> > best that we can hope for at this point is for lax property enforcement -
> > that is that it's enforced that @property functions are used as properties
> > but there is no enforcement that non-@property functions be called with
> > parens.
> Here's a good reason why the latter isn't the best idea: http://d.puremagic.com/issues/show_bug.cgi?id=2159
> 
> The reporter made the mistake of issuing a function call instead of taking an address of a function, which in turn invoked a different function overload with the temporary result.

I'd _love_ to make it illegal to call non-property functions without parens, and there are definitely folks around here who agree with me, including some on the Phobos dev team (e.g. Steven has always agreed with me when this has come up), but there are enough folks around here here who like to call functions without parens - especially with UFCS and templated functions like map or filter - that I don't think that that's going to fly at this point. Maybe if Andrei agreed it could happen, but he's hated the idea of @property practically from the get-go, and when you combine that with the facts that strengthening @property enforcement as originally intended would break a lot of code at this point and that Walter absolutely hates breaking people's code for pratically any reason whatsoever, I expect that Walter would be against it too. And with both of them against it, it just wouldn't happen.

The workaround for the bug in question is to not overload functions that take function pointers with an overload that takes something other than a function pointer or delegate. Even that's not perfect, because a function could return a function pointer or delegate, but at this point, I just don't see Andrei and Walter agreeing to the level of property enforcement required to stop it, even if they had agreed to it in the past. UFCS seems to be the feature that puts the nail in the coffin of that idea, because people don't want to do stuff like range.filter!(a => a.func() < 2)() but would rather do range.filter!(a => a.func() < 2).

- Jonathan M Davis
December 02, 2012
On Tuesday, 20 November 2012 at 04:12:54 UTC, Andrei Alexandrescu wrote:
> On 11/19/12 5:23 PM, Rob T wrote:
>> I don't have an answer, but there may be more to the picture than we think.
>
> I agree. In particular I find it a specious argument to insist on religiously associating "()" with function calling and the lack thereof with variable access. I don't see myself, when seeing an expression like "generator(x, y, z).map!(x => x * x)()", going like "holy cow, good I saw those trailing parens, otherwise I would've sworn it was a variable". Trailing parens in UFCS chains are just warts, this is the reality. Let's deal with it.
>
>
> Andrei

And what do you think about map!(x => x * x) = generator(x, y, z) ?
December 02, 2012
On Sunday, 2 December 2012 at 01:04:03 UTC, Jonathan M Davis wrote:
> On Sunday, December 02, 2012 01:16:40 Andrej Mitrovic wrote:
>> On 11/20/12, Jonathan M Davis <jmdavisProg@gmx.com> wrote:
>> > I suspect that the
>> > best that we can hope for at this point is for lax property enforcement -
>> > that is that it's enforced that @property functions are used as properties
>> > but there is no enforcement that non-@property functions be called with
>> > parens.
>> Here's a good reason why the latter isn't the best idea:
>> http://d.puremagic.com/issues/show_bug.cgi?id=2159
>> 
>> The reporter made the mistake of issuing a function call instead of
>> taking an address of a function, which in turn invoked a different
>> function overload with the temporary result.
>
> I'd _love_ to make it illegal to call non-property functions without parens,
> and there are definitely folks around here who agree with me, including some on
> the Phobos dev team (e.g. Steven has always agreed with me when this has come
> up), but there are enough folks around here here who like to call functions
> without parens - especially with UFCS and templated functions like map or
> filter - that I don't think that that's going to fly at this point.

As said before a lot of such usages can be made valid with a sane semantic using opDispatch.

BTW, I can't edit in the wiki? When I try to do so, it says me that deadalnix is an invalid username. If I need to register, I didn't found out how.
December 02, 2012
On Sunday, December 02, 2012 07:49:52 deadalnix wrote:
> And what do you think about map!(x => x * x) = generator(x, y, z)
> ?

What's that even supposed to mean? map has been given no function argument either as UFCS or with a normal function call, so it's not being called. And even if it were, it wouldn't result in an lvalue, so putting it on the left of an assignment makes no sense. I have no idea what you're trying to do here.

- Jonathan M Davis