Andrei Alexandrescu wrote:
> In wake of the many excellent comments and suggestions made here, I made one more pass through the draft proposal for ranges.
> 
> http://ssli.ee.washington.edu/~aalexand/d/tmp/std_range.html
> 
> There are some comments in red illustrating some uncertainties (not all), and the names of the primitives have been updated. Bicycle shed galore! But don't forget to comment on the reactor as well :o).
> 
> 
> Andrei

"""
All ranges satisfy certain invariants outlined below. (r is an object of a range type R.)
"""

By "object" you actually mean struct no? Struct instance to be even more precise.


Also, some more on important bike shed issues:
    for (; !src.done; src.next)
    {
        tgt.put(src.head);
    }

As a matter of coding style conventions, I would say that using the implicit property function call feature on a function that changes state is *bad* style, and surely hope the community would agree on that.
So "src.next" would be must better as "src.next()" as "src.next" really just makes me cringe.


-- 
Bruno Medeiros - Software Developer, MSc. in CS/E graduate
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D

In article <gbgpak$2q10$1@digitalmars.com>, brunodomedeiros+spam@com.gmail says...
> Also, some more on important bike shed issues:
>      for (; !src.done; src.next)
>      {
>          tgt.put(src.head);
>      }
> 
> As a matter of coding style conventions, I would say that using the
> implicit property function call feature on a function that changes state
> is *bad* style, and surely hope the community would agree on that.
> So "src.next" would be must better as "src.next()" as "src.next" really
> just makes me cringe.

I think that property function call feature in general adds an unnecessary ambiguity to the language.  I'd prefer functions to be callable only with regular function call syntax, and properties be usable only with member access syntax.  The same stands for 'unified function call' feature: if you want to inject a method into an 'array of chars' class you do so explicitly, and only the member call syntax is allowed on that method.  Otherwise code tends to become ambiguous and unreadable.

Sergey Gromov wrote:
> In article <gbgpak$2q10$1@digitalmars.com>, brunodomedeiros+spam@com.gmail says...
>> Also, some more on important bike shed issues:
>>      for (; !src.done; src.next)
>>      {
>>          tgt.put(src.head);
>>      }
>>
>> As a matter of coding style conventions, I would say that using the implicit property function call feature on a function that changes state is *bad* style, and surely hope the community would agree on that.
>> So "src.next" would be must better as "src.next()" as "src.next" really just makes me cringe.
> 
> I think that property function call feature in general adds an unnecessary ambiguity to the language.  I'd prefer functions to be callable only with regular function call syntax, and properties be usable only with member access syntax.  The same stands for 'unified function call' feature: if you want to inject a method into an 'array of chars' class you do so explicitly, and only the member call syntax is allowed on that method.  Otherwise code tends to become ambiguous and unreadable.

Experience with other languages has shown that using identical syntax for genuine member access and member function access helps maintainability because it allows a type implementer to switch back and forth between implementing a property as a direct member or as a function, transparently to that type's use.

Two nice examples of the undesirability of distinct notation are the std::pair first and second members in the STL, which made what seemed like an innocuous decision turn into a catastrophe, and also std::numeric_limits<T>::min and max, which partially prompted creation of an entire language feature(!).


Andrei

Bruno Medeiros wrote:
> Andrei Alexandrescu wrote:
>> In wake of the many excellent comments and suggestions made here, I made one more pass through the draft proposal for ranges.
>>
>> http://ssli.ee.washington.edu/~aalexand/d/tmp/std_range.html
>>
>> There are some comments in red illustrating some uncertainties (not all), and the names of the primitives have been updated. Bicycle shed galore! But don't forget to comment on the reactor as well :o).
>>
>>
>> Andrei
> 
> """
> All ranges satisfy certain invariants outlined below. (r is an object of a range type R.)
> """
> 
> By "object" you actually mean struct no? Struct instance to be even more precise.
> 
> 
> Also, some more on important bike shed issues:
>     for (; !src.done; src.next)
>     {
>         tgt.put(src.head);
>     }
> 
> As a matter of coding style conventions, I would say that using the implicit property function call feature on a function that changes state is *bad* style, and surely hope the community would agree on that.

I sure hope they won't agree to an unsupported assertion.

> So "src.next" would be must better as "src.next()" as "src.next" really just makes me cringe.

With me it's the opposite, particularly after I've written and stared at a few hundreds of "()"s due to a compiler bug.


Andrei

In article <gbgu0h$5sq$1@digitalmars.com>, SeeWebsiteForEmail@erdani.org says...
> Sergey Gromov wrote:
> > I think that property function call feature in general adds an unnecessary ambiguity to the language.  I'd prefer functions to be callable only with regular function call syntax, and properties be usable only with member access syntax.  The same stands for 'unified function call' feature: if you want to inject a method into an 'array of chars' class you do so explicitly, and only the member call syntax is allowed on that method.  Otherwise code tends to become ambiguous and unreadable.
> 
> Experience with other languages has shown that using identical syntax for genuine member access and member function access helps maintainability because it allows a type implementer to switch back and forth between implementing a property as a direct member or as a function, transparently to that type's use.

Sorry I may have been unclear.  I'm not against interchangeability between properties and property accessor methods.  I'm against using property accessors as methods, and against using methods as if they were property accessors.  The current situation actually breaks maintainability because after somebody used .length() you cannot replace it with a public variable anymore.  And you cannot replace

public void delegate(int) foo;

with an accessor method because the code 'instance.foo();' will stop working as it used to.

Andrei Alexandrescu wrote:
> Sergey Gromov wrote:
>> In article <gbgpak$2q10$1@digitalmars.com>, brunodomedeiros+spam@com.gmail says...
>>> Also, some more on important bike shed issues:
>>>      for (; !src.done; src.next)
>>>      {
>>>          tgt.put(src.head);
>>>      }
>>>
>>> As a matter of coding style conventions, I would say that using the
>>> implicit property function call feature on a function that changes
>>> state is *bad* style, and surely hope the community would agree on that.
>>> So "src.next" would be must better as "src.next()" as "src.next"
>>> really just makes me cringe.
>>
>> I think that property function call feature in general adds an unnecessary ambiguity to the language.  I'd prefer functions to be callable only with regular function call syntax, and properties be usable only with member access syntax.  The same stands for 'unified function call' feature: if you want to inject a method into an 'array of chars' class you do so explicitly, and only the member call syntax is allowed on that method.  Otherwise code tends to become ambiguous and unreadable.
> 
> Experience with other languages has shown that using identical syntax for genuine member access and member function access helps maintainability because it allows a type implementer to switch back and forth between implementing a property as a direct member or as a function, transparently to that type's use.
> 
> Two nice examples of the undesirability of distinct notation are the std::pair first and second members in the STL, which made what seemed like an innocuous decision turn into a catastrophe, and also std::numeric_limits<T>::min and max, which partially prompted creation of an entire language feature(!).
> 
> 
> Andrei

I've got a few questions regarding this:
suppose D gets a specific syntax for properties like C# has:
for example:
class MyClass {
private int x;
public int X {
  get {
    return x;
  }
  set {
    x = value;
  }
}
}

wouldn't it solve the problem of the implementer switching between a
direct member and a function, transparently to that type's use?
In the above you could remove the data member and re-implement the
get/set by calling suitable functions.

my main question is of style:
is it better in your opinion to allow all functions with no parameters
to be called as "function_name;" (i.e. no parens) and if you need to
refer to the function identifier itself you need to do &func (for
example if you want to pass it as a parameter to a different function)
OR
require an operator such as parens to signify you call the function and
the name without parens will just signify the function itself (so no
need to use &func when func is a parameter) ?

Yigal Chripun wrote:
> Andrei Alexandrescu wrote:
>> Sergey Gromov wrote:
>>> In article <gbgpak$2q10$1@digitalmars.com>,
>>> brunodomedeiros+spam@com.gmail says...
>>>> Also, some more on important bike shed issues:
>>>>      for (; !src.done; src.next)
>>>>      {
>>>>          tgt.put(src.head);
>>>>      }
>>>>
>>>> As a matter of coding style conventions, I would say that using the
>>>> implicit property function call feature on a function that changes
>>>> state is *bad* style, and surely hope the community would agree on that.
>>>> So "src.next" would be must better as "src.next()" as "src.next"
>>>> really just makes me cringe.
>>> I think that property function call feature in general adds an
>>> unnecessary ambiguity to the language.  I'd prefer functions to be
>>> callable only with regular function call syntax, and properties be
>>> usable only with member access syntax.  The same stands for 'unified
>>> function call' feature: if you want to inject a method into an 'array
>>> of chars' class you do so explicitly, and only the member call syntax
>>> is allowed on that method.  Otherwise code tends to become ambiguous
>>> and unreadable.
>> Experience with other languages has shown that using identical syntax
>> for genuine member access and member function access helps
>> maintainability because it allows a type implementer to switch back and
>> forth between implementing a property as a direct member or as a
>> function, transparently to that type's use.
>>
>> Two nice examples of the undesirability of distinct notation are the
>> std::pair first and second members in the STL, which made what seemed
>> like an innocuous decision turn into a catastrophe, and also
>> std::numeric_limits<T>::min and max, which partially prompted creation
>> of an entire language feature(!).
>>
>>
>> Andrei
> 
> I've got a few questions regarding this:
> suppose D gets a specific syntax for properties like C# has:
> for example:
> class MyClass {
> private int x;
> public int X {
>   get {
>     return x;
>   }
>   set {
>     x = value;
>   }
> }
> }
> 
> wouldn't it solve the problem of the implementer switching between a
> direct member and a function, transparently to that type's use?
> In the above you could remove the data member and re-implement the
> get/set by calling suitable functions.

It would solve the problem by adding a language feature. It is unclear to me whether the cost of adding the feature justifies its benefits.

> my main question is of style:
> is it better in your opinion to allow all functions with no parameters
> to be called as "function_name;" (i.e. no parens) and if you need to
> refer to the function identifier itself you need to do &func (for
> example if you want to pass it as a parameter to a different function)
> OR
> require an operator such as parens to signify you call the function and
> the name without parens will just signify the function itself (so no
> need to use &func when func is a parameter) ?

There are a few principles at work here that I consider universal, plus some others that I consider a matter of preference. One principle that I consider universal is that a language should minimize the number of syntactic constructs that are semantically and/or pragmatically meaningless. Another that I also consider universal is that the more frequently-used constructs should be given syntactic priority over the less-used constructs, particularly when the latter are also at risk of breaking the first principle.

C's handling of function names royally breaks both of these principles. It makes

func;

a valid syntactic construct with inoperant semantics and consequently useless pragmatics. Moreover,

a = func;
gunc(func);

both have valid syntax and semantics, but the pragmatics are the infrequently-used manipulations of function addresses in higher-order programming, something C is not quite adept at to start with. (So that makes the state of affairs all the more ironic.)

C++ builds on that irony by making

obj.func;
b = obj.func;
gunc(obj.func);

still syntactically valid but one order of magnitude less useful because they traffic in references to member functions, a contraption that is defined sufficiently bad and inefficient to be useless in practice, and also of a type with a syntax I'd be glad to remove from my memory. (How many here _do_ know that type's syntax and have the scars to prove it?)

So thinking of function call syntax has quite a few deep underpinnings. We shouldn't confuse habit acquired from C and C++ with some fundamental truth or just a matter of preference that can't be decided on an objective basis.

One issue with today's function call syntax in D is that people can write code that is of dubious expressiveness:

writeln = 3;

Properties would solve this problem by confining assignment syntax to themselves only.


Andrei

Andrei Alexandrescu wrote:
> Bruno Medeiros wrote:
>> Andrei Alexandrescu wrote:
>>> In wake of the many excellent comments and suggestions made here, I made one more pass through the draft proposal for ranges.
>>>
>>> http://ssli.ee.washington.edu/~aalexand/d/tmp/std_range.html
>>>
>>> There are some comments in red illustrating some uncertainties (not all), and the names of the primitives have been updated. Bicycle shed galore! But don't forget to comment on the reactor as well :o).
>>>
>>>
>>> Andrei
>>
>> """
>> All ranges satisfy certain invariants outlined below. (r is an object of a range type R.)
>> """
>>
>> By "object" you actually mean struct no? Struct instance to be even more precise.
>>
>>
>> Also, some more on important bike shed issues:
>>     for (; !src.done; src.next)
>>     {
>>         tgt.put(src.head);
>>     }
>>
>> As a matter of coding style conventions, I would say that using the implicit property function call feature on a function that changes state is *bad* style, and surely hope the community would agree on that.
> 
> I sure hope they won't agree to an unsupported assertion.
> 

It's unsupported because it is not an assertion, but more of a subjective opinion, like most coding style conventions (indentation, bracing, etc.). I don't like seeing "src.next" if 'next' isn't either a field, or a function which doesn't change any significant state.


>> So "src.next" would be must better as "src.next()" as "src.next" really just makes me cringe.
> 
> With me it's the opposite, particularly after I've written and stared at a few hundreds of "()"s due to a compiler bug.
> 
> 
> Andrei

I'm not imagining what that situation would be, could you explain a bit more?


-- 
Bruno Medeiros - Software Developer, MSc. in CS/E graduate
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D

Sergey Gromov wrote:
> In article <gbgpak$2q10$1@digitalmars.com>, brunodomedeiros+spam@com.gmail says...
>> Also, some more on important bike shed issues:
>>      for (; !src.done; src.next)
>>      {
>>          tgt.put(src.head);
>>      }
>>
>> As a matter of coding style conventions, I would say that using the implicit property function call feature on a function that changes state is *bad* style, and surely hope the community would agree on that.
>> So "src.next" would be must better as "src.next()" as "src.next" really just makes me cringe.
> 
> I think that property function call feature in general adds an unnecessary ambiguity to the language.  I'd prefer functions to be callable only with regular function call syntax, and properties be usable only with member access syntax.  The same stands for 'unified function call' feature: if you want to inject a method into an 'array of chars' class you do so explicitly, and only the member call syntax is allowed on that method.  Otherwise code tends to become ambiguous and unreadable.

Yes, I full agree, as many others do, as this has been discussed before (the latest discussion: http://www.digitalmars.com/d/archives/digitalmars/D/Omittable_parens_is_an_evil_73881.html)
But that didn't seem to convince any of the higher-ups, so I was hopping to at least have the feature used more sensibly (ie, not being used in functions that are not intended to emulate properties).

-- 
Bruno Medeiros - Software Developer, MSc. in CS/E graduate
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D

Andrei Alexandrescu wrote:
> Bruno Medeiros wrote:
>> As a matter of coding style conventions, I would say that using the implicit property function call feature on a function that changes state is *bad* style, and surely hope the community would agree on that.
> 
> I sure hope they won't agree to an unsupported assertion.
> 

Actually I *do* hate this "feature" ^_^.

And this "feature" has been put to challenged before:
 * Bug 2159. (http://d.puremagic.com/issues/show_bug.cgi?id=2159)
 * "Omitting Parens is an Evil" (http://www.digitalmars.com/d/archives/digitalmars/D/Omittable_parens_is_an_evil_73881.html)
*http://www.digitalmars.com/pnews/read.php?server=news.digitalmars.com&group=D&artnum=17579
But nothing got changed.

To the very least, when using next as a property I assume the call won't produce any secondary effect on src from the syntax, since I'm just reading a state! Not so if one calls src.next() as the "()" is an alarming sign that src _may_ change afterwards. This could is just a problem of personal taste since the compiler does not forbid src.next(), but not so if you're reading other's code.

P.S. If src.next() is too lengthy, why not just adopt ++src?

>> So "src.next" would be must better as "src.next()" as "src.next" really just makes me cringe.
> 
> With me it's the opposite, particularly after I've written and stared at a few hundreds of "()"s due to a compiler bug.
> 
> 
> Andrei