On Monday, 19 November 2012 at 08:45:03 UTC, thedeemon wrote:
On Monday, 19 November 2012 at 08:23:43 UTC, Jonathan M Davis
wrote:
On Monday, November 19, 2012 09:16:29 Rob T wrote:
My guess is that if @property gets enforced, we'll see a lot
of
functions with empty parameter lists being defined as
@property
for the sole reason to get rid of having to type in the ().
Which completely violates the concept of a property in the
first place. It's
intended to be an abstraction for a variable. Using @property
just to get rid
of parens would be like naming types with verbs instead of
nouns. It's
completely backwards.
- Jonathan M Davis
I very much like the combination of UFCS, ranges and
parens-free style which allows writing code like
iota(0,
1000000).map!(to!string).retro.take(50).retro[10].writeln;
So I like Andrei's idea to force @property only for those
functions where it's absolutely necessary to fight ambiguity.
I kind of agree with Jonathan here. @property really shines when
you want to "add" an attribute to a struct. array "front", for
example, is a perfect example of this. RefCounted's "payload"
(IMO), is also a good example.
*Functions* that do actual operations, in particular, "retro",
IMO, should not be properties.
"byLines", for example, is a member function, and not property.
How is:
r.retro;
any better than
r.byLines()
?
At best, it makes it look like r has a built-in retro attribute,
which is miss-leading.
--------
I'll admit I thought too it would be "convenient" to write
".retro" without the parens, but let's face it, that'd be
incorrect usage...
