On Sunday, May 29, 2016 18:27:53 default0 via Digitalmars-d wrote: > On Sunday, 29 May 2016 at 18:09:29 UTC, Steven Schveighoffer > > wrote: > > On 5/29/16 1:45 PM, Steven Schveighoffer wrote: > >> On 5/27/16 7:42 PM, Seb wrote: > >>> So what about the convention to explicitely declare a > >>> `.transient` enum > >>> member on a range, if the front element value can change? > >> > >> enum isTransient(R) = is(typeof(() { > >> > >> static assert(isInputRange!R); > >> static assert(hasIndirections(ElementType!R)); > >> static assert(!allIndrectionsImmutable!(ElementType!R)); // > >> > >> need to > >> write this > >> })); > > > > obviously, this is better as a simple && statement between the > > three requirements :) When I started writing, I thought I'd > > have to write some runtime code. > > > > -Steve > > Would that make a range of polymorphic objects transient?
It would make pretty much anything that isn't a value type - including a type that's actually a value but uses postblit to do it - be treated as transient, with the one exception being that if the reference types involved are immutable (be they the element type or members in the elmenet type), then it's not treated as transient. This means a very large number of ranges will be treated as being transient, which is completely unacceptable IMHO. Having a transient front is _not_ the norm, and code is usually written with the assumption that front is not transient. In almost all cases, if a range-based function happens to work with a transient front, it's by luck and not because it was designed that way. You can't statically check for transience, because it depends on runtime behavior. At best, you can statically eliminate a fairly small portion of the ranges as not being having transient fronts. If we want to actually support transient fronts, it really needs to be explicit IMHO. Regardless, I don't think that we want to need to be checking for transience in range-based functions in general. It's too much extra complication for too little benefit. A very small number of ranges actually have or benefit from having a transient front, and I don't think that it's worth supporting them as ranges given how much that affects everything else. Otherwise, you end up with the 1% case causing problems for all range-based code. - Jonathan M Davis