On Friday, 26 September 2014 at 22:58:53 UTC, Cliff wrote:
This is a clever syntax, but I can't say I particularly care
for it since it aliases two names for the same location which
differ only in their visibility, and this feels... wrong to me
somehow.
In C# this is a sufficiently common practice that the property
syntax allows for it directly:
class Foo
{
int A { get; private set; }
}
The compiler automatically creates a (hidden) backing property
(this is an implementation detail of course), both internal and
external customers use the same name, and there is no
redundancy.
If I were to compare the D way and the C# way, I would prefer
to C# way for this trivial-property case. What I would NOT
want is C#'s special handling of properties to go along with it
- a D analog would preserve A's access methods and handling as
if it were a field if that was the user's wish.
That's my $0.02.
C#'s way of declaring properties is something I've been missing
in D for a long time. Using a mixin is just plain ugly and breaks
tooling, yet this is such a common thing to have to do. It is
quite disappointing that there's no shorthand for it, like
'@property int a;' or '@property(readonly) int b'.
(On that matter, I'm not a fan in general of properties being
various methods glued together by an @property, but that's set in
stone by now.)
