On Tuesday, 20 November 2012 at 19:06:22 UTC, Jonathan M Davis wrote:
> Given the fact that this subject is extremely devisive, I suspect that the
> best that we can hope for at this point is for lax property enforcement

@property shouldn't be about enforcement. This is the fundamental flaw in the -property switch. While I think you and I are talking about the same goal, this is an important distinction to make: the fix isn't syntax. It is a semantic rewrite.

After referencing a property is rewritten to be a call, the syntax will just work:

@property int foo() {}

int a = foo(); // the error here is NOT "you must not use () on properties". It is "type int is not callable"



This is something that's bothered me about the @property debate since day one: we spend all this time talking about syntax.... but that's a side effect, not the core question.

On Tuesday, November 20, 2012 20:12:56 Adam D. Ruppe wrote:
> On Tuesday, 20 November 2012 at 19:06:22 UTC, Jonathan M Davis
> 
> wrote:
> > Given the fact that this subject is extremely devisive, I
> > suspect that the
> > best that we can hope for at this point is for lax property
> > enforcement
> 
> @property shouldn't be about enforcement. This is the fundamental flaw in the -property switch. While I think you and I are talking about the same goal, this is an important distinction to make: the fix isn't syntax. It is a semantic rewrite.
> 
> After referencing a property is rewritten to be a call, the syntax will just work:
> 
> @property int foo() {}
> 
> int a = foo(); // the error here is NOT "you must not use () on
> properties". It is "type int is not callable"
> 
> This is something that's bothered me about the @property debate since day one: we spend all this time talking about syntax.... but that's a side effect, not the core question.

It's the same result. @property means that the function is treated as a variable, so it doesn't make sense that parens be used. If the error treats it like a variable to the point that it complains about trying to use parens on the variable rather than the fact that you tried to use parens on an @property function, all the better.

- Jonathan M Davis

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];

On Tuesday, 20 November 2012 at 13:35:14 UTC, Adam D. Ruppe wrote:
> On Tuesday, 20 November 2012 at 06:06:21 UTC, deadalnix wrote:
>> I'm not sure how it fit in the DIP but &funName is ambiguous when funName return a reference.
>
> We can just define this away: &funName if it isn't a @property is the address of the function.
>

So this is impossible to get the address of the returned
reference.

> If it is a @property, ALL operations work on the return value, so it is rewritten as &(funName()).

I agree that this is ho it should work.

On 11/20/2012 09:56 PM, deadalnix wrote:
> On Tuesday, 20 November 2012 at 13:35:14 UTC, Adam D. Ruppe wrote:
>> On Tuesday, 20 November 2012 at 06:06:21 UTC, deadalnix wrote:
>>> I'm not sure how it fit in the DIP but &funName is ambiguous when
>>> funName return a reference.
>>
>> We can just define this away: &funName if it isn't a @property is the
>> address of the function.
>>
>
> So this is impossible to get the address of the returned
> reference.
>

&funName()

>> If it is a @property, ALL operations work on the return value, so it
>> is rewritten as &(funName()).
>
> I agree that this is ho it should work.

+1.

On Tuesday, 20 November 2012 at 19:12:58 UTC, Adam D. Ruppe wrote:
> On Tuesday, 20 November 2012 at 19:06:22 UTC, Jonathan M Davis wrote:
>> Given the fact that this subject is extremely devisive, I suspect that the
>> best that we can hope for at this point is for lax property enforcement
>
> @property shouldn't be about enforcement. This is the fundamental flaw in the -property switch. While I think you and I are talking about the same goal, this is an important distinction to make: the fix isn't syntax. It is a semantic rewrite.
>
> After referencing a property is rewritten to be a call, the syntax will just work:
>
> @property int foo() {}
>
> int a = foo(); // the error here is NOT "you must not use () on properties". It is "type int is not callable"
>
>

Yes

>
> This is something that's bothered me about the @property debate since day one: we spend all this time talking about syntax.... but that's a side effect, not the core question.

+1

On Tuesday, 20 November 2012 at 21:19:20 UTC, Timon Gehr wrote:
> On 11/20/2012 09:56 PM, deadalnix wrote:
>> On Tuesday, 20 November 2012 at 13:35:14 UTC, Adam D. Ruppe wrote:
>>> On Tuesday, 20 November 2012 at 06:06:21 UTC, deadalnix wrote:
>>>> I'm not sure how it fit in the DIP but &funName is ambiguous when
>>>> funName return a reference.
>>>
>>> We can just define this away: &funName if it isn't a @property is the
>>> address of the function.
>>>
>>
>> So this is impossible to get the address of the returned
>> reference.
>>
>
> &funName()
>

So now funName and funName are not equivalent anymore. Special cases should be removed, not added.

>>> If it is a @property, ALL operations work on the return value, so it
>>> is rewritten as &(funName()).
>>
>> I agree that this is ho it should work.
>
> +1.

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.

Le 20/11/2012 04:33, Jacob Carlborg a écrit :
> On 2012-11-20 08:48, thedeemon wrote:
>
>> This is just an old habit to see identifier with parens as a function
>> call and identifier without parens as a variable, so calling functions
>> without parens seem too unconventional to you. However there are many
>> languages which dropped this tradition and they are known for being
>> expressive and concise, that's why people love them. Recently we saw an
>> article from Walter about component programming which one could say was
>> really about function composition. It's really convenient to write code
>> in conveyor-style, this is what we see often in functional languages, as
>> well as some dynamic OO ones. For example, the task of reversing words
>> in a string may look like:
>
> I completely agree.
>
>> "one two three".split.map{|s| s.reverse}.join(' ')
>> in Ruby
>
> In this particular case you can use a shorter form of the map call:
>
> "one two three".split.map(&:reverse).join(' ')
>
>> print . unwords . map reverse . words $ "one two three"
>> in Haskell
>>
>> "one two three" |> split " " |> List.map reverse |> String.join " " |>
>> print_string
>> in OCaml
>> and something similar and even without dots in Scala.
>
> Wouldn't the Scala syntax look fairly similar to Ruby:
>
> "one two three".split.map(reverse).join(' ')
>

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

>> Ease of chaining functions together is one of the things that make those
>> languages so pleasant to work with. I love to have the same in current D
>> and it would be a pity to lose it due to a clash with some old-fashioned
>> tradition.
>
> I completely agree again.
>

On 2012-11-21 07:55, deadalnix wrote:

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

I said "fairly similar" not "exactly the same" :)

-- 
/Jacob Carlborg