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
