On Saturday, 18 January 2014 at 23:06:42 UTC, Tobias Pankrath wrote:
I actually didn't think that a ptr (to output range) would work. This way we can have best of both worlds and I'm happy with it.

A fun fact is that since "." notation works with pointers, more often than not, if "T" verifies some trait "isOutputRange", more often than not, so will "T*".

But this is more of a by-product than an actual rule, and, as a rule of thumb, may not be something you want to rely on in a general sense. Limitations include:

Type checking: If "R" is a random access range, "R*" will only be an input range, because "p.save" will return an "R", and not an "R*" :/

Also, it is limited to member functions, and not generic UFCS: For example, while in the general sense, "R is input range" => "R* is input range", this will fail for "T[]*", because slices have a non-member popFront, so "p.popFront()" will not actually match a function, and "T[]*" will fail the input range validation :/

So, my conclusion, "*" might be a workable solution. But simply taking by ref would be cleaner, and make more sense as a whole.

Reply via email to