[Issue 12736] @nogc std.algorithm.all

2022-12-17 Thread d-bugmail--- via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=12736

Iain Buclaw  changed:

   What|Removed |Added

   Priority|P1  |P4

--


[Issue 12736] @nogc std.algorithm.all

2019-12-25 Thread d-bugmail--- via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=12736

berni44  changed:

   What|Removed |Added

 CC||bugzi...@d-ecke.de
 OS|Windows |All

--


[Issue 12736] @nogc std.algorithm.all

2018-02-09 Thread d-bugmail--- via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=12736

Seb  changed:

   What|Removed |Added

 CC||greensunn...@gmail.com

--- Comment #4 from Seb  ---
the problem here is auto-decoding and that it can throw an exception,
The following works as expected:

---
void main() @nogc {
import std.ascii: isDigit;
import std.algorithm: all;
import std.utf : byCodeUnit;
auto b = "12".byCodeUnit.all!isDigit;
}
---

It has long being proposed to disable auto-decoding by introducing an RCString.
I'm not sure whether this should be kept open, because the issue is not on
`all`'s side - all it does is calling `popFront` of string - which happens to
be @nogc (due to throwing UTF Exceptions).

--


[Issue 12736] @nogc std.algorithm.all

2017-07-13 Thread via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=12736

Jon Degenhardt  changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|INVALID |---

--- Comment #3 from Jon Degenhardt  ---
Valid enhancement request, so reopening. If closed, should have a justification
indicating the mechanism expected to eventually achieve the enhancement, or an
explanation of why it the request is invalid at the API level.

--


[Issue 12736] @nogc std.algorithm.all

2017-07-12 Thread via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=12736

Jon Degenhardt  changed:

   What|Removed |Added

 CC||jrdemail2000-dl...@yahoo.co
   ||m

--- Comment #2 from Jon Degenhardt  ---
Seems a legitimate enhancement request, and in line with the longer term goal
of having Phobos be @nogc when possible. In this particular case, there doesn't
appear to be any reason why the functionality implemented by std.algorithm.all
cannot be @nogc. And, std.algorithm.find could be @nogc as well in this case.

Personally though, I would hesitate to write an enhancement request against
each individual function in Phobos for every attribute, and instead have a
larger placeholder ticket for larger blocks of Phobos, for example, a ticket
for all of std.algorithm. The above is a policy question of course, but if done
this way then this ticket could be closed as a duplicate of the larger ticket,
rather than closing it as invalid.

As aside: std.algorithm.find is @nogc for certain argument types. Example:

@nogc @safe nothrow pure unittest
{
import std.algorithm : find;
import std.range : iota;

assert(find(iota(1,5), 3) == iota(3,5));
}

--


[Issue 12736] @nogc std.algorithm.all

2017-07-12 Thread via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=12736

RazvanN  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||razvan.nitu1...@gmail.com
 Resolution|--- |INVALID

--- Comment #1 from RazvanN  ---
Why is this an issue? all calls find which is non-nogc. Closing as invalid

--


[Issue 12736] @nogc std.algorithm.all

2014-12-06 Thread via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=12736

sinkuup...@gmail.com changed:

   What|Removed |Added

 CC||sinkuup...@gmail.com
   See Also||https://issues.dlang.org/sh
   ||ow_bug.cgi?id=13458

--