a timeless
piece that speaks of enduring commitment and style, platinum is
pure perfection.
On Tuesday, 8 April 2025 at 15:54:52 UTC, Timon Gehr wrote:
In any case, casting a memory allocator to `pure` should be
fine. Any reasonable definition of `pure` we can come up with
in the future would be compatible with that.
Yes, this is also what I think. Of course an allocator cannot be
On Tuesday, April 8, 2025 9:07:45 AM MDT Guillaume Piolat via
Digitalmars-d-learn wrote:
> On Tuesday, 8 April 2025 at 14:00:56 UTC, Jonathan M Davis wrote:
> > Of course, I'm also increasingly of the opinion that pure was a
> > mistake in general, because it does almost
On 4/8/25 17:07, Guillaume Piolat wrote:
On Tuesday, 8 April 2025 at 14:00:56 UTC, Jonathan M Davis wrote:
Of course, I'm also increasingly of the opinion that pure was a
mistake in general, because it does almost nothing in practice but
routinely doesn't work with straightforward
On Tuesday, 8 April 2025 at 14:00:56 UTC, Jonathan M Davis wrote:
Of course, I'm also increasingly of the opinion that pure was a
mistake in general, because it does almost nothing in practice
but routinely doesn't work with straightforward code - and it's
definitely one of t
On Tuesday, 8 April 2025 at 14:00:56 UTC, Jonathan M Davis wrote:
You basically have to lie to the compiler and cast the function
pointer to pure [...].
That being said, core.memory has pureMalloc and pureFree which
do that for you already, including mucking around with errno to
ensure
On Tuesday, April 8, 2025 5:28:57 AM MDT Dom DiSc via Digitalmars-d-learn wrote:
> Hi.
>
> I want to create my own allocator, but using malloc is not pure
> (it internally has to have some "global state"). But the GC also
> has this "global state" and still is
Hi.
I want to create my own allocator, but using malloc is not pure
(it internally has to have some "global state"). But the GC also
has this "global state" and still is considered "pure".
So internally the impurity of the allocators has been hidden.
How
On Monday, 16 October 2023 at 18:05:04 UTC, Paul wrote:
On Thursday, 12 October 2023 at 21:20:44 UTC, Jonathan M Davis
wrote:
look like?
Types can have static members.
Basically what it comes down to is that outside of immutable
data, pure functions only have access to their arguments and
On Monday, October 16, 2023 12:05:04 PM MDT Paul via Digitalmars-d-learn
wrote:
> On Thursday, 12 October 2023 at 21:20:44 UTC, Jonathan M Davis
>
> wrote:
> > look like?
> >
> > Types can have static members.
> >
> > Basically what it comes down to is t
On Monday, October 16, 2023 12:05:04 PM MDT Paul via Digitalmars-d-learn
wrote:
> On Thursday, 12 October 2023 at 21:20:44 UTC, Jonathan M Davis
>
> wrote:
> > look like?
> >
> > Types can have static members.
> >
> > Basically what it comes down to is t
On Thursday, 12 October 2023 at 21:20:44 UTC, Jonathan M Davis
wrote:
look like?
Types can have static members.
Basically what it comes down to is that outside of immutable
data, pure functions only have access to their arguments and to
what they can access via their arguments (be it by
On Thursday, 12 October 2023 at 21:20:44 UTC, Jonathan M Davis
wrote:
Thanks Jonathan
On Thursday, 12 October 2023 at 19:33:32 UTC, Paul wrote:
If **int x** is global mutable state, what does static mutable
state look like?
In addition to Jonathan's reply, see:
https://dlang.org/spec/function.html#local-static-variables
On Thursday, October 12, 2023 1:33:32 PM MDT Paul via Digitalmars-d-learn
wrote:
> The spec doc has the following statement and corresponding
> example:
> ***"Pure functions cannot directly access global or static
> mutable state."***
>
> ```d
> int x;
> immut
ring why those functions are marked `pure` - they
> >> must affect the GC's bookkeeping state.
>
> I guess it was because the GC's internal state is not supposed to
> be observable outside internal GC functions. I find it harder to
> accept some of those than `GC.malloc` b
On Wednesday, 2 August 2023 at 17:55:12 UTC, Nick Treleaven wrote:
On Wednesday, 2 August 2023 at 17:52:00 UTC, Nick Treleaven
wrote:
Now I'm wondering why those functions are marked `pure` - they
must affect the GC's bookkeeping state.
I guess it was because the GC's intern
On Wednesday, 2 August 2023 at 17:52:00 UTC, Nick Treleaven wrote:
Now I'm wondering why those functions are marked `pure` - they
must affect the GC's bookkeeping state.
Here's the pull that added it:
https://github.com/dlang/druntime/pull/3561
On Tuesday, 27 December 2022 at 12:22:45 UTC, Johan wrote:
does semantic analysis (create AST; note that there is a ton of
calls needed to complete SeMa), and finally outputs object code.
If you want to capitalize the word use SemA. ;)
On Monday, 26 December 2022 at 19:13:01 UTC, Alexandru Ermicioi
wrote:
Hi team,
I'd like to ask a lazy question:
How easy is to use D compiler frontend without backend?
How complicated would be to write a transpiler, and from which
files should you start modifications?
I'm wondering if somet
On 27/12/2022 9:34 PM, Alexandru Ermicioi wrote:
Any idea from which file should I start at least learning about this
glue code?
You can look at dmd's... but realistically the work hasn't been done at
that level to make it easy to work with.
https://github.com/dlang/dmd/blob/master/compiler/
On Monday, 26 December 2022 at 23:08:59 UTC, Richard (Rikki)
Andrew Cattermole wrote:
...
That on the other hand... Yeah, things aren't great on that
front. The thing you want to implement is what we call glue
code and isn't really setup right now for this (nobody has
tried like this, ignorin
On 27/12/2022 8:13 AM, Alexandru Ermicioi wrote:
How easy is to use D compiler frontend without backend?
Easy.
https://github.com/dlang/dmd/blob/master/compiler/test/dub_package/frontend.d
How complicated would be to write a transpiler, and from which files
should you start modifications?
Hi team,
I'd like to ask a lazy question:
How easy is to use D compiler frontend without backend?
How complicated would be to write a transpiler, and from which
files should you start modifications?
I'm wondering if something like
https://typescripttolua.github.io/ could be done, but with d
out
}
}
void f2()
{
foreach(i; 0..4_000_000)
{
// defeat optimizations
asm @safe pure nothrow @nogc {}
}
}
auto r = benchmark!(f0, f1, f2)(1);
writeln(r[0]); // 4 μs
writeln(r[1]); // 4 μs
writeln(r[2]); // 1 ms
On Friday, 28 October 2022 at 09:48:14 UTC, ab wrote:
Thanks to H.S. Teoh and Dennis for the suggestions, they both
work. I like the empty asm block a bit more because it is less
invasive, but it only works with ldc.
I used the volatileLoad/volatileStore functions to ensure that
the compiler
On Friday, 28 October 2022 at 09:48:14 UTC, ab wrote:
On Thursday, 27 October 2022 at 17:17:01 UTC, ab wrote:
[...]
Thanks to H.S. Teoh and Dennis for the suggestions, they both
work. I like the empty asm block a bit more because it is less
invasive, but it only works with ldc.
@Imperatorn
On Thursday, 27 October 2022 at 17:17:01 UTC, ab wrote:
Hi,
when trying to compare different implementations of the
optimized builds of a pure function using benchmark from
std.datetime.stopwatch, I get times equal to zero, I suppose
because the functions are not executed as they do not have
..4_000_000)
{
// defeat optimizations
asm @safe pure nothrow @nogc {}
}
}
auto r = benchmark!(f0, f1, f2)(1);
writeln(r[0]); // 4 μs
writeln(r[1]); // 4 μs
writeln(r[2]); // 1 ms
}
```
On Thu, Oct 27, 2022 at 06:20:10PM +, Imperatorn via Digitalmars-d-learn
wrote:
> On Thursday, 27 October 2022 at 17:17:01 UTC, ab wrote:
> > Hi,
> >
> > when trying to compare different implementations of the optimized
> > builds of a pure fu
On Thursday, 27 October 2022 at 17:17:01 UTC, ab wrote:
Hi,
when trying to compare different implementations of the
optimized builds of a pure function using benchmark from
std.datetime.stopwatch, I get times equal to zero, I suppose
because the functions are not executed as they do not have
Hi,
when trying to compare different implementations of the optimized
builds of a pure function using benchmark from
std.datetime.stopwatch, I get times equal to zero, I suppose
because the functions are not executed as they do not have side
effects.
The same happens with the example from
On Thursday, 25 November 2021 at 07:26:48 UTC, sclytrack wrote:
int * pureFunction()
1) the pointer needs to be the same.
2) the value that the pointer points to needs to be the same. I
call this the "value
of interest" with relation to pure. The pointer doesn't matter.
3) b
On Thursday, 25 November 2021 at 07:26:48 UTC, sclytrack wrote:
My understanding is that pure is used for compiler optimization
in loops and expressions. It leaves out multiple calls if it
figures out it is not needed.
[one
link](https://klickverbot.at/blog/2012/05/purity-in-d
On Thursday, 25 November 2021 at 07:26:48 UTC, sclytrack wrote:
My understanding is that pure is used for compiler optimization
in loops and expressions. It leaves out multiple calls if it
figures out it is not needed.
Is pure used for anything else?
int * pureFunction()
1) the pointer
My understanding is that pure is used for compiler optimization
in loops and expressions. It leaves out multiple calls if it
figures out it is not needed.
Is pure used for anything else?
int * pureFunction()
1) the pointer needs to be the same.
2) the value that the pointer points to needs
On Monday, 2 August 2021 at 15:10:06 UTC, vit wrote:
On Monday, 2 August 2021 at 11:28:46 UTC, Tejas wrote:
[...]
Try this:
```d
void main(){
fp = cast(typeof(fp))&VFORMAT; //fails
}
```
Agh, stupid me.
You the man!!
p;Fn))) {
enum N = __traits(identifier, Fn);
enum string asPure = "private alias " ~ N ~ "_PURE
= " ~ typeof(&Fn).stringof ~ " pure;\n" ~ "__gshared immutable
" ~ N ~ "_PURE " ~ P ~"= cast(" ~ N ~ "_PURE) &" ~ N ~ &
null;
}
extern (C) string function(LogLevel level, string file, size_t
line, char[] tmp, bool line_break, string tag, string fmt, ...)
@nogc nothrow pure fp;
void main(){
fp = &VFORMAT; //fails
}
```
Try this:
```d
void main(){
fp = cast(typeof(fp))&VFORMAT; //fails
}
```
p;Fn))) {
enum N = __traits(identifier, Fn);
enum string asPure = "private alias " ~ N ~ "_PURE
= " ~ typeof(&Fn).stringof ~ " pure;\n" ~ "__gshared immutable
" ~ N ~ "_PURE " ~ P ~"= cast(" ~ N ~ "_PURE) &" ~ N ~ &
ring asPure = "private alias " ~ N ~ "_PURE =
" ~ typeof(&Fn).stringof ~ " pure;\n" ~ "__gshared immutable " ~
N ~ "_PURE " ~ P ~"= cast(" ~ N ~ "_PURE) &" ~ N ~ " ;" ;
}
enum xx = asPure!("VFORMATP&
On Friday, 12 February 2021 at 12:17:13 UTC, Per Nordlöw wrote:
On Tuesday, 9 February 2021 at 03:05:10 UTC, frame wrote:
On Sunday, 7 February 2021 at 14:13:18 UTC, vitamin wrote:
Why using 'new' is allowed in pure functions but calling
GC.addRange or GC.removeRange isn't a
for you :P
[...]
Thanks,
Yes, I am implementing container (ref counted pointer). When
allcoator is Mallcoator (pure allocate and deallocate) and
constructor of Type inside rc pointer has pure constructor and
destructor, then only impure calls was GC.addRange and
GC.removeRange.
Now there are mark
ef counted pointer). When
allcoator is Mallcoator (pure allocate and deallocate) and
constructor of Type inside rc pointer has pure constructor and
destructor, then only impure calls was GC.addRange and
GC.removeRange.
Now there are marked as pure.
On Tuesday, 9 February 2021 at 03:05:10 UTC, frame wrote:
On Sunday, 7 February 2021 at 14:13:18 UTC, vitamin wrote:
Why using 'new' is allowed in pure functions but calling
GC.addRange or GC.removeRange isn't allowed?
Would making
`new T[]` inject a call to `GC.addRange` ba
calls in Array.~this() can be marked as
`pure`, as the Array type as a whole implements the RAII design
pattern and offers at least basic exception-safety guarantees:
https://github.com/dlang/phobos/blob/81a968dee68728f7ea245b6983eb7236fb3b2981/std/container/array.d#L296-L298
(The whole function
On Wednesday, 10 February 2021 at 13:44:53 UTC, vit wrote:
On Wednesday, 10 February 2021 at 12:17:43 UTC, rm wrote:
On 09/02/2021 5:05, frame wrote:
On Sunday, 7 February 2021 at 14:13:18 UTC, vitamin wrote:
Why using 'new' is allowed in pure functions but calling
GC.a
On Wednesday, 10 February 2021 at 12:17:43 UTC, rm wrote:
On 09/02/2021 5:05, frame wrote:
On Sunday, 7 February 2021 at 14:13:18 UTC, vitamin wrote:
Why using 'new' is allowed in pure functions but calling
GC.addRange or GC.removeRange isn't allowed?
Does 'new' vi
On 09/02/2021 5:05, frame wrote:
On Sunday, 7 February 2021 at 14:13:18 UTC, vitamin wrote:
Why using 'new' is allowed in pure functions but calling GC.addRange
or GC.removeRange isn't allowed?
Does 'new' violate the 'pure' paradigm? Pure function
On Tuesday, 9 February 2021 at 21:00:39 UTC, Paul Backus wrote:
On Tuesday, 9 February 2021 at 19:53:27 UTC, Temtaime wrote:
pure is broken. Just don't [use it]
Allowing memory allocation in pure code in a language that can
distinguish between pointer equality and value equality is,
On Tuesday, 9 February 2021 at 20:50:12 UTC, Max Haughton wrote:
On Tuesday, 9 February 2021 at 19:53:27 UTC, Temtaime wrote:
On Sunday, 7 February 2021 at 14:13:18 UTC, vitamin wrote:
Why using 'new' is allowed in pure functions but calling
GC.addRange or GC.removeRange isn't
On Tuesday, 9 February 2021 at 19:53:27 UTC, Temtaime wrote:
On Sunday, 7 February 2021 at 14:13:18 UTC, vitamin wrote:
Why using 'new' is allowed in pure functions but calling
GC.addRange or GC.removeRange isn't allowed?
pure is broken. Just don't [use it]
[Citation needed]
On Sunday, 7 February 2021 at 14:13:18 UTC, vitamin wrote:
Why using 'new' is allowed in pure functions but calling
GC.addRange or GC.removeRange isn't allowed?
pure is broken. Just don't [use it]
On Sunday, 7 February 2021 at 14:13:18 UTC, vitamin wrote:
Why using 'new' is allowed in pure functions but calling
GC.addRange or GC.removeRange isn't allowed?
Does 'new' violate the 'pure' paradigm? Pure functions can only
call pure functions and GC
Why using 'new' is allowed in pure functions but calling
GC.addRange or GC.removeRange isn't allowed?
On 23.09.20 02:06, DlangUser38 wrote:
The following analysis might be wrong but I think that `scope` as a
**member** function attribute is not supposed to be used as that is not
even documented.
It's documented here:
https://dlang.org/spec/memory-safe-d.html#scope-return-params
Quote: "[`scop
On Wednesday, 23 September 2020 at 00:06:38 UTC, DlangUser38
wrote:
Hmm, why would `b` have longer lifetime? Isn't the lifetime of
`b` throughout `bar`?
The following analysis might be wrong but I think that `scope`
as a **member** function attribute is not supposed to be used
as that is not
into other parameters
without the `scope` qualifier?
This
class Bar
{
void bar(scope Bar b) @safe pure
{
b = this;
}
}
compiles but this
class Bar
{
scope void bar(scope Bar b) @safe pure
{
b = this; // Error: scope variable `this` assigned to
`b
Bar
{
void bar(scope Bar b) @safe pure
{
b = this;
}
}
compiles but this
class Bar
{
scope void bar(scope Bar b) @safe pure
{
b = this; // Error: scope variable `this` assigned to `b` with
longer lifetime
}
}
Hmm, why would `b` have longer lifetime
On Saturday, 19 September 2020 at 18:48:31 UTC, Jacob Carlborg
wrote:
A nested class seems to be able to escape the `this` reference:
Ahh, thanks.
I just realized that it can escape into other parameters without
the `scope` qualifier?
This
class Bar
{
void bar(scope Bar b) @safe pure
On 2020-09-19 18:07, Per Nordlöw wrote:
If an aggregate member is pure but not scope when can it escape the
`this` pointer?.
Only via return?
I'm not sure if returning the `this` pointer is considered escaping it.
The caller already had access to it. Under the hood, the `this` pointe
On Saturday, 19 September 2020 at 16:07:24 UTC, Per Nordlöw wrote:
If an aggregate member is pure but not scope when can it escape
the `this` pointer?.
Or rather when and, if so, how can the member allow its `this`
pointer to escape?
It seems to me like the `scope` qualifier is no effect in
If an aggregate member is pure but not scope when can it escape
the `this` pointer?.
Only via return?
In the struct and class case?
On Thursday, 7 May 2020 at 20:12:03 UTC, learner wrote:
Modules of D standard library aren't in a good shape, if
everyone suggests alternatives for a basic building block as
variant.
I don't think Variant as a whole is the problem, when one uses it
as the infinite variant it does fairly muc
On Thursday, 7 May 2020 at 15:36:36 UTC, Ben Jones wrote:
I've been using SumType... What are the main differences
between it and TaggedAlgebraic?
I have not used the the algebraic type of Taggedalgebraic tbh,
but it also has a tagged union type that I have good experiences
with. Unlike Phobo
On Thursday, 7 May 2020 at 10:21:26 UTC, Dukc wrote:
that's the reason why `std.range.enumerate` does not infer
attributes for example
This was wrong. `enumerate` can infer. It's `lockstep` that
cannot.
On Thursday, 7 May 2020 at 14:53:10 UTC, Steven Schveighoffer
wrote:
On 5/7/20 5:22 AM, learner wrote:
[...]
Because VariantN (the base of Algebraic) can literally hold
anything, it cannot be pure, @safe, nothrow, @nogc.
As others have recommended, I suggest using TaggedAlgebraic. I
On Thursday, 7 May 2020 at 15:36:36 UTC, Ben Jones wrote:
On Thursday, 7 May 2020 at 14:53:10 UTC, Steven Schveighoffer
wrote:
As others have recommended, I suggest using TaggedAlgebraic. I
recently have been using it to create an algebraic type to
hold a MYSQL value, so I can migrate the mys
On Thursday, 7 May 2020 at 14:53:10 UTC, Steven Schveighoffer
wrote:
As others have recommended, I suggest using TaggedAlgebraic. I
recently have been using it to create an algebraic type to hold
a MYSQL value, so I can migrate the mysql-native library to be
@safe (mysql-native currently uses
On 5/7/20 5:22 AM, learner wrote:
Good morning,
Is there a reason why std.variant.visit is not inferring pure?
```
void test() pure {
Algebraic!(int, string) alg;
visit!( (string) => 0, (int) => 0)(alg);
}
Error: pure function test cannot call impure function
test.visit!(Va
On Thursday, 7 May 2020 at 13:17:21 UTC, learner wrote:
I've find this: https://issues.dlang.org/show_bug.cgi?id=16662
Hmm, that explains why it can't infer attributes. An unlimited
variant could contain an object, and using it might or might not
be .
Of course, it could still infer the att
On Thursday, 7 May 2020 at 10:41:01 UTC, Simen Kjærås wrote:
On Thursday, 7 May 2020 at 09:22:28 UTC, learner wrote:
Good morning,
Is there a reason why std.variant.visit is not inferring pure?
```
void test() pure {
Algebraic!(int, string) alg;
visit!( (string) => 0, (int) =>
On Thursday, 7 May 2020 at 09:22:28 UTC, learner wrote:
Good morning,
Is there a reason why std.variant.visit is not inferring pure?
```
void test() pure {
Algebraic!(int, string) alg;
visit!( (string) => 0, (int) => 0)(alg);
}
Error: pure function test cannot call impure fu
On Thursday, 7 May 2020 at 09:22:28 UTC, learner wrote:
Good morning,
Is there a reason why std.variant.visit is not inferring pure?
I think `variant` will not infer any trributes. I'm not sure why.
It could be some language limitation (that's the reason why
`std.range.enumerate
Good morning,
Is there a reason why std.variant.visit is not inferring pure?
```
void test() pure {
Algebraic!(int, string) alg;
visit!( (string) => 0, (int) => 0)(alg);
}
Error: pure function test cannot call impure function
test.visit!(VariantN!(16LU, int, string)).visit
```
On Friday, 29 November 2019 at 15:54:13 UTC, realhet wrote:
On Friday, 29 November 2019 at 15:49:24 UTC, Paul Backus wrote:
It's actually a much simpler reason: filter calls .front twice
for each element in its input (once to check if the value
satisfies the predicate, and then again to return
On Friday, 29 November 2019 at 15:49:24 UTC, Paul Backus wrote:
It's actually a much simpler reason: filter calls .front twice
for each element in its input (once to check if the value
satisfies the predicate, and then again to return the value if
it does), and the range returned by map doesn't
On Friday, 29 November 2019 at 15:30:22 UTC, realhet wrote:
...
Unfortunately function purity is not the answer.
I put a very long calculation into the transform function which
is called from "map!".
And the "filter!" is making the "map!" call my function 2 times:
First for the "filter!" to
remove the filter! it does only one transform function
call per element.
Is this because the function is NOT PURE, so Phobos thinks that
the function can give different results for the same input?
If I modify the function to be pure, will the transform
function be called only once?
It&#
per element.
Is this because the function is NOT PURE, so Phobos thinks that
the function can give different results for the same input?
If I modify the function to be pure, will the transform function
be called only once?
Hi Guys!
In my programm, I have a custom String-type that I want to
initialize some variables of at compile time by casting a string
literal to said custom String type. I thought I could achieve
this straight forwardly, but after trying a bit, I could not find
a (simple) working solution. I m
On 27.02.19 19:10, Dukc wrote:
I tested a bit, and it appears that attribute inference is not done at
all for templates inside structs -the attribute need not be a delegate:
struct S
{
static int fImpl(Ret)() { return Ret.init; }
pragma(msg, __traits(getFunctionAttribute
On Wednesday, 27 February 2019 at 17:23:21 UTC, Q. Schroll wrote:
For whatever reason, when I put the code in a struct, the @safe
testing line tells me, it's @system now.
I tested a bit, and it appears that attribute inference is not
done at all for templates inside structs -the attribute need
On Wednesday, 27 February 2019 at 18:06:49 UTC, Stefan Koch wrote:
the struct gets drawn into your delegate-context.
and I guess that taints the function.
Even if it did, it should not make the delegate @system. And it
does not, since this manifest with static functions and function
pointer
On Wednesday, 27 February 2019 at 17:23:21 UTC, Q. Schroll wrote:
I have a template function `fImpl` I whish to instantiate
manually using the new name `f`. Reason is simple: `f` should
not be a template, but overloading it makes it easier that way.
Nothing's more simple in D:
[...]
the stru
I have a template function `fImpl` I whish to instantiate
manually using the new name `f`. Reason is simple: `f` should not
be a template, but overloading it makes it easier that way.
Nothing's more simple in D:
int fImpl(T)(T value) { return cast(int) value; }
alias f = fImpl!int;
On Monday, 20 August 2018 at 19:36:15 UTC, werter wrote:
The code below doesn't work. Is it possible to make a pure
opEquals in a class?
[...]
pure bool opEquals(const A rhs) const
{
return b == rhs.b;
}
It do
The code below doesn't work. Is it possible to make a pure
opEquals in a class?
void main()
{
class A
{
bool a;
int b;
this(bool g, int h)
{
a = g;
On Wednesday, 8 August 2018 at 17:08:57 UTC, vit wrote:
Hello, is in phobos some function which convert float/double to
string and is pure @nogc and nothrow?
Short answer: no.
Long answer: https://issues.dlang.org/show_bug.cgi?id=17628
vit wrote:
thanks, that code can be modified to pure nothrow @nogc @safe.
Is that lib ok? Is little complicated...
converting float to string is a *very* complicated task. that lib is quite
small for what it is doing ('cause it hacks around some... interesting
cases). the *real* thing
On Wednesday, 8 August 2018 at 17:40:11 UTC, ketmar wrote:
vit wrote:
Hello, is in phobos some function which convert float/double
to string and is pure @nogc and nothrow?
i don't think that you can make it `pure`, but you certainly
can make it `nothrow`, `@nogc` and ctfe-able.
vit wrote:
Hello, is in phobos some function which convert float/double to string
and is pure @nogc and nothrow?
i don't think that you can make it `pure`, but you certainly can make it
`nothrow`, `@nogc` and ctfe-able. it's dangerous to go alone! take this[0].
[0] http://
On 8/8/18 1:08 PM, vit wrote:
Hello, is in phobos some function which convert float/double to string
and is pure @nogc and nothrow?
Not one that I can see. formattedWrite doesn't seem to be pure.
-Steve
Hello, is in phobos some function which convert float/double to
string and is pure @nogc and nothrow?
On Thursday, 19 July 2018 at 06:35:36 UTC, Simen Kjærås wrote:
On Wednesday, 18 July 2018 at 11:28:54 UTC, Timoses wrote:
But why is a context pointer a problem? Is it problematic
because the context pointer to the main scope can not
guarantee `immutable`? E.g. if I happened to use data from
m
On Wednesday, 18 July 2018 at 11:28:54 UTC, Timoses wrote:
But why is a context pointer a problem? Is it problematic
because the context pointer to the main scope can not guarantee
`immutable`? E.g. if I happened to use data from main in a
function of the immutable struct then... well then what
On Tuesday, 17 July 2018 at 06:24:12 UTC, Simen Kjærås wrote:
That makes sense. The problem is F has a context pointer to the
main() block, since it's a non-static struct with methods
inside a block. It doesn't actually use the context pointer for
anything, so it possibly shouldn't have one,
On Monday, 16 July 2018 at 13:13:53 UTC, Timoses wrote:
On Monday, 16 July 2018 at 12:00:57 UTC, Simen Kjærås wrote:
On Monday, 16 July 2018 at 11:43:03 UTC, Timoses wrote:
Why does this fail?
It doesn't. Not using DMD 2.081.1 under Windows, at least. I
tried adding a bitfield since you ment
On Monday, 16 July 2018 at 13:13:53 UTC, Timoses wrote:
On Monday, 16 July 2018 at 12:00:57 UTC, Simen Kjærås wrote:
On Monday, 16 July 2018 at 11:43:03 UTC, Timoses wrote:
Why does this fail?
It doesn't. Not using DMD 2.081.1 under Windows, at least. I
tried adding a bitfield since you ment
On Monday, 16 July 2018 at 12:00:57 UTC, Simen Kjærås wrote:
On Monday, 16 July 2018 at 11:43:03 UTC, Timoses wrote:
Why does this fail?
It doesn't. Not using DMD 2.081.1 under Windows, at least. I
tried adding a bitfield since you mentioned it, but it compiles
nicely for me. Which version o
1 - 100 of 576 matches
Mail list logo
