Thread overview | ||||||
---|---|---|---|---|---|---|
|
August 16, 2010 [phobos] phobos commit, revision 1884 | ||||
---|---|---|---|---|
| ||||
phobos commit, revision 1884 user: dsimcha msg: Bug 4408: Ambiguity when using std.algorithm.splitter with generic ranges http://www.dsource.org/projects/phobos/changeset/1884 |
August 16, 2010 [phobos] phobos commit, revision 1884 | ||||
---|---|---|---|---|
| ||||
Posted in reply to dsource.org | An HTML attachment was scrubbed... URL: <http://lists.puremagic.com/pipermail/phobos/attachments/20100816/e256a9b5/attachment.html> |
August 16, 2010 [phobos] phobos commit, revision 1884 | ||||
---|---|---|---|---|
| ||||
Posted in reply to David Simcha | On 8/16/2010 8:16 PM, David Simcha wrote:
> 3. Stuff related to static arrays.
>
> How do we want to handle the static array case, long term? IMHO stuff in
> std.range and std.algorithm should generally* not *support static arrays because
> in addition to being a PITA to
> implement, since static arrays are usually stack allocated,
> using them as ranges is inherently unsafe.
In your code they might tend to be stack based, but static arrays inside classes is a perfectly valid and frequent enough use case (extrapolating from non-d usage on my part since I've done rather little d coding to date) that I wouldn't rule them out.
I do agree that for the stack case, there's risk of misuse. For the safe-d subset of the language, that's a problem, but phobos isn't restricted to the subset and so shouldn't go out of its way to make life hard for doing work outside that subset.
That said, I don't think it's a big burden to push the problem to the developer to just take a slice over the static array when passing it to a std.algorithm.
My 2 cents,
Brad
|
August 17, 2010 [phobos] phobos commit, revision 1884 | ||||
---|---|---|---|---|
| ||||
Posted in reply to David Simcha | On 08/16/2010 10:16 PM, David Simcha wrote: > I think that covers all the known bugs in std.range and std.algorithm, with the following exceptions: > > 1. Enhancement requests, as opposed to "real" bugs. > > 2. Pure documentation issues. > > 3. Stuff related to static arrays. > > 4. Bug 3067, which is really a compiler bug. This is great work! > How do we want to handle the static array case, long term? IMHO stuff in std.range and std.algorithm should generally* not *support static arrays because in addition to being a PITA to implement, since static arrays are usually stack allocated, using them as ranges is inherently unsafe. I agree. Just have people use arr[] instead of arr and call it a day. BTW generally passing arr[] to a function where arr is a static array allocated on the stack is an unsafe operation. Andrei |
Copyright © 1999-2021 by the D Language Foundation