@property - take it behind the woodshed and shoot it?

[Jonathan M Davis]

On Friday, January 25, 2013 12:24:56 monarch_dodra wrote:
> On Friday, 25 January 2013 at 11:01:31 UTC, mist wrote:
> > On Friday, 25 January 2013 at 10:26:14 UTC, Robert burner
> > 
> > Schadek wrote:
> >> ...
> >> Yes, the syntax is legit. It's the semantic that "scares" me.
> >> IMHO it feels strange that assigning a variable resizes a
> >> array. Something like a.resize(10) would make me feel better.
> > 
> > Ye, it was one of the first "Erm wtf?" moments when I started
> > to learn D. And living confirmation that core developers don't
> > really have a strong vision what properties should be.
> 
> I can view *reading* size as a property, but I don't think the
> setter itself should be a property, since it actually *does*
> something. Heck, it can throw an exception (!)

So? Of course, setters can throw exceptions. Why wouldn't they be able to? For 
instance, if you try and set the hour on a TimeOfDay to 25, it's going to 
throw a DateTimeException. I could see an argument that the operations that 
length does when set are expensive enough that it shouldn't be a setter 
property, but setters are not necessarily going to be as simple as setting a 
variable, and throwing exceptions from them is normal, depending on what they 
need to do. I could see generally restricting them to operations which are 
O(1) or O(log n) rather than O(n) or worse (and I think that C#'s guidelines 
on properties say something along those lines), but you make it sound as if 
all a setter property should ever do is simply set a variable, and if that 
were the case, you might as well just make it a public variable.

> However, I really think we are way past the point we can change
> array's interface. I'd just leave it be.

It's far too late at this point. I don't know if it was a good design choice 
or not (and I rarely use it myself), but it's not going to change.

- Jonathan M Davis