On Thu, May 19, 2016 at 09:21:40AM -0400, Steven Schveighoffer via Digitalmars-d-announce wrote: > On 5/17/16 8:36 PM, H. S. Teoh via Digitalmars-d-announce wrote: > > On Tue, May 17, 2016 at 08:19:48PM +0000, Vladimir Panteleev via > > Digitalmars-d-announce wrote: > > > On Tuesday, 17 May 2016 at 17:26:59 UTC, Steven Schveighoffer wrote: > > > > However, it's perfectly legal for a front function not to be > > > > tagged @property. > > > > > > BTW, where is this coming from? Is it simply an emergent property > > > of the existing implementations of isInputRange and ElementType, > > > or is it actually by design? > > > > This is very bad. The range API does not mandate that .front must be > > a function. I often write ranges where .front is an actual struct > > variable that gets updated by .popFront. Now you're saying that my > > range won't work with some code, because they call .front() (which > > is a compile error when .front is a variable, not a function)? > > My goodness no! > > People, please, my point is simply that is(typeof(someRange.front) == > ElementType!(typeof(someRange))) DOESN'T ALWAYS WORK.
OK, so the point is, use ElementType!(typeof(range)) instead of typeof(range.front)? That works for me. Sorry for the noise. :-P [...] > > In the old days (i.e., 1-2 years ago), isForwardRange!R will return > > false if .save is not marked @property. I thought isInputRange!R did > > the same for .front, or am I imagining things? Did somebody change > > this recently? > > You are imagining that someInputRange.front ever required that. In > fact, it would have had to go out of its way to do so (because > isInputRange puts no requirements on the *type* of front, except that > it returns a non-void value). > > But you are right that save did require @property at one time. Not (In > my opinion) because it meant to, but because it happened to check the > type of r.save against a type (namely, that .save returns its own > type). Ah, so that's where it came from. Now I remember that there were bugs caused by .save returning something other than the original range type, which broke certain algorithms. That's probably where the whole .save requiring @property thing came from. > At the same time, I fixed all the isXXXRange traits so @property is > not required anywhere. In particular, isRandomAccessRange required > r.front to be @property, even when isInputRange didn't (again, IMO > unintentionally). Here is the PR: > https://github.com/dlang/phobos/pull/3276 [...] Thanks for the info! T -- "Maybe" is a strange word. When mom or dad says it it means "yes", but when my big brothers say it it means "no"! -- PJ jr.
