On Saturday, 17 November 2018 at 13:13:36 UTC, aliak wrote:
On Friday, 16 November 2018 at 13:21:39 UTC, Stanislav Blinov
wrote:
auto assumeNoGC(T)(return scope T t) @trusted { /* ... */ }
Sawweet! Thanks, that made the printing possible!
"scope" is const from what I understand right? It
On Saturday, 17 November 2018 at 13:13:36 UTC, aliak wrote:
Sawweet! Thanks, that made the printing possible!
You're welcome ;) Still, try a more recent compiler. This works
fine:
void foo() @nogc {
debug {
import std.stdio;
writefln("%d", 42);
}
}
"
On Friday, 16 November 2018 at 13:03:40 UTC, Zoadian wrote:
debug {
import std.stdio;
writeln(args);
}
As mentioned in the original post, that does not work.
On Friday, 16 November 2018 at 13:21:39 UTC, Stanislav Blinov
wrote:
At 'point 1', you just take by value. If `t` ends up being a
closure, D will allocate. That's where it breaks the @nogc.
Solution:
auto assumeNoGC(T)(return scope T t) { /* ... */ }
Now you take (and return) a `scope` t
On Friday, 16 November 2018 at 12:12:12 UTC, Alex wrote:
=
This code compiles as long as `lazy` is commented out. But I'd
like to have
both lazy parameter and @nogc inferrence for `library_func` so
that user is not locked to code @nogc
On Friday, 16 November 2018 at 12:59:22 UTC, aliak wrote:
Adding @trusted to declaration of opDispatch gets rid of @safe
error but I still get "Error: @nogc function D main cannot call
non-@nogc function". And going through the codebase and
figuring out where to add @truste
debug {
import std.stdio;
writeln(args);
}
Hi, I previously had trouble trying to get print statements
working while debugging in nogc. And that was hackishly solved
[0], but I can't figure out how to do the same if I have @safe
involved. Here's a cut down sample:
// This is the function from the thread referenced
auto assumeNoGC(T)(T
On Friday, 16 November 2018 at 10:25:26 UTC, ikod wrote:
On Thursday, 15 November 2018 at 21:55:18 UTC, Steven
Schveighoffer wrote:
On 11/15/18 4:09 PM, Adam D. Ruppe wrote:
On Thursday, 15 November 2018 at 21:00:48 UTC, ikod wrote:
what are the rules for @nogc inference?
It attempts
On Thursday, 15 November 2018 at 21:55:18 UTC, Steven
Schveighoffer wrote:
On 11/15/18 4:09 PM, Adam D. Ruppe wrote:
On Thursday, 15 November 2018 at 21:00:48 UTC, ikod wrote:
what are the rules for @nogc inference?
It attempts it if and only if it is a template.
Well, the general "
in stripRight & make nogc
nothrow for strings
https://github.com/dlang/phobos/commit/e6719075de7ba3ac9aa141325882bc98f30e1eaa
Merge pull request #6771 from n8sh/issue-19405
Fix Issue 19405 - Speed up backwards UTF-8 decoding in stripRight & make nogc
nothrow for strings
--
https://issues.dlang.org/show_bug.cgi?id=19405
github-bugzi...@puremagic.com changed:
What|Removed |Added
Status|NEW |RESOLVED
https://issues.dlang.org/show_bug.cgi?id=19405
--- Comment #1 from Nathan S. ---
Pull request: https://github.com/dlang/phobos/pull/6771
--
|decoding in stripRight &|decoding in stripRight &
|make nogc nothrow for |make nogc nothrow for
|strings |strings
--
|decoding in stripRight |decoding in stripRight &
||make nogc nothrow for
||strings
--
On 11/15/18 4:09 PM, Adam D. Ruppe wrote:
On Thursday, 15 November 2018 at 21:00:48 UTC, ikod wrote:
what are the rules for @nogc inference?
It attempts it if and only if it is a template.
Well, the general "rule" is, if it's code that must be available to the
compiler when i
On Thursday, 15 November 2018 at 21:00:48 UTC, ikod wrote:
what are the rules for @nogc inference?
It attempts it if and only if it is a template.
https://issues.dlang.org/show_bug.cgi?id=19403
--- Comment #1 from Nathan S. ---
Pull request: https://github.com/dlang/phobos/pull/6769
--
|char array could be @nogc |on char array @nogc nothrow
|nothrow |
--
https://issues.dlang.org/show_bug.cgi?id=19403
Issue ID: 19403
Summary: std.string.stripLeft on char array could be @nogc
nothrow
Product: D
Version: D2
Hardware: All
OS: All
Status: NEW
On Friday, 2 November 2018 at 07:00:49 UTC, Manu wrote:
On Tue, Oct 30, 2018 at 9:30 AM Oleg via Digitalmars-d-announce
wrote:
Thanks for your work!
> Example
> ===
> ///
> @safe pure nothrow @nogc
> unittest
> {
> import mir.exception;
&g
On Tue, Oct 30, 2018 at 9:30 AM Oleg via Digitalmars-d-announce
wrote:
>
> Thanks for your work!
>
> > Example
> > ===
> > ///
> > @safe pure nothrow @nogc
> > unittest
> > {
> > import mir.exception;
> > import
On Friday, 2 November 2018 at 05:21:07 UTC, 9il wrote:
On Thursday, 1 November 2018 at 10:17:25 UTC, bauss wrote:
[...]
Well, added at v0.0.8 [1].
Mir Runtime formatting and exceptions are CTFE-able if a msg
fits into a local buffer and support user-defined types
formatting. Note, that
On Thursday, 1 November 2018 at 10:17:25 UTC, bauss wrote:
On Wednesday, 31 October 2018 at 13:56:56 UTC, 9il wrote:
~ is used for string concatenation in D including string
compile time constant concatenation. It is better not to
override it because both << and ~ can be used in the same
append("Hi D", 2, "!",
getData);
Would have been a much better approach similar to how
write/writeln etc. work from std.stdio.
https://github.com/atilaneves/nogc/blob/ed4663558ceea1f5dc2634d6f01cc6ce6967adc1/tests/ut/exception.d#L49
On Wednesday, 31 October 2018 at 13:56:56 UTC, 9il wrote:
~ is used for string concatenation in D including string
compile time constant concatenation. It is better not to
override it because both << and ~ can be used in the same
expression.
I see what your argument is now for it, BUT I
On Wednesday, 24 October 2018 at 10:57:27 UTC, 9il wrote:
Release v0.0.5 comes with
- mir.exception - @nogc MirException
- mir.format - @nogc formatting
Fantastic!
On Wednesday, 31 October 2018 at 09:13:14 UTC, Uknown wrote:
On Wednesday, 31 October 2018 at 08:34:08 UTC, 9il wrote:
The C++ format style is simpler to implement and it is much
faster to run.
D's style came from C and Boost's format. Also, the C++ style
is more low level then format strings,
On Wednesday, 31 October 2018 at 09:13:14 UTC, Uknown wrote:
On Wednesday, 31 October 2018 at 08:34:08 UTC, 9il wrote:
The C++ format style is simpler to implement and it is much
faster to run.
D's style came from C and Boost's format. Also, the C++ style
is more low level then format strings,
On Wednesday, 31 October 2018 at 08:34:08 UTC, 9il wrote:
The C++ format style is simpler to implement and it is much
faster to run.
D's style came from C and Boost's format. Also, the C++ style
is more low level then format strings, so they can be built on
top of it.
I think they meant why
On Tuesday, 30 October 2018 at 16:25:12 UTC, Oleg wrote:
Thanks for your work!
Example
===
///
@safe pure nothrow @nogc
unittest
{
import mir.exception;
import mir.format;
try throw new MirException(stringBuf() << "Hi D" << 2 <<
Thanks for your work!
Example
===
///
@safe pure nothrow @nogc
unittest
{
import mir.exception;
import mir.format;
try throw new MirException(stringBuf() << "Hi D" << 2 <<
"!" << getData);
https://issues.dlang.org/show_bug.cgi?id=15598
Stanislav Blinov changed:
What|Removed |Added
Status|NEW |RESOLVED
CC|
DIP 1000 says:
Delegates currently defensively allocate closures with the GC.
Few actually escape, and with scope only those that actually
escape need to have the closures allocated.
https://github.com/dlang/DIPs/blob/master/DIPs/DIP1000.md#benefits
then scope "exits" trough
scope(failure) in which case no deallocation should be performed
and only if scope "exits" trough scope(success), meaning
exception/s were handled, destructors need to be called.
To make exceptions nogc we need destructors that are aware of how
s
On Saturday, 20 October 2018 at 14:56:37 UTC, Mike Parker wrote:
On Saturday, 20 October 2018 at 13:48:32 UTC, Paolo Invernizzi
wrote:
If `@nogc` could be relaxed for `new Error` exactly for that
reason, pieces of Phobos could be turned `@nogc`...
But I admit that that change would
On Saturday, 20 October 2018 at 13:48:32 UTC, Paolo Invernizzi
wrote:
If `@nogc` could be relaxed for `new Error` exactly for that
reason, pieces of Phobos could be turned `@nogc`...
But I admit that that change would be controversial...
https://github.com/dlang/DIPs/blob/master/DIPs
and throw the error you want ;)
In my case, that's what I did anyway.
I don't know how a performance problem can occur on an error
being thrown anyway -- the process is about to end.
-Steve
If `@nogc` could be relaxed for `new Error` exactly for that
reason, pieces of Phobos could be turned
On Friday, 19 October 2018 at 23:46:29 UTC, Nicholas Wilson wrote:
On Friday, 19 October 2018 at 23:34:01 UTC, Atila Neves wrote:
On Thursday, 20 September 2018 at 12:48:13 UTC, Steven
Schveighoffer wrote:
How is the exception destroyed when dip1008 is enabled?
Apparently, it isn't. Which
On Friday, 19 October 2018 at 23:34:01 UTC, Atila Neves wrote:
On Thursday, 20 September 2018 at 12:48:13 UTC, Steven
Schveighoffer wrote:
How is the exception destroyed when dip1008 is enabled?
Apparently, it isn't. Which renders dip1008 pretty much useless
since we could already use static
On Friday, 19 October 2018 at 23:32:44 UTC, solidstate1991 wrote:
Since it's a bit difficult to make tree traversal through range
(especially if someone wants to make it @nogc), I thought I'll
make it through opApply override, however the delegate passed
by it doesn't have the @nogc attribute
On 20/10/2018 12:32 PM, solidstate1991 wrote:
Since it's a bit difficult to make tree traversal through range
(especially if someone wants to make it @nogc), I thought I'll make it
through opApply override, however the delegate passed by it doesn't have
the @nogc attribute, which would
On Thursday, 20 September 2018 at 12:48:13 UTC, Steven
Schveighoffer wrote:
On 9/20/18 6:48 AM, Atila Neves wrote:
On Wednesday, 19 September 2018 at 21:16:00 UTC, Steven
Schveighoffer wrote:
Given dip1008, we now can throw exceptions inside @nogc code!
This is really cool, and helps make code
Since it's a bit difficult to make tree traversal through range
(especially if someone wants to make it @nogc), I thought I'll
make it through opApply override, however the delegate passed by
it doesn't have the @nogc attribute, which would automatically
make it incapable to be used in a @nogc
https://issues.dlang.org/show_bug.cgi?id=19311
Nathan S. changed:
What|Removed |Added
Summary|Add @nogc attribute to |Add @nogc attribute
https://issues.dlang.org/show_bug.cgi?id=19311
Issue ID: 19311
Summary: Add @nogc attribute to std.socket receive methods
Product: D
Version: D2
Hardware: All
OS: All
Status: NEW
Severity: enhancement
On Friday, 21 September 2018 at 11:48:50 UTC, Nemanja Boric wrote:
On Friday, 21 September 2018 at 10:06:06 UTC, Nemanja Boric
wrote:
On Friday, 21 September 2018 at 09:10:06 UTC, Jonathan M Davis
wrote:
[...]
The @__future is fully (to a reasonable degree) implemented -
and the
On Friday, 21 September 2018 at 10:06:06 UTC, Nemanja Boric wrote:
On Friday, 21 September 2018 at 09:10:06 UTC, Jonathan M Davis
wrote:
[...]
The @__future is fully (to a reasonable degree) implemented -
and the `Throwable.message` was marked with this attribute to
prevent breaking the
On Friday, 21 September 2018 at 09:10:06 UTC, Jonathan M Davis
wrote:
[...]
I think that the message member was added by Dicebot as an
attempt to fix this issue, because Sociomantic needed it, but I
don't know exactly what's going on with that or @__future.
- Jonathan M Davis
The @__future
On Wednesday, September 19, 2018 3:16:00 PM MDT Steven Schveighoffer via
Digitalmars-d wrote:
> Given dip1008, we now can throw exceptions inside @nogc code! This is
> really cool, and helps make code that uses exceptions or errors @nogc.
> Except...
I pointed out this problem whe
On 9/20/18 1:58 PM, Adam D. Ruppe wrote:
On Thursday, 20 September 2018 at 17:14:12 UTC, Steven Schveighoffer wrote:
I don't know how a performance problem can occur on an error being
thrown anyway -- the process is about to end.
Walter's objection was code size - it would throw stuff out of
don't ever have to
allocate unless the sink itself does.
I believe Tango did this a decade ago. It's a solid strategy.
However, with Tango, the default was to implement the
toString(sink) function by calling the regular toString(), which
was quite convenient but won't work with @nogc.
On Thursday, 20 September 2018 at 17:14:12 UTC, Steven
Schveighoffer wrote:
I don't know how a performance problem can occur on an error
being thrown anyway -- the process is about to end.
Walter's objection was code size - it would throw stuff out of
cache lines, even if it doesn't need to
On 9/20/18 12:24 PM, Adam D. Ruppe wrote:
On Thursday, 20 September 2018 at 15:52:03 UTC, Steven Schveighoffer wrote:
I needed to know what the slice parameters that were failing were.
Aye. Note that RangeError is called by the compiler though, so you gotta
patch dmd to make it pass the
On Thursday, 20 September 2018 at 15:52:03 UTC, Steven
Schveighoffer wrote:
I needed to know what the slice parameters that were failing
were.
Aye. Note that RangeError is called by the compiler though, so
you gotta patch dmd to make it pass the arguments to it for
index. Ugh. I did a PR for
ed
filename = nofile.txt
mode = rb
Awesome! This is just what I was thinking of. In fact, I did something
similar locally since I needed to know what the slice parameters that
were failing were. I still had to trick the @nogc to get around the &q
catcher asks for it. And if the catcher doesn't ask for it, we saved
> > an extra GC allocation (which is a plus even if we're not trying to
> > go @nogc).
>
> Except we DON'T construct the stack trace string, even lazily. If you
> look at the code I posted, it's output dire
On Wednesday, 19 September 2018 at 21:16:00 UTC, Steven
Schveighoffer wrote:
As Andrei says -- Destroy!
Nah, I agree. Actually, I'm of the opinion that string error
messages in exceptions ought to be considered harmful: you
shouldn't be doing strings at all. All the useful information
the catcher
asks for it. And if the catcher doesn't ask for it, we saved an extra GC
allocation (which is a plus even if we're not trying to go @nogc).
Except we DON'T construct the stack trace string, even lazily. If you
look at the code I posted, it's output directly to the output buffer
(via
n the catcher
asks for it. And if the catcher doesn't ask for it, we saved an extra GC
allocation (which is a plus even if we're not trying to go @nogc).
T
--
Computers shouldn't beep through the keyhole.
it to RAII managed memory and you're good
to go.
Give me deterministic destruction of exceptions caught by
scope when using dip1008 and I'll give you @nogc exception
throwing immediately. I've even already written the code!
I thought it already did that? How is the exception destroyed
when
already if only I'd known @nogc was ignored
as well as pure.
It's a recent development:
https://dlang.org/changelog/2.082.0#debug-unsafe :
Unsafe code can now be used in debug blocks
https://dlang.org/changelog/2.079.0 :
Bugzilla 16492: support @nogc in debug{} blocks
Ah. I was wondering
On Thursday, 20 September 2018 at 12:41:07 UTC, Petar Kirov
[ZombineDev] wrote:
On Thursday, 20 September 2018 at 10:50:49 UTC, Atila Neves
wrote:
This pattern is incredibly easy to wrap and reuse as needed. I
would've done already if only I'd known @nogc was ignored as
well as pure.
It's
On 9/20/18 6:48 AM, Atila Neves wrote:
On Wednesday, 19 September 2018 at 21:16:00 UTC, Steven Schveighoffer
wrote:
Given dip1008, we now can throw exceptions inside @nogc code! This is
really cool, and helps make code that uses exceptions or errors @nogc.
Except...
The mechanism to report
On Thursday, 20 September 2018 at 10:50:49 UTC, Atila Neves wrote:
This pattern is incredibly easy to wrap and reuse as needed. I
would've done already if only I'd known @nogc was ignored as
well as pure.
It's a recent development:
https://dlang.org/changelog/2.082.0#debug-unsafe :
Unsafe
, arg)); // No good -
format is not @nogc
Another method:
debug
assert(condition, format(string, arg, arg));
else
assert(condition, string);
because @nogc is ignored in debug conditionals, just like
purity is ignored in debug conditionals.
That doesn't cut it on so many levels
On Wednesday, 19 September 2018 at 21:16:00 UTC, Steven
Schveighoffer wrote:
Given dip1008, we now can throw exceptions inside @nogc code!
This is really cool, and helps make code that uses exceptions
or errors @nogc. Except...
The mechanism to report what actually went wrong
On 19/09/18 22:53, Walter Bright wrote:
On 9/19/2018 10:13 AM, Shachar Shemesh wrote:
assert(condition, string); // string is useless without actual info
about what went wrong.
assert(condition, format(string, arg, arg)); // No good - format is
not @nogc
Another method:
debug
On 9/19/18 7:53 PM, Seb wrote:
On Wednesday, 19 September 2018 at 21:28:56 UTC, Steven Schveighoffer
wrote:
On 9/19/18 5:16 PM, Steven Schveighoffer wrote:
One further thing: I didn't make the sink version of message @nogc,
but in actuality, it could be.
We recently introduced support
On Wednesday, 19 September 2018 at 21:28:56 UTC, Steven
Schveighoffer wrote:
On 9/19/18 5:16 PM, Steven Schveighoffer wrote:
One further thing: I didn't make the sink version of message
@nogc, but in actuality, it could be.
We recently introduced support for output ranges in the
formatting
On 9/19/18 5:16 PM, Steven Schveighoffer wrote:
One further thing: I didn't make the sink version of message @nogc, but
in actuality, it could be. Notice how it allocates using the stack. Even
if we needed some indeterminate amount of memory, it would be simple to
use C malloc/free, or alloca
Given dip1008, we now can throw exceptions inside @nogc code! This is
really cool, and helps make code that uses exceptions or errors @nogc.
Except...
The mechanism to report what actually went wrong for an exception is a
string passed to the exception during *construction*. Given that you
On 9/19/2018 11:35 AM, Steven Schveighoffer wrote:
I'm running into this coincidentally right now, when trying to debug a PR. I
found I'm getting a range error deep inside a phobos function. But because
Phobos is trying to be pure @nogc nothrow @safe, I can do almost nothing to
display what
On 9/19/2018 10:13 AM, Shachar Shemesh wrote:
assert(condition, string); // string is useless without actual info about
what went wrong.
assert(condition, format(string, arg, arg)); // No good - format is not @nogc
Another method:
debug
assert(condition, format(string, arg, arg
On 9/7/2018 10:35 AM, Eugene Wissner wrote:
fill() uses enforce() which allocates and throws.
The addition of -dip1008 stopped using the gc for throwing exceptions, but it's
opt-in at the moment.
On 19/09/18 21:35, Steven Schveighoffer wrote:
On 9/19/18 1:13 PM, Shachar Shemesh wrote:
There is a catch, though. Writing Mecca with @nogc required
re-implementing quite a bit of druntime. Mecca uses its own exception
allocations (mkEx, just saw it's not yet documented, it's under
On 9/19/18 1:13 PM, Shachar Shemesh wrote:
There is a catch, though. Writing Mecca with @nogc required
re-implementing quite a bit of druntime. Mecca uses its own exception
allocations (mkEx, just saw it's not yet documented, it's under
mecca.lib.exception). The same module also has
On 08/09/18 11:07, Peter Alexander wrote:
I'd love to know if anyone is making good use of @nogc in a larger code
base and is happy with it. Weka.io?
No, sorry.
Actually, yes.
Well, sortof.
The main Weka codebase hardly uses any annotations of any kind. Not
@nogc nor others
and wanted to make sure everything
continued working before all GC allocations were removed.
mecca.lib.reflection has "as".
https://weka-io.github.io/mecca/docs/mecca/lib/reflection/as.html
Here is how you use it:
void fun() @nogc {
as!"@nogc"( some code that is not @no
On Friday, 7 September 2018 at 17:01:09 UTC, Meta wrote:
So it seems that it's never worked. Looking at the
implementation, it uses a std.container.BinaryHeap, so it'd
require a small rewrite to work with @nogc.
AFAICT, extending std.container with support for specifying you
own @nogc
On Monday, 10 September 2018 at 09:11:38 UTC, Kagamin wrote:
On Saturday, 8 September 2018 at 08:32:58 UTC, Guillaume Piolat
wrote:
There is no other choice when the runtime is disabled but to
have @nogc.
It's a fantastic peace of mind for high-performance to be able
to _enforce_ something
On Saturday, 8 September 2018 at 08:32:58 UTC, Guillaume Piolat
wrote:
Not Weka but we are happy with @nogc and without @nogc our job
would be impossible.
There is one way to code without garbage collector somewhat
practically without annotating @nogc, the way I use: Compile
manually only
On 10/09/2018 9:11 PM, Kagamin wrote:
On Saturday, 8 September 2018 at 08:32:58 UTC, Guillaume Piolat wrote:
There is no other choice when the runtime is disabled but to have @nogc.
It's a fantastic peace of mind for high-performance to be able to
_enforce_ something will not allocate.
You
On Saturday, 8 September 2018 at 08:32:58 UTC, Guillaume Piolat
wrote:
There is no other choice when the runtime is disabled but to
have @nogc.
It's a fantastic peace of mind for high-performance to be able
to _enforce_ something will not allocate.
You can't have a working GC allocation
On Saturday, 8 September 2018 at 08:32:58 UTC, Guillaume Piolat
wrote:
On Saturday, 8 September 2018 at 08:07:07 UTC, Peter Alexander
wrote:
I'd love to know if anyone is making good use of @nogc in a
larger code base and is happy with it. Weka.io?
Not Weka but we are happy with @nogc
On Saturday, 8 September 2018 at 08:07:07 UTC, Peter Alexander
wrote:
I'd love to know if anyone is making good use of @nogc in a
larger code base and is happy with it. Weka.io?
Not Weka but we are happy with @nogc and without @nogc our job
would be impossible.
You don't like it fine. But I
On Friday, 7 September 2018 at 17:01:09 UTC, Meta wrote:
You are allowed to call "@gc" functions inside @nogc functions
if you prefix them with a debug statement, e.g.:
Thanks! I was aware that debug is an escape hatch for pure, but
didn't consider it for @nogc.
I've been think
(?) is @nogc, so
he either missed topNCopy or the gc-ness of the function has
changed sometime between ~2015 and now.
It was never true. Here is another example:
import std.algorithm;
void main() @nogc
{
int[4] a, b;
fill(a[], b[]);
}
The funny thing is that fill() doesn't always allocate
On Friday, 7 September 2018 at 16:44:05 UTC, Peter Alexander
wrote:
I recently wrote a small program of ~600 lines of code to solve
an optimisation puzzle. Profiling showed that GC allocations
were using non-trivial CPU, so I decided to try and apply @nogc
to remove allocations
On Friday, 7 September 2018 at 17:01:09 UTC, Meta wrote:
Semi-unrelated, but I think you should open a bug for this one.
I remember Andrei stating before that every function in
std.algorithm except for LevehnsteinDistance(?) is @nogc, so he
either missed topNCopy or the gc-ness of the function
On Fri, Sep 07, 2018 at 04:44:05PM +, Peter Alexander via Digitalmars-d
wrote:
> I recently wrote a small program of ~600 lines of code to solve an
> optimisation puzzle. Profiling showed that GC allocations were using
> non-trivial CPU, so I decided to try and apply @nogc
On Friday, 7 September 2018 at 16:44:05 UTC, Peter Alexander
wrote:
I recently wrote a small program of ~600 lines of code to solve
an optimisation puzzle. Profiling showed that GC allocations
were using non-trivial CPU, so I decided to try and apply @nogc
to remove allocations
I recently wrote a small program of ~600 lines of code to solve
an optimisation puzzle. Profiling showed that GC allocations were
using non-trivial CPU, so I decided to try and apply @nogc to
remove allocations. This is a small experience report of my
efforts.
1. My program does some
On Wednesday, 5 September 2018 at 21:06:07 UTC, Adam D. Ruppe
wrote:
It doesn't affect @nogc because the function above will throw a
statically-allocated object instead of creating a new one (if
it is out of memory, where would it allocate a new one anyway?).
It doesn't affect nothrow because
ry
be non-`nothrow`, and in turn, non-`@nogc`?
No, it doesn't affect either of those.
It doesn't affect @nogc because the function above will throw a
statically-allocated object instead of creating a new one (if it
is out of memory, where would it allocate a new one anyway?).
It doesn't affe
error?
If so should all algorithms that potentially allocates memory be
non-`nothrow`, and in turn, non-`@nogc`?
And how does this relate to instead using `assert`s and DIP-1008?
[1]: https://ziglang.org/
)
{
enum attrs = functionAttributes!T | FunctionAttribute.nogc;
return cast(SetFunctionAttributes!(T, functionLinkage!T,
attrs)) t;
}
void f(T)(auto ref T) {
writeln("yo");
}
@nogc void main() {
assumeNoGC(() => f(3));
// or
assumeNoGC( { writeln("yo&
On Saturday, 1 September 2018 at 21:53:03 UTC, aliak wrote:
Anyway around this?
I don't know if your situation allows it, but you can mark f
explicitly as always @nogc. If your design assumes that it's
@nogc, it's a good idea to add the attribute anyway.
You can also use the C printf
;
return cast(SetFunctionAttributes!(T, functionLinkage!T, attrs)) t;
}
void f(T)(auto ref T) {
writeln("yo");
}
@nogc void main() {
assumeNoGC(() => f(3));
// or
assumeNoGC( { writeln("yo"); });
}
Ali
I would like to debug a few things and need to insert print
statements to figure things out. I thought that using debug print
would be ok in nogc code?
Seems it make the compiler infer f as not nogc though so this is
basically unworkable unless I go through my entire source code
and remove
401 - 500 of 2667 matches
Mail list logo
