http://d.puremagic.com/issues/show_bug.cgi?id=8185
--- Comment #56 from github-bugzi...@puremagic.com 2012-07-01 23:12:33 PDT ---
Commits pushed to master at
https://github.com/D-Programming-Language/d-programming-language.org
http://d.puremagic.com/issues/show_bug.cgi?id=8185
Walter Bright bugzi...@digitalmars.com changed:
What|Removed |Added
Status|NEW |RESOLVED
http://d.puremagic.com/issues/show_bug.cgi?id=8185
--- Comment #20 from Denis Shelomovskij verylonglogin@gmail.com
2012-06-04 11:54:40 MSD ---
(In reply to comment #19)
I honestly don't understand why much in the way of examples are needed.
OK. I have written some examples. Are they too
http://d.puremagic.com/issues/show_bug.cgi?id=8185
--- Comment #22 from Denis Shelomovskij verylonglogin@gmail.com
2012-06-04 13:07:21 MSD ---
(In reply to comment #21)
Why would you be marking a function as pure if it can access global state? The
compiler would flag that unless you
http://d.puremagic.com/issues/show_bug.cgi?id=8185
--- Comment #23 from timon.g...@gmx.ch 2012-06-04 02:22:54 PDT ---
(In reply to comment #14)
(In reply to comment #13)
(In reply to comment #12)
(In reply to comment #11)
Pointers may only access their own memory blocks, therefore
http://d.puremagic.com/issues/show_bug.cgi?id=8185
--- Comment #24 from timon.g...@gmx.ch 2012-06-04 02:41:16 PDT ---
(In reply to comment #22)
`strlen` is now pure (marked by Andrei Alexandrescu) and it can access global
state once used with non-zero-ended string. I just made situation
http://d.puremagic.com/issues/show_bug.cgi?id=8185
--- Comment #25 from klickverbot c...@klickverbot.at 2012-06-04 03:07:52 PDT
---
I am partly playing Devil's advocate here, but:
(In reply to comment #23)
This is
why i suggested above that only dereferencing a pointer should be allowed
http://d.puremagic.com/issues/show_bug.cgi?id=8185
--- Comment #26 from Jonathan M Davis jmdavisp...@gmx.com 2012-06-04 03:19:22
PDT ---
I'd actually argue that the line Pure functions are functions that produce the
same result for the same arguments should be removed from the spec.
http://d.puremagic.com/issues/show_bug.cgi?id=8185
--- Comment #27 from klickverbot c...@klickverbot.at 2012-06-04 03:38:12 PDT
---
(In reply to comment #26)
While the origin and original motivation for pure in D was to enable
optimizations based on functional purity (multiple calls to the
http://d.puremagic.com/issues/show_bug.cgi?id=8185
--- Comment #29 from timon.g...@gmx.ch 2012-06-04 03:39:52 PDT ---
(In reply to comment #25)
I am partly playing Devil's advocate here, but:
(In reply to comment #23)
This is
why i suggested above that only dereferencing a pointer
http://d.puremagic.com/issues/show_bug.cgi?id=8185
--- Comment #28 from Jonathan M Davis jmdavisp...@gmx.com 2012-06-04 03:39:33
PDT ---
https://github.com/D-Programming-Language/d-programming-language.org/pull/128
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
http://d.puremagic.com/issues/show_bug.cgi?id=8185
--- Comment #30 from Jonathan M Davis jmdavisp...@gmx.com 2012-06-04 03:42:40
PDT ---
I think you've provided a good explanation of the high-level design of the
pure keyword, more than once, but it seems that you are missing that this
http://d.puremagic.com/issues/show_bug.cgi?id=8185
--- Comment #31 from klickverbot c...@klickverbot.at 2012-06-04 06:18:02 PDT
---
(In reply to comment #30)
pure doesn't restrict pointers in any way shape or form. That's an
@safe/@trusted/@system issue, and is completely orthogonal to pure.
http://d.puremagic.com/issues/show_bug.cgi?id=8185
Don clugd...@yahoo.com.au changed:
What|Removed |Added
CC||clugd...@yahoo.com.au
---
http://d.puremagic.com/issues/show_bug.cgi?id=8185
--- Comment #33 from klickverbot c...@klickverbot.at 2012-06-04 06:43:32 PDT
---
(In reply to comment #32)
That's correct. You should not expect *any* optimizations from weakly pure
functions. The ONLY purpose of weakly pure functions is to
http://d.puremagic.com/issues/show_bug.cgi?id=8185
--- Comment #34 from Denis Shelomovskij verylonglogin@gmail.com
2012-06-04 19:08:08 MSD ---
(In reply to comment #33)
(In reply to comment #32)
That's correct. You should not expect *any* optimizations from weakly pure
functions. The
http://d.puremagic.com/issues/show_bug.cgi?id=8185
--- Comment #35 from Denis Shelomovskij verylonglogin@gmail.com
2012-06-04 19:18:33 MSD ---
For Jonathan M Davis: here (as before) when I say optimization I mean
doesn't behave such way that can be optimized which means doesn't behave
such
http://d.puremagic.com/issues/show_bug.cgi?id=8185
--- Comment #36 from Jonathan M Davis jmdavisp...@gmx.com 2012-06-04 08:45:00
PDT ---
int f(size_t) pure;
__gshared int tmp;
void g(size_t, ref int dummy = tmp) pure;
void h(size_t a, size_t b) pure
{
int res = f(a);
g(b);
http://d.puremagic.com/issues/show_bug.cgi?id=8185
--- Comment #37 from klickverbot c...@klickverbot.at 2012-06-04 09:03:18 PDT
---
(In reply to comment #34)
[…] strong unsafe pure functions […]
Please note that @safe-ty of a function has nothing to do with purity. Yes in a
@system/@trusted
http://d.puremagic.com/issues/show_bug.cgi?id=8185
--- Comment #38 from art.08...@gmail.com 2012-06-04 09:08:38 PDT ---
(In reply to comment #23)
(In reply to comment #14)
(In reply to comment #13)
(In reply to comment #12)
(In reply to comment #11)
Pointers may only access their
http://d.puremagic.com/issues/show_bug.cgi?id=8185
--- Comment #39 from klickverbot c...@klickverbot.at 2012-06-04 09:13:14 PDT
---
(In reply to comment #38)
BTW, is my foo() above @safe? According to the compiler here - it is.
If so, please open a new issue – this is clearly a bug.
--
http://d.puremagic.com/issues/show_bug.cgi?id=8185
--- Comment #40 from Denis Shelomovskij verylonglogin@gmail.com
2012-06-04 20:27:24 MSD ---
(In reply to comment #36)
int f(size_t) pure;
__gshared int tmp;
void g(size_t, ref int dummy = tmp) pure;
void h(size_t a, size_t b)
http://d.puremagic.com/issues/show_bug.cgi?id=8185
--- Comment #41 from Jonathan M Davis jmdavisp...@gmx.com 2012-06-04 09:35:33
PDT ---
void g(size_t p, ref size_t) pure
{
++*cast(int*) p;
}
You're casting a size_t to a pointer. That's breaking the type system. The
assertion is
http://d.puremagic.com/issues/show_bug.cgi?id=8185
--- Comment #42 from Denis Shelomovskij verylonglogin@gmail.com
2012-06-04 20:52:56 MSD ---
(In reply to comment #41)
void g(size_t p, ref size_t) pure
{
++*cast(int*) p;
}
You're casting a size_t to a pointer. That's breaking
http://d.puremagic.com/issues/show_bug.cgi?id=8185
--- Comment #43 from Steven Schveighoffer schvei...@yahoo.com 2012-06-04
10:30:19 PDT ---
(In reply to comment #42)
It isn't and here is the point! It's explicitly stated that when I'm casting
away const and than modify date the result is
http://d.puremagic.com/issues/show_bug.cgi?id=8185
--- Comment #44 from Steven Schveighoffer schvei...@yahoo.com 2012-06-04
10:45:33 PDT ---
(In reply to comment #7)
In general response to this bug, I'm unsure how pointers should be treated by
the optimizer. My gut feeling is the
http://d.puremagic.com/issues/show_bug.cgi?id=8185
--- Comment #45 from klickverbot c...@klickverbot.at 2012-06-04 10:51:45 PDT
---
(In reply to comment #44)
Still thinking about the rest of the proposal, but:
[…] or @trusted functions […]
If a @trusted function accepts a pointer, it must
http://d.puremagic.com/issues/show_bug.cgi?id=8185
--- Comment #46 from Steven Schveighoffer schvei...@yahoo.com 2012-06-04
10:59:49 PDT ---
(In reply to comment #45)
(In reply to comment #44)
Still thinking about the rest of the proposal, but:
[…] or @trusted functions […]
If a
http://d.puremagic.com/issues/show_bug.cgi?id=8185
--- Comment #47 from Denis Shelomovskij verylonglogin@gmail.com
2012-06-04 22:13:05 MSD ---
(In reply to comment #43)
The compiler does not assume the worst, it assumes the reasonable, until
you tell it otherwise. In other words, no
http://d.puremagic.com/issues/show_bug.cgi?id=8185
--- Comment #48 from klickverbot c...@klickverbot.at 2012-06-04 11:24:10 PDT
---
(In reply to comment #46)
(In reply to comment #45)
If a @trusted function accepts a pointer, it must _under no circumstances_
access anything except for the
http://d.puremagic.com/issues/show_bug.cgi?id=8185
--- Comment #49 from art.08...@gmail.com 2012-06-04 11:29:39 PDT ---
As this discussions was mostly about what *should* be happening, I decided to
see what actually *is* happening right now.
It seems that the compiler will only optimize based
http://d.puremagic.com/issues/show_bug.cgi?id=8185
--- Comment #50 from Steven Schveighoffer schvei...@yahoo.com 2012-06-04
11:35:27 PDT ---
(In reply to comment #47)
Common! System language must have strict rights. You just have said that D is
JavaScript.
A systems language is very strict
http://d.puremagic.com/issues/show_bug.cgi?id=8185
--- Comment #51 from Steven Schveighoffer schvei...@yahoo.com 2012-06-04
11:48:22 PDT ---
(In reply to comment #48)
(In reply to comment #46)
(In reply to comment #45)
If a @trusted function accepts a pointer, it must _under no
http://d.puremagic.com/issues/show_bug.cgi?id=8185
--- Comment #52 from Steven Schveighoffer schvei...@yahoo.com 2012-06-04
11:51:14 PDT ---
(In reply to comment #49)
It seems that the compiler will only optimize based on pureness if a
function
takes an 'immutable T*' argument, even
http://d.puremagic.com/issues/show_bug.cgi?id=8185
--- Comment #53 from klickverbot c...@klickverbot.at 2012-06-04 12:12:16 PDT
---
(In reply to comment #51)
(In reply to comment #48)
Here, calling gun needs to be safe under _any_ circumstances.
No, it does not. Once you use @trusted,
http://d.puremagic.com/issues/show_bug.cgi?id=8185
--- Comment #54 from klickverbot c...@klickverbot.at 2012-06-04 12:14:40 PDT
---
(In reply to comment #52)
This is a bug, both should be optimized equally:
void foo(immutable int * _param) pure
{
immutable(int)* param = _param; //
http://d.puremagic.com/issues/show_bug.cgi?id=8185
--- Comment #55 from Steven Schveighoffer schvei...@yahoo.com 2012-06-04
13:34:50 PDT ---
(In reply to comment #53)
(In reply to comment #51)
(In reply to comment #48)
Here, calling gun needs to be safe under _any_ circumstances.
http://d.puremagic.com/issues/show_bug.cgi?id=8185
--- Comment #9 from Denis Shelomovskij verylonglogin@gmail.com 2012-06-03
10:23:09 MSD ---
Such a mess! The more people write here the more different opinions I see.
IMHO, Walter and Andrei must also participate here to help with
http://d.puremagic.com/issues/show_bug.cgi?id=8185
--- Comment #10 from art.08...@gmail.com 2012-06-03 06:28:09 PDT ---
(In reply to comment #7)
argument value is all the data reachable via the parameters. Argument result
is all the data reachable via the result.
[...]
the optimizer. My
http://d.puremagic.com/issues/show_bug.cgi?id=8185
timon.g...@gmx.ch changed:
What|Removed |Added
CC||timon.g...@gmx.ch
--- Comment #11
http://d.puremagic.com/issues/show_bug.cgi?id=8185
--- Comment #12 from art.08...@gmail.com 2012-06-03 12:46:28 PDT ---
(In reply to comment #11)
Pointers may only access their own memory blocks, therefore exactly those
blocks participate in argument value and return value.
What does 'their
http://d.puremagic.com/issues/show_bug.cgi?id=8185
--- Comment #14 from art.08...@gmail.com 2012-06-03 13:52:53 PDT ---
(In reply to comment #13)
(In reply to comment #12)
(In reply to comment #11)
Pointers may only access their own memory blocks, therefore exactly those
blocks
http://d.puremagic.com/issues/show_bug.cgi?id=8185
--- Comment #15 from Jonathan M Davis jmdavisp...@gmx.com 2012-06-03 14:40:12
PDT ---
The _only_ thing that the pure attribute means by itself is that that function
cannot directly access any mutable global or static variables. That is _all_.
http://d.puremagic.com/issues/show_bug.cgi?id=8185
--- Comment #16 from art.08...@gmail.com 2012-06-03 15:50:29 PDT ---
(In reply to comment #15)
pure by itself indicates a weakly pure function. That function enables _zero_
Inventing terminology doesn't help, especially when the result is so
http://d.puremagic.com/issues/show_bug.cgi?id=8185
--- Comment #17 from Jonathan M Davis jmdavisp...@gmx.com 2012-06-03 16:02:19
PDT ---
They aren't _my_ definitions. They're official. They've been discussed in the
newsgroup. They've even been used by folks like Walter Bright in talks at
http://d.puremagic.com/issues/show_bug.cgi?id=8185
--- Comment #18 from Denis Shelomovskij verylonglogin@gmail.com
2012-06-04 09:38:21 MSD ---
(In reply to comment #15)
I really don't know how the documentation could be much clearer.
Once it will have examples showing what asserts have
http://d.puremagic.com/issues/show_bug.cgi?id=8185
--- Comment #19 from Jonathan M Davis jmdavisp...@gmx.com 2012-06-03 22:58:33
PDT ---
I honestly don't understand why much in the way of examples are needed. The
documentation explains what pure is. When the compiler is able to optimize out
http://d.puremagic.com/issues/show_bug.cgi?id=8185
klickverbot c...@klickverbot.at changed:
What|Removed |Added
CC||c...@klickverbot.at
http://d.puremagic.com/issues/show_bug.cgi?id=8185
--- Comment #3 from Denis Shelomovskij verylonglogin@gmail.com 2012-06-02
14:29:01 MSD ---
(In reply to comment #1)
The current behavior is by design, and perfectly fine – note that `pure` in D
just means that a function doesn't access
http://d.puremagic.com/issues/show_bug.cgi?id=8185
klickverbot c...@klickverbot.at changed:
What|Removed |Added
Severity|enhancement |normal
--- Comment
http://d.puremagic.com/issues/show_bug.cgi?id=8185
art.08...@gmail.com changed:
What|Removed |Added
CC||art.08...@gmail.com
--- Comment
http://d.puremagic.com/issues/show_bug.cgi?id=8185
--- Comment #6 from Denis Shelomovskij verylonglogin@gmail.com 2012-06-02
19:59:12 MSD ---
(In reply to comment #4)
(In reply to comment #3)
assert(res == f(arr.ptr + 1)); // *p isn't changed
Might fail, f is allowed to return
http://d.puremagic.com/issues/show_bug.cgi?id=8185
Steven Schveighoffer schvei...@yahoo.com changed:
What|Removed |Added
CC|
http://d.puremagic.com/issues/show_bug.cgi?id=8185
Jonathan M Davis jmdavisp...@gmx.com changed:
What|Removed |Added
CC|
54 matches
Mail list logo
