On Sat, 05 Apr 2014 08:26:01 -0400, Artur Skawina art.08...@gmail.com
wrote:
On 03/26/14 00:30, Artur Skawina wrote:
It's ok to treat allocator and factory functions as pure, because those
really
are logically pure, ie can't affect any /visible/ state and return
results that
are unique.
On 03/25/14 14:30, Steven Schveighoffer wrote:
Of course naturally, with all things this low-level, we have to make
decisions as to what is *provably* @safe/pure/nothrow, and what is
*logically* @safe/pure/nothrow. The most obvious example is memory allocation
-- It is technically not pure
On Tuesday, 25 March 2014 at 23:30:28 UTC, Artur Skawina wrote:
It's ok to treat allocator and factory functions as pure,
because those really
are logically pure, ie can't affect any /visible/ state and
return results that
are unique.
Allocators don't return unique results, GC being the
On 03/26/14 15:36, Kagamin wrote:
On Tuesday, 25 March 2014 at 23:30:28 UTC, Artur Skawina wrote:
It's ok to treat allocator and factory functions as pure, because those
really
are logically pure, ie can't affect any /visible/ state and return results
that
are unique.
Allocators don't
On Wed, 26 Mar 2014 10:36:45 -0400, Kagamin s...@here.lot wrote:
On Tuesday, 25 March 2014 at 23:30:28 UTC, Artur Skawina wrote:
It's ok to treat allocator and factory functions as pure, because those
really
are logically pure, ie can't affect any /visible/ state and return
results that
There has been an increased effort as of late to make as much as possible
inside the runtime @safe, pure, and nothrow. The goal is to make it so
it's not as nasty writing such code, because the library will allow it.
Everything that we mark properly down below will allow higher-level
On Tuesday, 25 March 2014 at 13:30:04 UTC, Steven Schveighoffer
wrote:
How can we force these to be weak-pure? One option suggested is
to add a hidden void * parameter that defaults to null, to
force the issue. But I think future compilers may be smart
enough to realize that can also be a
On Tue, 25 Mar 2014 10:08:20 -0400, monarch_dodra monarchdo...@gmail.com
wrote:
On Tuesday, 25 March 2014 at 13:30:04 UTC, Steven Schveighoffer wrote:
How can we force these to be weak-pure? One option suggested is to add
a hidden void * parameter that defaults to null, to force the issue.
On 03/25/14 14:30, Steven Schveighoffer wrote:
[...] functions like GC.setAttr and assumeSafeAppend cannot be marked pure.
For example:
auto str = hello.idup;
str = str[0..1];
str.assumeSafeAppend();
str ~= iya;
The compiler could rationally elide the call to assumeSafeAppend if it is
On 25/03/14 15:08, monarch_dodra wrote:
Maybe instead of using null, we could use global junk?
That really seems like a nasty workaround which could break at any moment
depending on how the compiler is tweaked. :-(
Better surely to have an explicit indication that a function may not be
On Tue, 25 Mar 2014 14:49:27 -0400, Artur Skawina art.08...@gmail.com
wrote:
On 03/25/14 14:30, Steven Schveighoffer wrote:
[...] functions like GC.setAttr and assumeSafeAppend cannot be marked
pure. For example:
auto str = hello.idup;
str = str[0..1];
str.assumeSafeAppend();
str ~= iya;
On 03/25/14 21:51, Steven Schveighoffer wrote:
On Tue, 25 Mar 2014 14:49:27 -0400, Artur Skawina art.08...@gmail.com wrote:
On 03/25/14 14:30, Steven Schveighoffer wrote:
[...] functions like GC.setAttr and assumeSafeAppend cannot be marked pure.
For example:
auto str = hello.idup;
str =
On Tue, 25 Mar 2014 19:30:04 -0400, Artur Skawina art.08...@gmail.com
wrote:
On 03/25/14 21:51, Steven Schveighoffer wrote:
On Tue, 25 Mar 2014 14:49:27 -0400, Artur Skawina art.08...@gmail.com
wrote:
On 03/25/14 14:30, Steven Schveighoffer wrote:
[...] functions like GC.setAttr and
13 matches
Mail list logo
