On 18-01-2012 21:26, Nick Sabalausky wrote:
> "Jacob Carlborg"<doob@me.com>  wrote in message
> news:jf6e7a$1929$1@digitalmars.com...
>>
>> method:
>> no parameters - parentheses are optional
>
> FWIW, I always do a double-take when I see code like:
>
> functionName;
> //or
> object.functionName;
>
> It sets off all mannar of "no-effect expression!" bells and buzzers in my
> head every time I look at it, which I then have to silence.
>
>
>

Indeed! It's so unnatural in a C-based language. See, if the semicolon wasn't there, it would be a different story (see most ML-style functional languages).

-- 
- Alex

Alex Rønne Petersen wrote:
> if the semicolon wasn't there
... it would look like a parameterless command in a shell:
    pwd, ls, du, df, date, uptime, ...

-manfred

On 18/01/12 12:52 AM, Timon Gehr wrote:
> On 01/18/2012 01:40 AM, Jonathan M Davis wrote:
>> On Tuesday, January 17, 2012 19:31:25 bearophile wrote:
>>> Nick Sabalausky:
>>>> Without properties, member function access *ANY* many value
>>>> accesses are "a.b()". Is this member value a plain-old-var or a
>>>> function?
>>>> Who knows! It's a leeked out implementation detail, hooray!
>>>
>>> I have a partially related question.
>>>
>>> Currently this code compiles even with -property:
>>>
>>> void main() {
>>> int[int] aa = [1:2];
>>> auto byval = aa.byValue();
>>> }
>>>
>>> But I think byValue is a property, so isn't it right to give a
>>> compilation
>>> error if you add () after the name of a property?
>>
>> Definitely a bug. Strict enforcement requires that parens be used on all
>> function calls and that no properties use parens. If you use parens on
>> them,
>> that would mean that you're using them on the return value of the
>> property
>> (e.g. opCall) - and in fact, that's one of the main reasons that
>> @property was
>> added in the first place, since without enforcement, property
>> functions which
>> return a delegate result in an ambiguity.
>>
>> - Jonathan M Davis
>
> A related and way more embarrassing problem is that lazy function
> parameters have the same issue.
>
> This program prints nothing:
> import std.stdio;
> void foo(lazy void delegate() dg){
> dg();
> }
> void main(){
> foo({writeln("hello");});
> }

Perhaps I'm wrong, but this issue is different.

The code you have written is something that would be written by someone that doesn't understand how lazy works. You have to use () to un-lazy it, and then () again to invoke the delegate. There is no ambiguity like there is with property delegates.

On 19-01-2012 01:41, Peter Alexander wrote:
> On 18/01/12 12:52 AM, Timon Gehr wrote:
>> On 01/18/2012 01:40 AM, Jonathan M Davis wrote:
>>> On Tuesday, January 17, 2012 19:31:25 bearophile wrote:
>>>> Nick Sabalausky:
>>>>> Without properties, member function access *ANY* many value
>>>>> accesses are "a.b()". Is this member value a plain-old-var or a
>>>>> function?
>>>>> Who knows! It's a leeked out implementation detail, hooray!
>>>>
>>>> I have a partially related question.
>>>>
>>>> Currently this code compiles even with -property:
>>>>
>>>> void main() {
>>>> int[int] aa = [1:2];
>>>> auto byval = aa.byValue();
>>>> }
>>>>
>>>> But I think byValue is a property, so isn't it right to give a
>>>> compilation
>>>> error if you add () after the name of a property?
>>>
>>> Definitely a bug. Strict enforcement requires that parens be used on all
>>> function calls and that no properties use parens. If you use parens on
>>> them,
>>> that would mean that you're using them on the return value of the
>>> property
>>> (e.g. opCall) - and in fact, that's one of the main reasons that
>>> @property was
>>> added in the first place, since without enforcement, property
>>> functions which
>>> return a delegate result in an ambiguity.
>>>
>>> - Jonathan M Davis
>>
>> A related and way more embarrassing problem is that lazy function
>> parameters have the same issue.
>>
>> This program prints nothing:
>> import std.stdio;
>> void foo(lazy void delegate() dg){
>> dg();
>> }
>> void main(){
>> foo({writeln("hello");});
>> }
>
> Perhaps I'm wrong, but this issue is different.
>
> The code you have written is something that would be written by someone
> that doesn't understand how lazy works. You have to use () to un-lazy
> it, and then () again to invoke the delegate. There is no ambiguity like
> there is with property delegates.

But couldn't that be considered leaking an implementation detail of lazy values? Or is this intentional design?

-- 
- Alex

On 01/19/2012 01:41 AM, Peter Alexander wrote:
> On 18/01/12 12:52 AM, Timon Gehr wrote:
>> On 01/18/2012 01:40 AM, Jonathan M Davis wrote:
>>> On Tuesday, January 17, 2012 19:31:25 bearophile wrote:
>>>> Nick Sabalausky:
>>>>> Without properties, member function access *ANY* many value
>>>>> accesses are "a.b()". Is this member value a plain-old-var or a
>>>>> function?
>>>>> Who knows! It's a leeked out implementation detail, hooray!
>>>>
>>>> I have a partially related question.
>>>>
>>>> Currently this code compiles even with -property:
>>>>
>>>> void main() {
>>>> int[int] aa = [1:2];
>>>> auto byval = aa.byValue();
>>>> }
>>>>
>>>> But I think byValue is a property, so isn't it right to give a
>>>> compilation
>>>> error if you add () after the name of a property?
>>>
>>> Definitely a bug. Strict enforcement requires that parens be used on all
>>> function calls and that no properties use parens. If you use parens on
>>> them,
>>> that would mean that you're using them on the return value of the
>>> property
>>> (e.g. opCall) - and in fact, that's one of the main reasons that
>>> @property was
>>> added in the first place, since without enforcement, property
>>> functions which
>>> return a delegate result in an ambiguity.
>>>
>>> - Jonathan M Davis
>>
>> A related and way more embarrassing problem is that lazy function
>> parameters have the same issue.
>>
>> This program prints nothing:
>> import std.stdio;
>> void foo(lazy void delegate() dg){
>> dg();
>> }
>> void main(){
>> foo({writeln("hello");});
>> }
>
> Perhaps I'm wrong, but this issue is different.
>
> The code you have written is something that would be written by someone
> that doesn't understand how lazy works.

It is written by someone who understands how it should work.

> You have to use () to un-lazy

What would 'un-lazying' be and what is supposed to be its effect?

> it, and then () again to invoke the delegate. There is no ambiguity like
> there is with property delegates.

The code has exactly the same semantics whether or not you write the parens after a lazy variable except for the case when it is a delegate or function pointer.

On 01/19/2012 01:38 AM, Alex Rønne Petersen wrote:
> On 19-01-2012 01:41, Peter Alexander wrote:
>> On 18/01/12 12:52 AM, Timon Gehr wrote:
>>> On 01/18/2012 01:40 AM, Jonathan M Davis wrote:
>>>> On Tuesday, January 17, 2012 19:31:25 bearophile wrote:
>>>>> Nick Sabalausky:
>>>>>> Without properties, member function access *ANY* many value
>>>>>> accesses are "a.b()". Is this member value a plain-old-var or a
>>>>>> function?
>>>>>> Who knows! It's a leeked out implementation detail, hooray!
>>>>>
>>>>> I have a partially related question.
>>>>>
>>>>> Currently this code compiles even with -property:
>>>>>
>>>>> void main() {
>>>>> int[int] aa = [1:2];
>>>>> auto byval = aa.byValue();
>>>>> }
>>>>>
>>>>> But I think byValue is a property, so isn't it right to give a
>>>>> compilation
>>>>> error if you add () after the name of a property?
>>>>
>>>> Definitely a bug. Strict enforcement requires that parens be used on
>>>> all
>>>> function calls and that no properties use parens. If you use parens on
>>>> them,
>>>> that would mean that you're using them on the return value of the
>>>> property
>>>> (e.g. opCall) - and in fact, that's one of the main reasons that
>>>> @property was
>>>> added in the first place, since without enforcement, property
>>>> functions which
>>>> return a delegate result in an ambiguity.
>>>>
>>>> - Jonathan M Davis
>>>
>>> A related and way more embarrassing problem is that lazy function
>>> parameters have the same issue.
>>>
>>> This program prints nothing:
>>> import std.stdio;
>>> void foo(lazy void delegate() dg){
>>> dg();
>>> }
>>> void main(){
>>> foo({writeln("hello");});
>>> }
>>
>> Perhaps I'm wrong, but this issue is different.
>>
>> The code you have written is something that would be written by someone
>> that doesn't understand how lazy works. You have to use () to un-lazy
>> it, and then () again to invoke the delegate. There is no ambiguity like
>> there is with property delegates.
>
> But couldn't that be considered leaking an implementation detail of lazy
> values? Or is this intentional design?
>

I suppose it is an implementation relic.

On Thursday, January 19, 2012 01:38:23 Alex Rønne Petersen wrote:
> But couldn't that be considered leaking an implementation detail of lazy values? Or is this intentional design?

The language requires that lazy parameters be accessed with (). That leaks the fact that the variable is lazy into the function body, but whether it leaks how lazy parameters are implemented is debatable. The same syntax could be used with a different implementation underneath the hood.

But the fact that you have to use double parens on a lazy delegate isn't leaking any kind of implemenatation detail. It's the natural extension of the syntax for lazy. var() gives you the value of the lazy parameter var, and so if you want to call var (or use opCall or it), then you need another set of parens - var()().

Whether requiring parens on lazy parameters is a good design decision is debatable, but I don't see any leaking of implementation details in it. The syntax chosen was probably chosen because it's implemented with a delegate, but the fact that it's implemented with a delegate is still an implementation detail which could theoretically be changed.

- Jonathan M Davis

On 01/19/2012 01:52 AM, Jonathan M Davis wrote:
> On Thursday, January 19, 2012 01:38:23 Alex Rønne Petersen wrote:
>> But couldn't that be considered leaking an implementation detail of lazy
>> values? Or is this intentional design?
>
> The language requires that lazy parameters be accessed with (). That leaks the
> fact that the variable is lazy into the function body, but whether it leaks
> how lazy parameters are implemented is debatable. The same syntax could be
> used with a different implementation underneath the hood.
>
> But the fact that you have to use double parens on a lazy delegate isn't
> leaking any kind of implemenatation detail. It's the natural extension of the
> syntax for lazy. var() gives you the value of the lazy parameter var, and so
> if you want to call var (or use opCall or it), then you need another set of
> parens - var()().
>
> Whether requiring parens on lazy parameters is a good design decision is
> debatable,

They are only required if you want to call a lazy delegate/function pointer. They are optional in all other cases.

> but I don't see any leaking of implementation details in it. The
> syntax chosen was probably chosen because it's implemented with a delegate,
> but the fact that it's implemented with a delegate is still an implementation
> detail which could theoretically be changed.
>

On Thursday, January 19, 2012 03:18:22 Timon Gehr wrote:
> They are only required if you want to call a lazy delegate/function pointer. They are optional in all other cases.

I could have sworn that they were required. If not, then yeah, that seems pretty bad. It's certainly not the end of the world, but it's inconsistent in away that has caused problem for some people (Andrej was posting about it just the other day). So, it's poor design in that respect.

- Jonathan M Davis

On 2012-01-18 21:26, Nick Sabalausky wrote:
> "Jacob Carlborg"<doob@me.com>  wrote in message
> news:jf6e7a$1929$1@digitalmars.com...
>>
>> method:
>> no parameters - parentheses are optional
>
> FWIW, I always do a double-take when I see code like:
>
> functionName;
> //or
> object.functionName;
>
> It sets off all mannar of "no-effect expression!" bells and buzzers in my
> head every time I look at it, which I then have to silence.

It's even more fun in Ruby which doesn't require semicolons :) Just:

functionName

-- 
/Jacob Carlborg