http://d.puremagic.com/issues/show_bug.cgi?id=8084
Jonathan M Davis <jmdavisp...@gmx.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |jmdavisp...@gmx.com --- Comment #5 from Jonathan M Davis <jmdavisp...@gmx.com> 2012-05-12 11:38:24 PDT --- > OK. ByLine.front returns the slice of internal line buffer, so it specifies 'temporary' data. So? It's returning a reference type, so it could change on you. It _is_ potentially problematic in some cases, but I don't see how that makes it so that it isn't an input range > We should get dup in each iteration. It's specifically _avoiding_ that for efficiency purposes. Now, maybe having ByLine's front return the same array with changes values rather than a new array makes it so that it doesn't work with a lot of range-based functions, effectively making it useless as a range, even if it _does_ follow the API. If that's the case, maybe we should make it use opApply for the loop case (having it use the current non-duping behavior) and have front do a dup (and if front as pure, that result could even be implicitly converted to an immutable result, avoiding having to dup it twice to get an immutable copy). -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------