On 09/03/2011 13:32, Steven Schveighoffer wrote:
On Tue, 08 Mar 2011 18:33:31 -0500, Bruno Medeiros
brunodomedeiros+spam@com.gmail wrote:
I'm not saying all pointer arithmetic and manipulation should be
illegal. It could be allowed, but only so long as the coder maintains
the contract of the
On 12/03/2011 20:21, Don wrote:
Bruno Medeiros wrote:
On 23/02/2011 17:47, Steven Schveighoffer wrote:
On Wed, 23 Feb 2011 12:28:33 -0500, Andrei Alexandrescu
seewebsiteforem...@erdani.org wrote:
On 2/23/11 11:16 AM, Steven Schveighoffer wrote:
Just because a function is not marked @safe
Sorry for the late reply to this post, the topic is not easy and I am not sure
what the right ideas are:
http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.Darticle_id=130554
Steven Schveighoffer:
@transparent has little value outside a pure function, because the
Do input arguments of pure functions need the @transparent attributes? Is
dropping it ouside the pure subset of the program safe/acceptable? I think so.
Sorry, in my opinion the answers to those questions are no and yes.
Bye,
bearophile
Bruno Medeiros wrote:
On 23/02/2011 17:47, Steven Schveighoffer wrote:
On Wed, 23 Feb 2011 12:28:33 -0500, Andrei Alexandrescu
seewebsiteforem...@erdani.org wrote:
On 2/23/11 11:16 AM, Steven Schveighoffer wrote:
Just because a function is not marked @safe does not mean it is unsafe.
It
On Tue, 08 Mar 2011 18:33:31 -0500, Bruno Medeiros
brunodomedeiros+spam@com.gmail wrote:
I'm not saying all pointer arithmetic and manipulation should be
illegal. It could be allowed, but only so long as the coder maintains
the contract of the pure attribute. So this means that you could
On 23/02/2011 17:47, Steven Schveighoffer wrote:
On Wed, 23 Feb 2011 12:28:33 -0500, Andrei Alexandrescu
seewebsiteforem...@erdani.org wrote:
On 2/23/11 11:16 AM, Steven Schveighoffer wrote:
Just because a function is not marked @safe does not mean it is unsafe.
It just means you can do
On Tue, 08 Mar 2011 14:28:44 -0500, Bruno Medeiros
brunodomedeiros+spam@com.gmail wrote:
On 23/02/2011 17:47, Steven Schveighoffer wrote:
On Wed, 23 Feb 2011 12:28:33 -0500, Andrei Alexandrescu
seewebsiteforem...@erdani.org wrote:
On 2/23/11 11:16 AM, Steven Schveighoffer wrote:
Just
On 08/03/2011 20:17, Steven Schveighoffer wrote:
On Tue, 08 Mar 2011 14:28:44 -0500, Bruno Medeiros
brunodomedeiros+spam@com.gmail wrote:
On 23/02/2011 17:47, Steven Schveighoffer wrote:
On Wed, 23 Feb 2011 12:28:33 -0500, Andrei Alexandrescu
seewebsiteforem...@erdani.org wrote:
On 2/23/11
On Tuesday, March 08, 2011 12:17:02 Steven Schveighoffer wrote:
On Tue, 08 Mar 2011 14:28:44 -0500, Bruno Medeiros
brunodomedeiros+spam@com.gmail wrote:
On 23/02/2011 17:47, Steven Schveighoffer wrote:
On Wed, 23 Feb 2011 12:28:33 -0500, Andrei Alexandrescu
On 24/02/11 14:47, dsimcha wrote:
On 2/22/2011 12:13 AM, Jonathan M Davis wrote:
On Monday 21 February 2011 20:46:56 %u wrote:
Hi,
I'm just curious... why is saying something like this:
extern(C)
private static const pure override final synchronized ~this() { }
allowed?
dmd is pretty lax
On Thu, 24 Feb 2011 19:25:24 -0500, Steven Wawryk stev...@acres.com.au
wrote:
On 24/02/11 14:47, dsimcha wrote:
On 2/22/2011 12:13 AM, Jonathan M Davis wrote:
On Monday 21 February 2011 20:46:56 %u wrote:
Hi,
I'm just curious... why is saying something like this:
extern(C)
private static
On 23/02/2011 01:22, %u wrote:
- private makes no sense since (unless we're trying to imitate C++ here)
destructors are only called from
the runtime, and nowhere else.
- The only meaningful attribute there is extern(C).
In what way is extern(C) meaningful for a destructor?
I guess it
On 2/22/11 3:14 PM, Steven Schveighoffer wrote:
On Tue, 22 Feb 2011 15:48:42 -0500, %u wfunct...@hotmail.com wrote:
D pure functions are significantly different than this definition
(as of recent times, when weak-pure was added).
Essentially, a pure function cannot access global variables.
On Wed, 23 Feb 2011 08:04:49 -0500, Andrei Alexandrescu
seewebsiteforem...@erdani.org wrote:
On 2/22/11 3:14 PM, Steven Schveighoffer wrote:
On Tue, 22 Feb 2011 15:48:42 -0500, %u wfunct...@hotmail.com wrote:
D pure functions are significantly different than this definition
(as of recent
On Tue, 22 Feb 2011 18:19:15 -0500, bearophile bearophileh...@lycos.com
wrote:
Steven Schveighoffer:
I would think malloc and friends should be pure, as well as free. They
can easily simply be marked pure, since they are C bindings.
D even accepts strongly pure functions like:
pure
On 2/23/11 9:00 AM, Steven Schveighoffer wrote:
On Wed, 23 Feb 2011 08:04:49 -0500, Andrei Alexandrescu
seewebsiteforem...@erdani.org wrote:
On 2/22/11 3:14 PM, Steven Schveighoffer wrote:
On Tue, 22 Feb 2011 15:48:42 -0500, %u wfunct...@hotmail.com wrote:
D pure functions are significantly
On Wed, 23 Feb 2011 10:35:26 -0500, Andrei Alexandrescu
seewebsiteforem...@erdani.org wrote:
On 2/23/11 9:00 AM, Steven Schveighoffer wrote:
On Wed, 23 Feb 2011 08:04:49 -0500, Andrei Alexandrescu
seewebsiteforem...@erdani.org wrote:
On 2/22/11 3:14 PM, Steven Schveighoffer wrote:
On Tue,
On 2/23/11 9:42 AM, Steven Schveighoffer wrote:
On Wed, 23 Feb 2011 10:35:26 -0500, Andrei Alexandrescu
seewebsiteforem...@erdani.org wrote:
free(p) affects data remotely outside the pure function.
This is allowed however in the new pure regime:
pure void foo(int *x) {(*x)++;}
int x;
On Wed, 23 Feb 2011 10:46:43 -0500, Andrei Alexandrescu
seewebsiteforem...@erdani.org wrote:
At a level it's clear to me that a function cannot be at the same time
pure and unsafe. For example:
pure void foo(int *x) { free(x); (*x)++; }
This function essentially breaks any guarantee for
I thought @safe was orthogonal to pure? If this isn't the case,
then yes, free must be disallowed. But then malloc must also be,
and any construct which manages its own memory via malloc/free.
From what I remember, pure functions:
1. cannot access shared or global non-immutable data
2.
On Wed, 23 Feb 2011 11:41:52 -0500, %u wfunct...@hotmail.com wrote:
I thought @safe was orthogonal to pure? If this isn't the case,
then yes, free must be disallowed. But then malloc must also be,
and any construct which manages its own memory via malloc/free.
From what I remember, pure
On 2/23/11 9:57 AM, Steven Schveighoffer wrote:
On Wed, 23 Feb 2011 10:46:43 -0500, Andrei Alexandrescu
seewebsiteforem...@erdani.org wrote:
At a level it's clear to me that a function cannot be at the same time
pure and unsafe. For example:
pure void foo(int *x) { free(x); (*x)++; }
This
On Wed, 23 Feb 2011 11:45:48 -0500, Andrei Alexandrescu
seewebsiteforem...@erdani.org wrote:
On 2/23/11 9:57 AM, Steven Schveighoffer wrote:
On Wed, 23 Feb 2011 10:46:43 -0500, Andrei Alexandrescu
seewebsiteforem...@erdani.org wrote:
At a level it's clear to me that a function cannot be at
On 2/23/11 10:52 AM, Steven Schveighoffer wrote:
On Wed, 23 Feb 2011 11:45:48 -0500, Andrei Alexandrescu
seewebsiteforem...@erdani.org wrote:
On 2/23/11 9:57 AM, Steven Schveighoffer wrote:
On Wed, 23 Feb 2011 10:46:43 -0500, Andrei Alexandrescu
seewebsiteforem...@erdani.org wrote:
At a
It seems that you're using the word pure as a synonym for the noalias
and/or restrict __declspec keywords. However, they're different words
because they have
different meanings. :) If you really mean noalias, then I think we just just
call it that and introduce the attribute @noalias?
On 2011-02-23 11:45:48 -0500, Andrei Alexandrescu
seewebsiteforem...@erdani.org said:
On 2/23/11 9:57 AM, Steven Schveighoffer wrote:
On Wed, 23 Feb 2011 10:46:43 -0500, Andrei Alexandrescu
seewebsiteforem...@erdani.org wrote:
At a level it's clear to me that a function cannot be at the
On Wed, 23 Feb 2011 12:01:15 -0500, Andrei Alexandrescu
seewebsiteforem...@erdani.org wrote:
On 2/23/11 10:52 AM, Steven Schveighoffer wrote:
Why? We have both attributes, why not just require @safe pure if you
want @safe pure functions?
Because a pure unsafe function is useless.
Just
Programmers are allowed to make conceptually safe functions which
are not marked as @safe, why not the same for pure functions?
Programmers can always shoot themselves in the foot anyway, if they
really want to. Why not just make it easier for them? :) (We could
allow unsafe casts, for
On 2/23/11 11:16 AM, Steven Schveighoffer wrote:
On Wed, 23 Feb 2011 12:01:15 -0500, Andrei Alexandrescu
seewebsiteforem...@erdani.org wrote:
On 2/23/11 10:52 AM, Steven Schveighoffer wrote:
Why? We have both attributes, why not just require @safe pure if you
want @safe pure functions?
On Wed, 23 Feb 2011 12:28:33 -0500, Andrei Alexandrescu
seewebsiteforem...@erdani.org wrote:
On 2/23/11 11:16 AM, Steven Schveighoffer wrote:
Just because a function is not marked @safe does not mean it is unsafe.
It just means you can do things the compiler cannot verify are safe, but
On 2/23/11 11:47 AM, Steven Schveighoffer wrote:
On Wed, 23 Feb 2011 12:28:33 -0500, Andrei Alexandrescu
seewebsiteforem...@erdani.org wrote:
On 2/23/11 11:16 AM, Steven Schveighoffer wrote:
Just because a function is not marked @safe does not mean it is unsafe.
It just means you can do
On Wed, 23 Feb 2011 12:25:52 -0500, %u wfunct...@hotmail.com wrote:
Programmers are allowed to make conceptually safe functions which
are not marked as @safe, why not the same for pure functions?
Programmers can always shoot themselves in the foot anyway, if they
really want to. Why not just
On 2011-02-23 12:01:15 -0500, Andrei Alexandrescu
seewebsiteforem...@erdani.org said:
Because a pure unsafe function is useless.
I disagree. Suppose you have a function which is conceptually pure but
requires a temporary 100 Mb matrix of doubles. Wouldn't it make sense
to use malloc/free
On 2/22/11 10:36 AM, Simen Kjaeraas wrote:
%u Wrote:
Well, the trouble is, pretty much all of these are invalid attributes:
- static obviously makes no sense
And here is where you're wrong. You have defined a static destructor, which is
called with module destructor as the program goes
Steven Schveighoffer:
cast voids all warranties ;)
OK. But that idea is unchanged if you remove the cast and return an int* from
that function.
Memory allocation has to be allowed inside pure functions. Otherwise,
pure functions are too strict and limited.
I agree. But there are
On Wed, 23 Feb 2011 13:13:35 -0500, bearophile bearophileh...@lycos.com
wrote:
Steven Schveighoffer:
cast voids all warranties ;)
OK. But that idea is unchanged if you remove the cast and return an int*
from that function.
That is allowed, and it's expected that a pure function can
On Wednesday, February 23, 2011 09:17:15 %u wrote:
It seems that you're using the word pure as a synonym for the noalias
and/or restrict __declspec keywords. However, they're different words
because they have
different meanings. :) If you really mean noalias, then I think we just
just
Because a pure unsafe function is useless.
I disagree. Suppose you have a function which is conceptually pure but
requires a temporary 100
Mb matrix of doubles. Wouldn't it make sense to use malloc/free for this
temporary storage
instead of using the GC and risking the block never being
Steven Schveighoffer:
That is allowed, and it's expected that a pure function can return
different references with identical calls.
A pointer and a transparent reference are two different things. That function
returns a pointer, and a pointer is a value.
If you call a pure function with the
No. pure is what we want. Changing it would break code and contradict TDPL
(though the
addition of weakly pure isn't in TDPL). Strongly pure functions are essentially
what you'd
expect from pure. Weakly pure functions aren't, but they're necessary to make
pure very
useful, and there's no real
On Wed, 23 Feb 2011 14:28:01 -0500, %u wfunct...@hotmail.com wrote:
No. pure is what we want. Changing it would break code and contradict
TDPL (though the
addition of weakly pure isn't in TDPL). Strongly pure functions are
essentially what you'd
expect from pure. Weakly pure functions
On Wed, 23 Feb 2011 14:31:35 -0500, bearophile bearophileh...@lycos.com
wrote:
Steven Schveighoffer:
That is allowed, and it's expected that a pure function can return
different references with identical calls.
A pointer and a transparent reference are two different things. That
On 23/02/2011 18:07, Ary Manzana wrote:
On 2/22/11 10:36 AM, Simen Kjaeraas wrote:
%u Wrote:
Well, the trouble is, pretty much all of these are invalid attributes:
- static obviously makes no sense
And here is where you're wrong. You have defined a static destructor, which is
called
with
On Wednesday, February 23, 2011 11:28:01 %u wrote:
No. pure is what we want. Changing it would break code and contradict
TDPL (though the
addition of weakly pure isn't in TDPL). Strongly pure functions are
essentially what you'd expect from pure. Weakly pure functions aren't, but
they're
Steven Schveighoffer:
A pointer is not a value, it's a pointer. int is a value. You should
expect two calls to a pure function to return the same exact int.
I don't care of how you want to define what a pointer is. Definitions are
labels for ideas, you are free to use a different label.
On Wed, 23 Feb 2011 15:28:32 -0500, bearophile bearophileh...@lycos.com
wrote:
Steven Schveighoffer:
I see zero value in disallowing comparing pointers in D.
I have not suggested to disallow comparing all pointers. I have
suggested to disallow it only for pointers/references allocated
Steven Schveighoffer:
That's not what your example showed. It showed comparing two allocated
pointers *outside* a pure function, and expected them to be equal. I see
that as disallowing all pointer comparisons.
My first examples were not so good, I am sorry :-) Thank you for not
On Wed, 23 Feb 2011 16:40:22 -0500, bearophile bearophileh...@lycos.com
wrote:
Steven Schveighoffer:
That's not what your example showed. It showed comparing two allocated
pointers *outside* a pure function, and expected them to be equal. I
see
that as disallowing all pointer
== Quote from Stewart Gordon (smjg_1...@yahoo.com)'s article
On 23/02/2011 18:07, Ary Manzana wrote:
On 2/22/11 10:36 AM, Simen Kjaeraas wrote:
%u Wrote:
Well, the trouble is, pretty much all of these are invalid attributes:
- static obviously makes no sense
And here is where you're
On 2/22/2011 12:13 AM, Jonathan M Davis wrote:
On Monday 21 February 2011 20:46:56 %u wrote:
Hi,
I'm just curious... why is saying something like this:
extern(C)
private static const pure override final synchronized ~this() { }
allowed?
dmd is pretty lax about attributes which don't
== Quote from bearophile (bearophileh...@lycos.com)'s article
...
Currently you are able to write functions like:
pure bool randomPure() {
int[] a1 = new int[1];
int[] a2 = new int[2];
return a1.ptr a2.ptr;
}
Is it possible to fix this by disallowing using the value of a
== Quote from Kevin Bealer (kevindangerbea...@removedanger.gmail.com)'s article
== Quote from bearophile (bearophileh...@lycos.com)'s article
...
Currently you are able to write functions like:
pure bool randomPure() {
int[] a1 = new int[1];
int[] a2 = new int[2];
return
On 2/24/11, Kevin Bealer kevindangerbea...@removedanger.gmail.com wrote:
I wanted to add something I just realized -- malloc is essentially pure if
you can't compare the pointers it returns. Of course if you can't do either
casting or arithmetic on these pointers I'm not sure how to use
%u Wrote:
Well, the trouble is, pretty much all of these are invalid attributes:
- static obviously makes no sense
And here is where you're wrong. You have defined a static destructor, which is
called with module destructor as the program goes out of scope, rather than
when your struct or
On Tue, 22 Feb 2011 01:08:38 -0500, %u wfunct...@hotmail.com wrote:
dmd is pretty lax about attributes which don't apply. It generally just
ignores them. Personally,
I think that it should error on invalid attributes, but for some reason,
that's not how it works.
Of course, there could be
Well, the trouble is, pretty much all of these are invalid
attributes:
- static obviously makes no sense
And here is where you're wrong. You have defined a static
destructor, which is called with module destructor as the program
goes out of scope, rather than when your struct or class is
On 2011-02-22 13:15:03 -0500, %u wfunct...@hotmail.com said:
So okay, fine... 2 out of about 8. That still doesn't mean the rest
of them should be allowed, though... think about how confusing code
with a pure destructor would be.
What's the problem with a pure destructor? It only means you
What's the problem with a pure destructor? It only means you can't access
global variables.
If the object holds a pointer to somewhere, you can still affect that somewhere.
In fact, if your struct's destructor isn't pure, how can you use it as local
variable inside
of a pure function?
The
I just visited Wikipedia (savior of the day) and a quick look at
this article:
http://en.wikipedia.org/wiki/Pure_function
yields the following requirements for a pure function:
1. The function always evaluates the same result value given the
same argument value(s). The function result value
On Tue, 22 Feb 2011 14:31:30 -0500, %u wfunct...@hotmail.com wrote:
I just visited Wikipedia (savior of the day) and a quick look at
this article:
http://en.wikipedia.org/wiki/Pure_function
yields the following requirements for a pure function:
1. The function always evaluates the same result
D pure functions are significantly different than this definition
(as of recent times, when weak-pure was added).
Essentially, a pure function cannot access global variables.
However, it can access variables referred to via a member of the
object instance.
i.e. this is a valid pure function:
On Tue, 22 Feb 2011 15:48:42 -0500, %u wfunct...@hotmail.com wrote:
D pure functions are significantly different than this definition
(as of recent times, when weak-pure was added).
Essentially, a pure function cannot access global variables.
However, it can access variables referred to via
On Tuesday, February 22, 2011 12:48:42 %u wrote:
D pure functions are significantly different than this definition
(as of recent times, when weak-pure was added).
Essentially, a pure function cannot access global variables.
However, it can access variables referred to via a member of
Steven Schveighoffer:
Freeing and allocating memory is fair game for pure functions.
Allocating arrays and objects is possible in pure D functions, despite the
memory pointers they contain (like the ptr of a returned array) are different
across different calls. This makes those function only
On Tue, 22 Feb 2011 16:34:21 -0500, bearophile bearophileh...@lycos.com
wrote:
Steven Schveighoffer:
Freeing and allocating memory is fair game for pure functions.
Allocating arrays and objects is possible in pure D functions, despite
the memory pointers they contain (like the ptr of a
Steven Schveighoffer:
I would think malloc and friends should be pure, as well as free. They
can easily simply be marked pure, since they are C bindings.
D even accepts strongly pure functions like:
pure size_t foo() {
auto a = new ubyte[1];
return cast(size_t)a.ptr;
}
For
This is an idea to patch that hole a little, doing this inside pure functions:
1) Keep disallowing alloca()/malloc()/etc calls;
2) Disallow struct allocations;
3) Keep allowing object and dynamic array allocations;
4) Disallow read and write of the ptr fields of dynamic arrays;
5) Disallow
A safer idea comes from using the type system, but it's hard. The idea is
introducing pure memory references.
I think I have just invented the idea of referentially transparent
pointers/references for D, a subtype of normal D pointers/references.
Bye,
bearophile
On 22/02/2011 06:08, %u wrote:
snip
- synchronized is meaningless since there's only one thread ever running the
destructor anyway
As such, destructors are vacuously synchronized. At least, if you don't have a collision
between threads that try to delete the same object at the same time,
- private makes no sense since (unless we're trying to imitate C++ here)
destructors are only called from
the runtime, and nowhere else.
- The only meaningful attribute there is extern(C).
In what way is extern(C) meaningful for a destructor?
I guess it would be logical to specify that, if
On 2/21/2011 11:46 PM, %u wrote:
Hi,
I'm just curious... why is saying something like this:
extern(C)
private static const pure override final synchronized ~this() { }
allowed?
Thanks!
...And when's the last time you needed one?
On Monday 21 February 2011 20:46:56 %u wrote:
Hi,
I'm just curious... why is saying something like this:
extern(C)
private static const pure override final synchronized ~this() { }
allowed?
dmd is pretty lax about attributes which don't apply. It generally just ignores
them.
dmd is pretty lax about attributes which don't apply. It generally just
ignores them. Personally,
I think that it should error on invalid attributes, but for some reason, that's
not how it works.
Of course, there could be other bugs in play here, but there's every
possibility that the end
74 matches
Mail list logo
