I'm back

H. S. Teoh hsteoh at quickfur.ath.cx
Thu Nov 15 10:49:08 PST 2012


On Thu, Nov 15, 2012 at 04:38:04AM -0800, Jonathan M Davis wrote:
> On Thursday, November 15, 2012 13:17:12 jerro wrote:
> > > std.array.array will never work with ranges with a transient front
> > > unless it somehow knew when it was and wasn't appropriate to dup,
> > > which it's not going to know purely by looking at the type of
> > > front. The creator of the range would have to tell them somehow.
> > > And even then, it wouldn't work beyond the built-in types, because
> > > there's no generic way to dup stuff.
> > 
> > Daniel was actually talking about std.byLine.map!"a.dup", which is
> > not a transient range, but would be considered transient if we did
> > what Andrei suggests.
> 
> Well, there's no way around that as far as I can see. Even if all
> ranges had to be explicitly marked as transient or not, map would be
> in a bind here, because it knows nothing about what the function it
> was given is doing, so it has no way of knowing how it affects
> transience. At minimum, it would be forced to mark itself as transient
> if the original range was (even if the function used idup), or it
> would _always_ be forced to mark it as transient (I'm not sure which).
> The only way out would be if there were a way to tell map explicitly
> to mark the resultant range as having a non-transient front.

OK, you've convinced me. The only way to take care of all these corner
cases is to make transient ranges illegal, period. Just the fact that
map!a and map!"a.dup" may be transient or not, shows that this isn't
going to be solved by any simple means. None of our proposals so far
even comes close to handling this one correctly.


> By using type deduction like Andrei is suggesting, then we can at
> least deduce that map!"a.idup" has a non-transient front,

Well, this at least gives us some semblance of workability for this
particular case, though it is very leaky around the edges.


> but the only way that we'd know that map!"a.dup" was non-transient was
> if map were told somehow, and it defined an enum that the
> hasTransientFront trait could examine (i.e. we're back in the boat
> we'd be in if all ranges had to declare whether they were transient or
> not). So, as long as we can have transient fronts, map!"a.dup" is
> screwed, which may or may not be a problem.

This is not good, because it relies on the user to declare whether or
not something is transient when they aren't even the implementor of the
delegate passed to map. It's one thing to require users to declare their
ranges transient or not, but it's quite another thing to require them to
tell map whether or not a.dup is transient (where a.dup can be
substituted with an arbitrarily complex delegate which may not even be
implemented by the user).


[...]
> It's looking like this comes down to either banning ranges with
> transient fronts entirely (and changing how ByLine and ByChunk work),

This is looking like the more attractive option right now.


> or we're going to have to deal with quirks like
> array(map!"a.dup"(file.byLine())) not working whereas
> array(map!"a.idup"(file.byLine())) does work.
[...]

This is ugly. I don't like it. But at least, it does give you a compile
time error when array requires a non-transient range, but gets a
transient one. Better than subtle runtime breakage, for sure.


T

-- 
It said to install Windows 2000 or better, so I installed Linux instead.


More information about the Digitalmars-d mailing list