http://d.puremagic.com/issues/show_bug.cgi?id=8185
Walter Bright changed:
What|Removed |Added
Status|NEW |RESOLVED
CC|
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
https://github.com/D-Programming-Language/d-programming-language.org
http://d.puremagic.com/issues/show_bug.cgi?id=8185
--- Comment #55 from Steven Schveighoffer 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.
> >
> > No, it does
http://d.puremagic.com/issues/show_bug.cgi?id=8185
--- Comment #54 from klickverbot 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; // legal
>... //
http://d.puremagic.com/issues/show_bug.cgi?id=8185
--- Comment #53 from klickverbot 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, the compiler sto
http://d.puremagic.com/issues/show_bug.cgi?id=8185
--- Comment #52 from Steven Schveighoffer 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 'immutable(T)*' is en
http://d.puremagic.com/issues/show_bug.cgi?id=8185
--- Comment #51 from Steven Schveighoffer 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 circumstances_
> > > ac
http://d.puremagic.com/issues/show_bug.cgi?id=8185
--- Comment #50 from Steven Schveighoffer 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 as long as you pla
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 on
http://d.puremagic.com/issues/show_bug.cgi?id=8185
--- Comment #48 from klickverbot 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 pointer target
http://d.puremagic.com/issues/show_bug.cgi?id=8185
--- Comment #47 from Denis Shelomovskij
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 reasonable developer will
http://d.puremagic.com/issues/show_bug.cgi?id=8185
--- Comment #46 from Steven Schveighoffer 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 @trusted function acc
http://d.puremagic.com/issues/show_bug.cgi?id=8185
--- Comment #45 from klickverbot 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 _under no circumstanc
http://d.puremagic.com/issues/show_bug.cgi?id=8185
--- Comment #44 from Steven Schveighoffer 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 compiler/optimizer should tr
http://d.puremagic.com/issues/show_bug.cgi?id=8185
--- Comment #43 from Steven Schveighoffer 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 undefined. I will be
http://d.puremagic.com/issues/show_bug.cgi?id=8185
--- Comment #42 from Denis Shelomovskij
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 the type system. T
http://d.puremagic.com/issues/show_bug.cgi?id=8185
--- Comment #41 from Jonathan M Davis 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 guaranteed to pass as lo
http://d.puremagic.com/issues/show_bug.cgi?id=8185
--- Comment #40 from Denis Shelomovskij
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) pure
> > {
> >i
http://d.puremagic.com/issues/show_bug.cgi?id=8185
--- Comment #39 from klickverbot 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.
--
Configure issuemail: h
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 onl
http://d.puremagic.com/issues/show_bug.cgi?id=8185
--- Comment #37 from klickverbot 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 pure function, it's
http://d.puremagic.com/issues/show_bug.cgi?id=8185
--- Comment #36 from Jonathan M Davis 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);
>assert(res ==
http://d.puremagic.com/issues/show_bug.cgi?id=8185
--- Comment #35 from Denis Shelomovskij
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 way that is expected/d
http://d.puremagic.com/issues/show_bug.cgi?id=8185
--- Comment #34 from Denis Shelomovskij
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 ONLY purpose of weakly
http://d.puremagic.com/issues/show_bug.cgi?id=8185
--- Comment #33 from klickverbot 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 increase the numbe
http://d.puremagic.com/issues/show_bug.cgi?id=8185
Don changed:
What|Removed |Added
CC||clugd...@yahoo.com.au
--- Comment #32 from Don
http://d.puremagic.com/issues/show_bug.cgi?id=8185
--- Comment #31 from klickverbot 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.
I guess I _might
http://d.puremagic.com/issues/show_bug.cgi?id=8185
--- Comment #30 from Jonathan M Davis 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
> issue, at least as s
http://d.puremagic.com/issues/show_bug.cgi?id=8185
--- Comment #28 from Jonathan M Davis 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
--- You are rec
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 poi
http://d.puremagic.com/issues/show_bug.cgi?id=8185
--- Comment #27 from klickverbot 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 same function
> wit
http://d.puremagic.com/issues/show_bug.cgi?id=8185
--- Comment #26 from Jonathan M Davis 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.
Ostensibly, yes. The same ar
http://d.puremagic.com/issues/show_bug.cgi?id=8185
--- Comment #25 from klickverbot 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 in
> > pure funct
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 m
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, ther
http://d.puremagic.com/issues/show_bug.cgi?id=8185
--- Comment #22 from Denis Shelomovskij
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 cheated through casts or the u
http://d.puremagic.com/issues/show_bug.cgi?id=8185
--- Comment #21 from Jonathan M Davis 2012-06-04 01:22:53
PDT ---
???
Why would you be marking a function as pure if it can access global state? The
compiler would flag that unless you cheated through casts or the use of
extern(C) functions w
http://d.puremagic.com/issues/show_bug.cgi?id=8185
--- Comment #20 from Denis Shelomovskij
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 obvious to not be in docs?
http://d.puremagic.com/issues/show_bug.cgi?id=8185
--- Comment #19 from Jonathan M Davis 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
calls to pure function
http://d.puremagic.com/issues/show_bug.cgi?id=8185
--- Comment #18 from Denis Shelomovskij
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 to/may/shouldn't pass
and/or
http://d.puremagic.com/issues/show_bug.cgi?id=8185
--- Comment #17 from Jonathan M Davis 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
conferences. How purity i
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 #15 from Jonathan M Davis 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_.
It means _nothing_ e
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 #13 from timon.g...@gmx.ch 2012-06-03 12:53:36 PDT ---
(In reply to comment #12)
> (In reply to comment #11)
> > Pointers may only access their own memory blocks, therefore exactly those
> > blocks participate in argument value and r
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
timon.g...@gmx.ch changed:
What|Removed |Added
CC||timon.g...@gmx.ch
--- Comment #11 f
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
--- Comment #9 from Denis Shelomovskij 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 conclusion (or
to finally mix everyth
http://d.puremagic.com/issues/show_bug.cgi?id=8185
Jonathan M Davis changed:
What|Removed |Added
CC||jmdavisp...@gmx.com
--- Comment #8
http://d.puremagic.com/issues/show_bug.cgi?id=8185
Steven Schveighoffer changed:
What|Removed |Added
CC||schvei...@yahoo.com
--- 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 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 cast(int)p.
Am I understand
http://d.puremagic.com/issues/show_bug.cgi?id=8185
klickverbot changed:
What|Removed |Added
Severity|enhancement |normal
--- Comment #4 from klickverbot
http://d.puremagic.com/issues/show_bug.cgi?id=8185
--- Comment #3 from Denis Shelomovskij 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 global (mutable) state. A p
http://d.puremagic.com/issues/show_bug.cgi?id=8185
--- Comment #2 from klickverbot 2012-06-02 03:12:04 PDT
---
Also, please note that issue 3057 is really old – I think at that point we
didn't even have the relaxed purity rules yet.
--
Configure issuemail: http://d.puremagic.com/issues/userp
http://d.puremagic.com/issues/show_bug.cgi?id=8185
klickverbot changed:
What|Removed |Added
CC||c...@klickverbot.at
Severity|ma
57 matches
Mail list logo
