On Friday, 14 February 2014 at 19:24:58 UTC, Marc Schütz wrote:
> On Friday, 14 February 2014 at 16:16:28 UTC, Robin wrote:
>> On Friday, 14 February 2014 at 15:21:04 UTC, Jesse Phillips wrote:
>>> FYI an infinite range is defined to have
>>>
>>>   struct Infinite {
>>>       enum empty = false;
>>>   }
>>>
>>> You know it will never be empty at compile time.
>>
>> Hiho,
>>
>> thank you for this interesting input. =)
>>
>> Couldn't this be equally possible (also at runtime) with the following:
>>
>> struct Infinite {
>>    enum empty_ = false;
>>    bool empty() pure { return empty_; }
>> }
>
> Yes, but only at runtime. For some things to work, you need to be able to know it at compile time. `std.range` defines a template `isInfinite` that checks for this.
>
> This information can be used for some optimizations: `std.algorithm.count` and `std.range.walkLength` are only defined for non-infinite ranges (to avoid creating an infinite loop), `std.algorithm.cartesianProduct` can work with two infinite ranges using a special enumeration strategy if it can detect them, `std.range.chain` can optimize index access by stopping at the first infinite range, `std.range.take` can always define a length for infinite ranges (even if they don't have a length property themselves), ...
>
> Another example: The `length` property of ranges. It is possible to turn builtin slices (dynamic arrays) into ranges by importing `std.range` or `std.array`. Slices already have a member field `length` by default. Here you have an example where it's impossible to define a method `length()`. With properties, nothing special needs to be done: You can always use `length` without parens, even if it happens to be a method.

Uhm, ... I thought that enum types for variables are determined
at compiletime and as pure functions aren't affected by
side-effects and cause no side-effects their result should be
determinable at compiletime, too.

Couldn't it be possible again if we just add another getter
method "length()" for the slice's length? Then you would have a
uniform access as length() instead of length (without parens) if
you do it analogiously for all other cases. There is just no
difference in my opinion - the one solution forces an interface
with parens and the other forces an interface without them.

Robin

Does @property force you to call the function without parens? If not I don't really see what the keyword actually does.

On Sunday, 16 February 2014 at 01:21:21 UTC, Casper Færgemand wrote:
> Does @property force you to call the function without parens? If not I don't really see what the keyword actually does.

@property does not force you to use parentheses.

@property myExample(int a) {}

It can be called via
myExample = a;
or
myExample(3);

I can't entirely remember the behaviour for no args on the first syntax.

On 2/14/2014 4:32 AM, Robin wrote:
>
> Why are there Properties in D?

http://www.youtube.com/watch?v=z6dmnE2mUgE

On Saturday, 15 February 2014 at 15:45:40 UTC, Robin wrote:
> On Friday, 14 February 2014 at 19:24:58 UTC, Marc Schütz wrote:
>> Another example: The `length` property of ranges. It is possible to turn builtin slices (dynamic arrays) into ranges by importing `std.range` or `std.array`. Slices already have a member field `length` by default. Here you have an example where it's impossible to define a method `length()`. With properties, nothing special needs to be done: You can always use `length` without parens, even if it happens to be a method.
>
> Uhm, ... I thought that enum types for variables are determined
> at compiletime and as pure functions aren't affected by
> side-effects and cause no side-effects their result should be
> determinable at compiletime, too.
>
> Couldn't it be possible again if we just add another getter
> method "length()" for the slice's length? Then you would have a
> uniform access as length() instead of length (without parens) if
> you do it analogiously for all other cases. There is just no
> difference in my opinion - the one solution forces an interface
> with parens and the other forces an interface without them.

You can't define a method and a member variable with the same name.

On 02/16/2014 02:21 AM, "Casper Færgemand" <shorttail@gmail.com>" wrote:
> Does @property force you to call the function without parens?

It is supposed to, but no.

> If not I don't really see what the keyword actually does.

There's a variety of ideas what it should do:

http://wiki.dlang.org/DIP21
http://wiki.dlang.org/DIP23
http://wiki.dlang.org/DIP24

(DIP21 is basically a subset of 'DIP24/@property: basic design'.)

Robin wrote:

> Hiho,
> 
> I am learning D since some time and I must say all in all it is truely a better C++! I especially like the statement of Walter Bright that nowadays it is more important that the programmer can easily read programming text and do not have to "interpret" every single line by looking into several definitions and declarations in order to fully understand what a piece of program text really means as programmers normally spend much more time debugging a code than writing one and thus it isn't that important to keep program code short - more important is clean and unambiguous code.
> 
> But what about Properties - the feature where functions can be
> called as if they were member variables ...
> Isn't this a step backwards if you think about the sentence above?
> 
> With Properties used in a code a programmer again has to look up the definition of all calls and assignments of variables just in case they could be Properties and not just member variables.
> 
> So I am asking why should one use Properties? The only advantage is that one can leave out the nasty "()" but the disadvantage is that especially new people who are working out a code of another person or people who have to inspect older code may have a harder time understanding what really happens especially if Properties are "overused".
> 
> In my opinion this leads to less clear code.
> 
> But maybe I am overlooking something and things aren't that worse so it would be nice if someone could tell me about other advantages of Properties. =)
> 
> Robbepop

I understand your frustration. It gets even worse when properties are mixed
with UFCS. People who are new to D just get more confused. :)
I do not know, I find it very hard to read, personally, so I do not abuse
them like some other people do. I like my code to be understood by anyone in
the first "code scan".

-- 
http://dejan.lekic.org