On Sun, Nov 04, 2012 at 07:47:49PM -0800, Jonathan M Davis wrote: > On Sunday, November 04, 2012 19:41:39 H. S. Teoh wrote: [...] > > The crux of what deadalnix proposed is that range transformers > > simply pass .transient along, whilst range consumers decide whether > > or not to use .transient. So this isn't even an issue until you are > > in a range consumer, which can decide whether or not the transient > > range should be used. > > > > IOW, the choice between .transient or not isn't even made until the > > end. The range consumer is the one in the position to decide > > whether or not .transient should be used. > > And how on earth would it decide that when it's been wrapped by > who-knows how many wrapper ranges? It would be far too late at that > point.
I think you're missing the point here. The range consumer simply calls .transient on the range that gets passed in. If the range doesn't define .transient, then it falls back via UFCS to the default .transient, which just returns the range itself. Only if the range defines .transient, will an actual transient range get returned. > Unless you expect that every one of those ranges is going to duplicate > itself such that when you call fastRange or transient or whatever you > can get a different range type which is transient? If a range does not support transience, then it needs not do anything more. UFCS kicks in, and the range itself gets returned. Only when the range can support transience, will it return a transient version of itself. All ranges will be non-transient by default. > That's worse than inTransient IMHO. The only advantage that it has is > that if you fail to take it into account, you end up with the > non-transient range, and your code doesn't end up doing crazy stuff. > But in either case, all of the range types have to take it into > account, complicating their implementations that much further, and > fastRange would complicate those implementations far more than > isTransient would, because it would require code duplication rather > than just statically disallowing the transient range when it wouldn't > work. [...] No, all existing ranges will work as-is (except for the currently transient ranges, which will be modified to become non-transient). They will not define .transient, UFCS kicks in, and any range consumer that calls .transient on them simply gets the original range back. Only when the range supports .transient, *and* the range consumer asks for it, will the transient range be used. IOW, only those algorithms that are specifically transience-capable need to be updated to call .transient (and even if they aren't updated, they will still work, just slower). Only the ranges that can be made transient need to implement .transient. Nothing else needs to be touched. Most user code won't even *see* transient ranges, so they will be safe by default. (The only time user code needs to worry about .transient is when they want to write a range consumer that wants to take advantage of the speed up. In all other cases, transient ranges aren't even used, so the code is safe by default.) T -- Just because you survived after you did it, doesn't mean it wasn't stupid!
