Does D have too many features?

Jonathan M Davis jmdavisProg at gmx.com
Sun Apr 29 19:41:50 PDT 2012


On Sunday, April 29, 2012 19:37:50 H. S. Teoh wrote:
> On Sun, Apr 29, 2012 at 08:42:23PM +0200, Andrej Mitrovic wrote:
> > On 4/29/12, Jacob Carlborg <doob at me.com> wrote:
> > > In principle I agree with you. But in practice this doesn't always
> > > work.  Take this for example: Prints "0" and "1" as expected. If we
> > > now change "point" to a property like this: It will now print "0"
> > > and "0". This is a silently breaking change. Sure you can change
> > > "point" to return by reference..
> > 
> > This is a great point and an issue I've ran into and talked about
> > before. The compiler really ought to try and convert a call like this:
> > 
> > foo.property++;
> > foo.property+=10;
> > 
> > into e.g.:
> > foo.property = foo.property.opAdd(1);
> > foo.property = foo.property.opAdd(10);
> > 
> > It would make for some really nice APIs if this feature was available.
> 
> [...]
> 
> To me, the compiler needs to be fixed so that anytime the return value
> of a @property is used as an lvalue, it should always try to call the
> setter function, or some kind of setter function, instead of the getter
> (unless there's no setter, in which case it's OK to call the getter).
> 
> I chalk this up to a compiler issue, not a language issue.

Well, it's both really. If the language spec was exact enough, it would say 
_exactly_ what the correct behavior is here, in which case, either the 
compiler is currently doing the right thing or it's not, depending on the 
spec. But the spec isn't that exact, so in some respects, the compiler _is_ 
the spec. Certainly, the way that this behaves in the language right now is a 
matter of how the compiler behaves.

Ideally though, there would be zero difference between using a property and a 
public member variable save for taking its address (which should probably just 
be illegal for @property functions). I've been tempted to add an enhancement 
request for putting @property on public member variables to make it so that 
anything which would would break code if it were switched to a property 
function wouldn't be legal (such as taking its address). Unfortunately, right 
now that would include stuff like ++.

- Jonathan M Davis


More information about the Digitalmars-d mailing list