On Thursday, May 19, 2016 13:11:47 jmh530 via Digitalmars-d-announce wrote: > On Thursday, 19 May 2016 at 12:10:36 UTC, Jonathan M Davis wrote: > > [snip] > > Very informative, as always. > > I had not realized the implication of front being called without > parens, such as front being something that isn't an @property > function (esp. variable). Are there any ranges in phobos (you can > think of) that do this?
I'm not aware of any, but there might be some. I think that most of use pretty much always use @property functions, though the usual reasons for that don't really apply to Voldemort types. The usual reason to use an @property function instead of a public variable is that while property functions emulate variables, they really aren't the same (e.g. taking its address doesn't have the same semantics, and stuff like incrementing doesn't normally work with property functions). So, unfortunately, you can't transparently swap between @property functions and variables, even though that's theoretically one of the reasons that property functions exist in a language. But when using a range that's a Voldemort type, you don't even ever see the type's declaration, and you're only ever supposed to use the range API on it, so the semantics of variable vs function don't really matter, since you're not supposed to be doing any of the stuff where it would matter (e.g. it makes no sense to take the address of front, because what that means is not specified by the range API and will do different things with different range implementations). So, it's arguably better to just use public variables with ranges if functions like front or empty are just going to return a value, but many of use just use @property functions out of habit given that in the general case, it's problematic to use public variables instead of @property functions (though it _would_ be a nice language enhancement IMHO if using @property on a variable made it illegal to do anything on it that you couldn't do on an @property function, since then you could make it a public variable until refactoring required that it become a function, and changing it wouldn't break code, whereas now, it might). - Jonathan M Davis
