Re: I can't build dsfml2 or derelict.sfml whit dsss
DSFML2 doesn't exist right now. So no doubt you'll have trouble to compile it. I don't know what you are try to achieve, but definitively not what you believe. Note that my answer in the mentionned link give you all you need to use SFML with D. SFML2 is currently on a devellopement stage, so is DSFML2. Considering the current stage of DSFML2, you don't want to use it right now. Le 22/09/2011 06:10, Cuauhtémoc Ledesma a écrit : First at all sorry for my english. I've tried to build any binding of sfml in a 32-bit machine with archlinux. My problem with dsfml2 is similar to this http://www.digitalmars.com/d/archives/digitalmars/D/learn/Buliding_DSFML2_64-bit_Linux_25694.html. After installing mingw32-pthreads (what i don't know if is the correct library) the problem persist and I don't know which library link. But this only happens when i try to compile an individual file with dmd, not with dsss build. After trying to build derelict (using the command dsss net install derelict) to get derelict.sfml, I figured that the problem maybe is dsss, becouse every time I invoke it the output is as if I hadn't written anything after the dsss command, what is not true. I know that there is a derelict2 packages in yaourt, but i get some errors when I try to install it. This is insane , I can't get any binding of this particular library becouse I can't even get that the tools work properly (I also tried in a mac but I get some different errors). So if any one can help me to solve any of this problems I will extremly grateful. Thanks.
Why this simple binaryHeap program does not compile?
import std.container;
class T {
int i;
}
void main() {
auto array = Array!(T);
auto heap = BinaryHeap!(Array!(T), a.i b.i)(array);
}
After compiling:
dmd2/linux/bin32/../../src/phobos/std/container.d(1612): Error:
template std.conv.emplace(T) if (!is(T == class)) does not match any
function template declaration
dmd2/linux/bin32/../../src/phobos/std/container.d(1612): Error:
template std.conv.emplace(T) if (!is(T == class)) cannot deduce
template function from argument types !()(T*,T)
Is this a bug or I use the binary heap wrongly? Thanks a lot!
Re: Conditional Compilation with Version
On 09/22/2011 04:17 AM, alex wrote:
Hi Y'all!! Just as a note, I am new to the news group, but slightly less
new to D =)
Back on topic:
I am unable to get multiple version specifications to work (from the
website)
sometihng like:
version (foo) {
version = bar;
version = baz;
}
version (bar) {
... codes 'n' stuff
}
version (baz) {
... more codez
}
every time I get an error which says rhe version statement wants
(statement), not '=', unlike from the website article on language
is this simply a deprecated feature, or am I doing something wrong?
pssst... I use DMD 2.055 on linux x86 (ubuntu, dont be a hater)
Probably, the problem is that you try to set versions in function scope.
That does not work, version=foo; declarations must be at module scope.
Re: I can't build dsfml2 or derelict.sfml whit dsss
DSFML2's dsss file is just a remnant from the old DSFML. Also I don't really update DSFML2 anymore. A SWIG wrapper would be a better idea but it's hard to make it use our custom system module instead of wrapping the original one. In general using dsss isn't advisable, since rebuild is horribly outdated.
Re: I can't build dsfml2 or derelict.sfml whit dsss
On 9/22/2011 1:10 PM, Cuauhtémoc Ledesma wrote: First at all sorry for my english. After trying to build derelict (using the command dsss net install derelict) to get derelict.sfml, I figured that the problem maybe is dsss, becouse every time I invoke it the output is as if I hadn't written anything after the dsss command, what is not true. I know that there is a derelict2 packages in yaourt, but i get some errors when I try to install it. Yes, the problem is with DSSS, which is no longer maintained. The net install has been broken for a long, long time. I suggest you use the Derelict makefiles to build. Although the documentation is currently incomplete, all of the info you need to build Derelict is there. However, DerelictSFML does not bind to SFML 2, only 1.x.
Re: Dynamic Array Question
On Wed, 21 Sep 2011 00:09:08 -0400, Jesse Phillips jessekphillip...@gmail.com wrote: On Tue, 20 Sep 2011 14:28:54 -0400, Steven Schveighoffer wrote: You can deallocate the original array. The soon-to-be-deprecated method Note: ^ :) (but easiest) is: delete t; To avoid having to change your other code, I'd do this: wchar[] t = ...; scope(exit) delete t; // add this line to the end of the function (after returning) Unless I missed something, delete is being removed from the language. -Steve
Re: Is this a bug in execvp of std.process
On Wed, 21 Sep 2011 00:30:11 -0400, Cheng Wei riverch...@gmail.com wrote:
#import std.process
void main() {
execvp(ip, route);
}
result:
Object ute is unknown, try ip help.
That is the first two bytes are lost
Adding two spaces works:
#import std.process
void main() {
execvp(ip, route);
}
Version 2.055, linux, 32bit
Thanks.
Definitely a bug, but likely one that will not be fixed. std.process has
been rewritten, and the result is waiting for a change to the Windows C
runtime (dmc) for supporting pipes.
However, you are on Linux, so you can probably use the updated std.process
see here:
https://github.com/kyllingstad/phobos/tree/new-std-process
You will likely have to do some git cloning to get these into the latest
phobos.
-Steve
Wrong const attribute?
Hi all,
I've found nothing on bugzilla for that, what I'm missing? Or it's a bug? (DMD
2.055)
struct Bar {
immutable int i;
this(int j){ i = j; }
}
struct Foo {
Bar bar;
}
void main(){
auto b = Bar(1);
auto f = Foo();
f.bar = Bar(2); // Error: can only initialize const member bar inside
constructor
}
Cheers,
Paolo Invernizzi
Re: Wrong const attribute?
On Thursday, September 22, 2011 04:12 Paolo Invernizzi wrote:
Hi all,
I've found nothing on bugzilla for that, what I'm missing? Or it's a bug?
(DMD 2.055)
struct Bar {
immutable int i;
this(int j){ i = j; }
}
struct Foo {
Bar bar;
}
void main(){
auto b = Bar(1);
auto f = Foo();
f.bar = Bar(2); // Error: can only initialize const member bar inside
constructor
}
The error is a bit confusing but essentially correct. Bar has an immutable
member variable. Once it's been initialized, that immutable member variable
can never be changed, so you can never assign to a variable of type Bar.
Naturally, that includes the member variable in Foo. So, when you constructed
your f variable, the bar member variable was initialized, and after that, it
can never be assigned to. So, when you try and do it, you get an error. The
error message could definitely use some improvement though.
- Jonathan M Davis
Re: Why this simple binaryHeap program does not compile?
On 09/22/2011 06:10 AM, Cheng Wei wrote: Is this a bug or I use the binary heap wrongly? Thanks a lot! Looks like a bug in Array. emplace doesn't accept a pointer to a chunk for class types. Report that puppy!
Re: Why this simple binaryHeap program does not compile?
On 9/22/11 7:20 PM, Ellery Newcomer wrote: Looks like a bug in Array. emplace doesn't accept a pointer to a chunk for class types. Report that puppy! See https://github.com/D-Programming-Language/phobos/commit/65a0c2158b1d2ea8e9d3094746739da636266089. David
Using pure to create immutable
The discussion on Reddit brought to my attention that pure functions can return
and assign to an immutable.
http://www.reddit.com/r/programming/comments/knn5p/thoughts_on_immutability_in_d/c2lsgek
I am trying to modify the example request to make use of this, but have failed.
http://www.reddit.com/r/programming/comments/knn5p/thoughts_on_immutability_in_d/c2lrfpm
test.d(4): Error: cannot implicitly convert expression (makeFromArray([1,2,3]))
of type test.List!(int).List to immutable(List)
Is this a bug? I can't identify where this issue would lie (works with
inheritance and templating).
void main() {
immutable a = makeFromArray([1,2,3]);
}
private abstract class List(T) {
abstract bool isEmpty () const;
abstract T head () const;
abstract const(List!T) tail () const;
}
private final class Cons(T): List!T {
immutable T head_;
Cons!T tail_; // not immutable here for a reason
this(T h, Cons!T t) { head_ = h; tail_ = t; }
override bool isEmpty() const { return false; }
override T head () const { return head_; }
override const(Cons!T) tail () const { return tail_; }
}
List!T makeFromArray(T)(T[] array) pure {
if (array.length == 0) { return null; }
auto result = new Cons!T(array[0], null);
auto end = result;
for (int i = 1; i array.length; ++i) {
end.tail_ = new Cons!T(array[i], null);
end = end.tail_;
}
return result;
}
Re: Heap fucntion calls
On Thu, 22 Sep 2011 00:43:09 +0200, deadalnix deadal...@gmail.com wrote:
Great answer ! Thank you very much, it answered almost everything !
But what about, in the exemple you gave me (which is great by the way)
if foo as parameters ? Those parameters are passed on the stack by copy
to the function, and then, copied to the heap (resulting in two copies) ?
Oui. In that case:
void foo(int n, ref int i) { // Adding in a ref, for good measure.
n = 2;
int x = 5;
auto dg = () {x = 4; n = 3; i = 2;};
dg();
}
becomes:
typedef struct foo_dg_1_delegate {
void (*funcptr)(struct foo_dg_1_context*);
void* ptr;
};
typedef struct foo_dg_1_context {
int x;
int n;
int* i;
};
void foo_dg_1(struct foo_dg_1_context* ctx) {
ctx-x = 4;
ctx-n = 3;
*ctx-i = 2;
}
void foo(int n, int* i) {
struct foo_dg_1_delegate dg;
struct foo_dg_1_context* ctx = (struct
foo_dg_1_context*)malloc(sizeof(struct foo_dg_1_context));
dg.funcptr = foo_dg_1;
dg.ptr = ctx;
ctx-x = 5;
ctx-n = n; // Unnecessary initialization, but conceptually happens.
ctx-i = i;
ctx-n = 2;
dg.funcptr(dg.ptr);
}
--
Simen
Re: Using pure to create immutable
On 22.09.2011 22:53, Jesse Phillips wrote:
The discussion on Reddit brought to my attention that pure functions can return
and assign to an immutable.
http://www.reddit.com/r/programming/comments/knn5p/thoughts_on_immutability_in_d/c2lsgek
I am trying to modify the example request to make use of this, but have failed.
http://www.reddit.com/r/programming/comments/knn5p/thoughts_on_immutability_in_d/c2lrfpm
test.d(4): Error: cannot implicitly convert expression (makeFromArray([1,2,3]))
of type test.List!(int).List to immutable(List)
Is this a bug? I can't identify where this issue would lie (works with
inheritance and templating).
Maybe:
-
List!T makeFromArray(T)(immutable T[] array) pure {
if (array.length == 0) { return null; }
auto result = new Cons!T(array[0], null);
auto end = result;
for (int i = 1; i array.length; ++i) {
end.tail_ = new Cons!T(array[i], null);
end = end.tail_;
}
return result;
}
If I'm not mistaken only strongly pure functions are working.
--
Dmitry Olshansky
Re: Using pure to create immutable
On Thursday, September 22, 2011 23:36:40 Dmitry Olshansky wrote:
On 22.09.2011 22:53, Jesse Phillips wrote:
The discussion on Reddit brought to my attention that pure functions can
return and assign to an immutable.
http://www.reddit.com/r/programming/comments/knn5p/thoughts_on_immutabil
ity_in_d/c2lsgek
I am trying to modify the example request to make use of this, but have
failed.
http://www.reddit.com/r/programming/comments/knn5p/thoughts_on_immutabil
ity_in_d/c2lrfpm
test.d(4): Error: cannot implicitly convert expression
(makeFromArray([1,2,3])) of type test.List!(int).List to
immutable(List)
Is this a bug? I can't identify where this issue would lie (works with
inheritance and templating).
Maybe:
-
List!T makeFromArray(T)(immutable T[] array) pure {
if (array.length == 0) { return null; }
auto result = new Cons!T(array[0], null);
auto end = result;
for (int i = 1; i array.length; ++i) {
end.tail_ = new Cons!T(array[i], null);
end = end.tail_;
}
return result;
}
If I'm not mistaken only strongly pure functions are working.h
Which would make sense. The only reason that it can implicitly cast to
immutable is because it _knows_ that there are no other mutable references to
that data, and for it to be able to know that, the function must be strongly
pure.
- Jonathan M Davis
Templated ctors can't call each other?
import std.typetuple;
import std.traits;
struct Foo
{
this(T1, T2)(T1 x, T2 y) if (allSatisfy!(isIntegral, T1, T2))
{
this.x = x;
this.y = y;
}
this(P)(P point) // ..constraints needed of course
{
this(point.x, point.y);
}
int x, y;
}
struct Point { int x, y; }
void main()
{
auto foo = Foo(Point(1, 2));
}
test.d(14): Error: constructor call must be in a constructor
test.d(24): Error: template instance test.Foo.__ctor!(Point) error instantiating
It's only an issue with code reusability though. I could easily
populate the fields inside the ctor that takes a Point without calling
other ctors. Or I could create a special ctor() function and call
that from the templated ctors, e.g.:
struct Foo
{
void ctor(T1, T2)(T1 x, T2 y) if (allSatisfy!(isIntegral, T1, T2))
{
this.x = x;
this.y = y;
}
this(T1, T2)(T1 x, T2 y) if (allSatisfy!(isIntegral, T1, T2))
{
ctor(x, y);
}
this(P)(P point) // ..constraints
{
ctor(x, y);
}
int x, y;
}
struct Point { int x, y; }
void main()
{
auto foo = Foo(Point(1, 2));
}
So is the original code a rejects-valid bug or is this by design?
Re: Using pure to create immutable
On Thu, 22 Sep 2011 15:44:21 -0400, Jonathan M Davis jmdavisp...@gmx.com
wrote:
On Thursday, September 22, 2011 23:36:40 Dmitry Olshansky wrote:
On 22.09.2011 22:53, Jesse Phillips wrote:
The discussion on Reddit brought to my attention that pure functions
can
return and assign to an immutable.
http://www.reddit.com/r/programming/comments/knn5p/thoughts_on_immutabil
ity_in_d/c2lsgek
I am trying to modify the example request to make use of this, but
have
failed.
http://www.reddit.com/r/programming/comments/knn5p/thoughts_on_immutabil
ity_in_d/c2lrfpm
test.d(4): Error: cannot implicitly convert expression
(makeFromArray([1,2,3])) of type test.List!(int).List to
immutable(List)
Is this a bug? I can't identify where this issue would lie (works with
inheritance and templating).
Maybe:
-
List!T makeFromArray(T)(immutable T[] array) pure {
if (array.length == 0) { return null; }
auto result = new Cons!T(array[0], null);
auto end = result;
for (int i = 1; i array.length; ++i) {
end.tail_ = new Cons!T(array[i], null);
end = end.tail_;
}
return result;
}
If I'm not mistaken only strongly pure functions are working.h
Which would make sense. The only reason that it can implicitly cast to
immutable is because it _knows_ that there are no other mutable
references to
that data, and for it to be able to know that, the function must be
strongly
pure.
Technically, something like this could be cast to immutable:
T[] foo(const(T)[] arg) pure
Since it can be proven that the result is new data.
So it doesn't *need* to be strong-pure.
-Steve
Re: Using pure to create immutable
On Thu, 22 Sep 2011 16:09:29 -0400, Steven Schveighoffer
schvei...@yahoo.com wrote:
On Thu, 22 Sep 2011 15:44:21 -0400, Jonathan M Davis
jmdavisp...@gmx.com wrote:
On Thursday, September 22, 2011 23:36:40 Dmitry Olshansky wrote:
On 22.09.2011 22:53, Jesse Phillips wrote:
The discussion on Reddit brought to my attention that pure functions
can
return and assign to an immutable.
http://www.reddit.com/r/programming/comments/knn5p/thoughts_on_immutabil
ity_in_d/c2lsgek
I am trying to modify the example request to make use of this, but
have
failed.
http://www.reddit.com/r/programming/comments/knn5p/thoughts_on_immutabil
ity_in_d/c2lrfpm
test.d(4): Error: cannot implicitly convert expression
(makeFromArray([1,2,3])) of type test.List!(int).List to
immutable(List)
Is this a bug? I can't identify where this issue would lie (works
with
inheritance and templating).
Maybe:
-
List!T makeFromArray(T)(immutable T[] array) pure {
if (array.length == 0) { return null; }
auto result = new Cons!T(array[0], null);
auto end = result;
for (int i = 1; i array.length; ++i) {
end.tail_ = new Cons!T(array[i], null);
end = end.tail_;
}
return result;
}
If I'm not mistaken only strongly pure functions are working.h
Which would make sense. The only reason that it can implicitly cast to
immutable is because it _knows_ that there are no other mutable
references to
that data, and for it to be able to know that, the function must be
strongly
pure.
Technically, something like this could be cast to immutable:
T[] foo(const(T)[] arg) pure
Since it can be proven that the result is new data.
So it doesn't *need* to be strong-pure.
And actually, just making the argument immutable doesn't make it
strong-pure, the result has to be too.
So I don't think it has to do with strong-purity at all.
-Steve
Re: Using pure to create immutable
On Thursday, September 22, 2011 16:09:29 Steven Schveighoffer wrote:
On Thu, 22 Sep 2011 15:44:21 -0400, Jonathan M Davis jmdavisp...@gmx.com
wrote:
On Thursday, September 22, 2011 23:36:40 Dmitry Olshansky wrote:
On 22.09.2011 22:53, Jesse Phillips wrote:
The discussion on Reddit brought to my attention that pure
functions
can
return and assign to an immutable.
http://www.reddit.com/r/programming/comments/knn5p/thoughts_on_immutab
il
ity_in_d/c2lsgek
I am trying to modify the example request to make use of this, but
have
failed.
http://www.reddit.com/r/programming/comments/knn5p/thoughts_on_immutab
il
ity_in_d/c2lrfpm
test.d(4): Error: cannot implicitly convert expression
(makeFromArray([1,2,3])) of type test.List!(int).List to
immutable(List)
Is this a bug? I can't identify where this issue would lie (works
with
inheritance and templating).
Maybe:
-
List!T makeFromArray(T)(immutable T[] array) pure {
if (array.length == 0) { return null; }
auto result = new Cons!T(array[0], null);
auto end = result;
for (int i = 1; i array.length; ++i) {
end.tail_ = new Cons!T(array[i], null);
end = end.tail_;
}
return result;
}
If I'm not mistaken only strongly pure functions are working.h
Which would make sense. The only reason that it can implicitly cast to
immutable is because it _knows_ that there are no other mutable
references to
that data, and for it to be able to know that, the function must be
strongly
pure.
Technically, something like this could be cast to immutable:
T[] foo(const(T)[] arg) pure
Since it can be proven that the result is new data.
So it doesn't *need* to be strong-pure.
Yes, you can always cast to immutable, but unless the compiler can _prove_
that the return value can be safely cast to immutable, it won't do it
implicitly, and the function needs to be strongly pure to do that.
Now, if the compiler were improved to consider that function strongly pure
when it's passed an immutable argument, then it would work in that case, but
until that happens, it can't do that, and even then, it would only work if the
argument passed to it were immutable rather than mutable or const.
- Jonathan M Davis
Re: Using pure to create immutable
On Thursday, September 22, 2011 16:11:05 Steven Schveighoffer wrote:
On Thu, 22 Sep 2011 16:09:29 -0400, Steven Schveighoffer
schvei...@yahoo.com wrote:
On Thu, 22 Sep 2011 15:44:21 -0400, Jonathan M Davis
jmdavisp...@gmx.com wrote:
On Thursday, September 22, 2011 23:36:40 Dmitry Olshansky wrote:
On 22.09.2011 22:53, Jesse Phillips wrote:
The discussion on Reddit brought to my attention that pure
functions
can
return and assign to an immutable.
http://www.reddit.com/r/programming/comments/knn5p/thoughts_on_immut
abil
ity_in_d/c2lsgek
I am trying to modify the example request to make use of this,
but
have
failed.
http://www.reddit.com/r/programming/comments/knn5p/thoughts_on_immut
abil
ity_in_d/c2lrfpm
test.d(4): Error: cannot implicitly convert expression
(makeFromArray([1,2,3])) of type test.List!(int).List to
immutable(List)
Is this a bug? I can't identify where this issue would lie
(works
with
inheritance and templating).
Maybe:
-
List!T makeFromArray(T)(immutable T[] array) pure {
if (array.length == 0) { return null; }
auto result = new Cons!T(array[0], null);
auto end = result;
for (int i = 1; i array.length; ++i) {
end.tail_ = new Cons!T(array[i], null);
end = end.tail_;
}
return result;
}
If I'm not mistaken only strongly pure functions are working.h
Which would make sense. The only reason that it can implicitly cast to
immutable is because it _knows_ that there are no other mutable
references to
that data, and for it to be able to know that, the function must be
strongly
pure.
Technically, something like this could be cast to immutable:
T[] foo(const(T)[] arg) pure
Since it can be proven that the result is new data.
So it doesn't *need* to be strong-pure.
And actually, just making the argument immutable doesn't make it
strong-pure, the result has to be too.
So I don't think it has to do with strong-purity at all.
??? Functions are pure, not variables or return values. The entire reason that
the compiler can implicitly cast the return value to immutable is because it
_knows_ that there are no mutable references to that data, and it can only
make that guarantee if the function is strongly pure. So, if a function is
strongly pure, the implicit cast to immutable can be made, and if it's not,
then it can't be.
For a function to be strongly pure, it cannot access any globally mutable
state, all functions that it calls must be pure, and all of its parameters
must either be immutable or implicitly convertible to immutable (so that the
complire can guarantee that they'll never change). So, it's guaranteed that
the return value of a strongly pure function is either immutable or it was
allocated within that strongly pure function (or within a function that it
called) and that there are no other references to that data, so then it's
guaranteed that the return value can be safely cast to immutable. const
doesn't enter into it (unless the compiler is improved to consider a pure
function with const parameters strongly pure when it's passed immutable
arguments), and there is no concept of the return value being pure or not. So,
I'm not quite sure what you're thinking here.
- Jonathan M Davis
Re: Using pure to create immutable
On Thu, 22 Sep 2011 16:15:20 -0400, Jonathan M Davis jmdavisp...@gmx.com
wrote:
On Thursday, September 22, 2011 16:09:29 Steven Schveighoffer wrote:
Technically, something like this could be cast to immutable:
T[] foo(const(T)[] arg) pure
Since it can be proven that the result is new data.
So it doesn't *need* to be strong-pure.
Yes, you can always cast to immutable
I meant implicitly cast, sorry. I should be able to do this:
T[] foo(const(T)[] arg) pure {...}
immutable x = foo(y);
but unless the compiler can _prove_
that the return value can be safely cast to immutable, it won't do it
implicitly, and the function needs to be strongly pure to do that.
It doesn't. In fact, the result of a strongly-pure function *cannot* be
cast away from immutable implicitly:
immutable(int)[] strongpure(immutable(int)[] arg) pure { return arg[0..5];}
immutable(int)[] y = [1,2,3,4,5,6,7,8,9];
int[] x = strongpure(y); // error!
This function is not strong pure:
int[] weakpure(immutable(int)[] arg) pure {...}
because it cannot be optimized away. Subsequent calls to weakpure do
*not* return the same value, each one returns a new piece of data.
Yet because we know it returns a new piece of data, the result should be
implicitly castable to immutable:
immutable(int)[] y = [1,2,3,4,5,6,7,8,9];
immutable(int)[] x = weakpure(y); // should be fine
-Steve
Re: Using pure to create immutable
On Thu, 22 Sep 2011 16:23:12 -0400, Jonathan M Davis jmdavisp...@gmx.com
wrote:
On Thursday, September 22, 2011 16:11:05 Steven Schveighoffer wrote:
On Thu, 22 Sep 2011 16:09:29 -0400, Steven Schveighoffer
schvei...@yahoo.com wrote:
On Thu, 22 Sep 2011 15:44:21 -0400, Jonathan M Davis
jmdavisp...@gmx.com wrote:
On Thursday, September 22, 2011 23:36:40 Dmitry Olshansky wrote:
On 22.09.2011 22:53, Jesse Phillips wrote:
The discussion on Reddit brought to my attention that pure
functions
can
return and assign to an immutable.
http://www.reddit.com/r/programming/comments/knn5p/thoughts_on_immut
abil
ity_in_d/c2lsgek
I am trying to modify the example request to make use of this,
but
have
failed.
http://www.reddit.com/r/programming/comments/knn5p/thoughts_on_immut
abil
ity_in_d/c2lrfpm
test.d(4): Error: cannot implicitly convert expression
(makeFromArray([1,2,3])) of type test.List!(int).List to
immutable(List)
Is this a bug? I can't identify where this issue would lie
(works
with
inheritance and templating).
Maybe:
-
List!T makeFromArray(T)(immutable T[] array) pure {
if (array.length == 0) { return null; }
auto result = new Cons!T(array[0], null);
auto end = result;
for (int i = 1; i array.length; ++i) {
end.tail_ = new Cons!T(array[i], null);
end = end.tail_;
}
return result;
}
If I'm not mistaken only strongly pure functions are working.h
Which would make sense. The only reason that it can implicitly cast
to
immutable is because it _knows_ that there are no other mutable
references to
that data, and for it to be able to know that, the function must be
strongly
pure.
Technically, something like this could be cast to immutable:
T[] foo(const(T)[] arg) pure
Since it can be proven that the result is new data.
So it doesn't *need* to be strong-pure.
And actually, just making the argument immutable doesn't make it
strong-pure, the result has to be too.
So I don't think it has to do with strong-purity at all.
??? Functions are pure, not variables or return values. The entire
reason that
the compiler can implicitly cast the return value to immutable is
because it
_knows_ that there are no mutable references to that data, and it can
only
make that guarantee if the function is strongly pure. So, if a function
is
strongly pure, the implicit cast to immutable can be made, and if it's
not,
then it can't be.
For a function to be strongly pure, it cannot access any globally mutable
state, all functions that it calls must be pure, and all of its
parameters
must either be immutable or implicitly convertible to immutable (so that
the
complire can guarantee that they'll never change).
The definition of strong-pure is a pure function where pure optimizations
can be made. In order for that to work, The return value must also be
immutable or implicitly castable to immutable.
Consider:
char[] foo(string s) pure { return s.dup;} // strong pure?
auto x = foo(hello);
auto y = foo(hello);
If foo was considered strong-pure, then couldn't the compiler rewrite the
second line to be auto y = x ? But let's mess it up:
auto x = foo(hello);
x[0] = 'm';
auto y = foo(hello);
The compiler *must* call both foo calls, it can't optimize any away.
Contrast this with a true strong-pure function which returns string, the
compiler *can* safely remove the second call.
This is different from a pure function where it's guaranteed the result
is new data. That is the condition for which you should be allowed to
implicitly cast. Uniqueness is the property we are looking for, and the
only way to guarantee it is with a pure function that returns a type that
cannot be a subset of any parameter.
-Steve
Re: Using pure to create immutable
On Thursday, September 22, 2011 13:25 Steven Schveighoffer wrote:
On Thu, 22 Sep 2011 16:15:20 -0400, Jonathan M Davis jmdavisp...@gmx.com
wrote:
On Thursday, September 22, 2011 16:09:29 Steven Schveighoffer wrote:
Technically, something like this could be cast to immutable:
T[] foo(const(T)[] arg) pure
Since it can be proven that the result is new data.
So it doesn't *need* to be strong-pure.
Yes, you can always cast to immutable
I meant implicitly cast, sorry. I should be able to do this:
T[] foo(const(T)[] arg) pure {...}
immutable x = foo(y);
but unless the compiler can _prove_
that the return value can be safely cast to immutable, it won't do it
implicitly, and the function needs to be strongly pure to do that.
It doesn't. In fact, the result of a strongly-pure function *cannot* be
cast away from immutable implicitly:
Casting away immutability was never the issue. I don't believe that that can
_ever_ be done implicitly, regardless of purity. It's casting _to_ immutable
that's the issue.
immutable(int)[] strongpure(immutable(int)[] arg) pure { return arg[0..5];}
immutable(int)[] y = [1,2,3,4,5,6,7,8,9];
int[] x = strongpure(y); // error!
This function is not strong pure:
int[] weakpure(immutable(int)[] arg) pure {...}
because it cannot be optimized away. Subsequent calls to weakpure do
*not* return the same value, each one returns a new piece of data.
Yet because we know it returns a new piece of data, the result should be
implicitly castable to immutable:
immutable(int)[] y = [1,2,3,4,5,6,7,8,9];
immutable(int)[] x = weakpure(y); // should be fine
Okay. I think that the problem here is that everything that I've been saying
has everything to do with the parameters and arguments and _nothing_ to do
with the return value. You make a valid point in your other post that a
function returning a mutable value can't be considered strongly pure. However,
if you ignore the return value in what I was saying about strongly pure
before, everything holds for being able to implicitly cast to immutable. The
issue is that a function which returns a mutable value can't quite be strongly
pure, which I misjudged, so terming them strongly pure as I was is incorrect.
However, I would point out that a function which returns a const value can
still be strongly pure as long as all of its parameters are all immutable or
implicitly convertible to immutable, since then the compiler can guarantee
that the return value can't be changed without subverting the type system.
In any case, in order for a function to be able to have its return value
implicitly value implicitly cast to immutable, it must pure and all of its
arguments must be immutable or implicitly convertible to immutable (or - if
the compiler is ever improved to treat pure functions with const parameters
and immutable arguments the same way - the requirement would be that the
function must be pure and all of its _arguments_ must be immutable or
implicitly convertible to immutable). So, we have a new distinguish to make
with regards to purity - whether the return value can be implicitly cast to
immutable or not - and we don't have a name for that. And unlike strong purity
vs weak purity, programmers actually have to understand the distinction if
they're going to take advantage of it.
- Jonathan M Davis
Re: Using pure to create immutable
On Thursday, September 22, 2011 14:03 Jonathan M Davis wrote: In any case, in order for a function to be able to have its return value implicitly value implicitly cast to immutable, it must pure and all of its arguments must be immutable[...] Ouch! I really must reread my posts more before posting. That's understandable but pretty bad. :( I guess that I'm frequently in too much of a hurry when posting. - Jonathan M Davis
Re: Using pure to create immutable
On Thursday, September 22, 2011 14:10 Steven Schveighoffer wrote:
On Thu, 22 Sep 2011 17:03:08 -0400, Jonathan M Davis jmdavisp...@gmx.com
wrote:
In any case, in order for a function to be able to have its return value
implicitly value implicitly cast to immutable, it must pure and all of
its
arguments must be immutable or implicitly convertible to immutable (or -
if
the compiler is ever improved to treat pure functions with const
parameters
and immutable arguments the same way - the requirement would be that the
function must be pure and all of its _arguments_ must be immutable or
implicitly convertible to immutable).
No, the parameter types can be const, and can accept mutable arguments.
The main point is, the return value has to be proven to be *unique*. The
only way to do this with pure functions is to prove that the result is
*not* a subset of the parameters. That's all.
Observe:
char[] foo(const(char)[] x) pure {...}
There is no way to write the body of this function such that the return
value is a substring of x. So you are guaranteed that the result is *new
memory*, and since it cannot be stored globally anywhere (per pure rules),
it's guaranteed to be unique, and should be implicitly castable to
immutable.
Even if you pass a char[] into foo.
H. You're right. Bleh. This is overly complicated. It works, but sorting
it out is a pain. And trying to explain to newbies why and when a function can
have its return value implicitly converted to immutable... Well, it's going to
be an issue - just like with strong purity, but in that case at least, we can
pretty much just let the compiler optimize where it's going to optimize and
not generally worry about what's strong or weakly pure unless you're really
trying to optimize code. In this case, however, programmers are going to need
to understand in order to use it properly.
- Jonathan M Davis
allSatisfy could use some constraints
import std.string;
import std.traits;
import std.typetuple;
void main()
{
if (allSatisfy!(isNumeric, int, short))
{
}
}
D:\DMD\dmd2\windows\bin\..\..\src\phobos\std\typetuple.d(576): Error:
template instance F is not a template declaration, it is a overloadset
This took a good while to figure out what went wrong. std.traits
defines isNumeric, but std.string defines it too. allSatisfy takes an
alias type parameter with no constraints, so maybe some constraints
could be added so it doesn't get instantiated with regular functions
but only template functions?
Re: Using pure to create immutable
Dmitry Olshansky Wrote:
Maybe:
-
List!T makeFromArray(T)(immutable T[] array) pure {
--
Dmitry Olshansky
Thank you this lets it compile. I think I had that somewhere, but forgot about
it. As Steve mentions, it probably should also work for const arguments too.
Re: Using pure to create immutable
Jesse Phillips: Thank you this lets it compile. I think I had that somewhere, but forgot about it. As Steve mentions, it probably should also work for const arguments too. If you are convinced of this, then I suggest you to add an enhancement request in Phobos about it. It will make purity more and more useful. Bye, bearophile
Re: allSatisfy could use some constraints
On Thursday, September 22, 2011 15:36 Andrej Mitrovic wrote:
import std.string;
import std.traits;
import std.typetuple;
void main()
{
if (allSatisfy!(isNumeric, int, short))
{
}
}
D:\DMD\dmd2\windows\bin\..\..\src\phobos\std\typetuple.d(576): Error:
template instance F is not a template declaration, it is a overloadset
This took a good while to figure out what went wrong. std.traits
defines isNumeric, but std.string defines it too. allSatisfy takes an
alias type parameter with no constraints, so maybe some constraints
could be added so it doesn't get instantiated with regular functions
but only template functions?
Well, the simple solution is to just pass it std.traits.isNumeric. As annoying
as it may be at times, conflicting functions is something that can happen in D
and has been planned for, so there are simple ways around the problem.
However, if you're absolutely certain that it doesn't make sense for
allSatisfy to work with a function as opposed to an eponymous template (and
I'm not at all certain that that's true), then you can open an enhancement
request.
- Jonathan M Davis
Re: allSatisfy could use some constraints
On Thursday, September 22, 2011 16:45 Jonathan M Davis wrote:
On Thursday, September 22, 2011 15:36 Andrej Mitrovic wrote:
import std.string;
import std.traits;
import std.typetuple;
void main()
{
if (allSatisfy!(isNumeric, int, short))
{
}
}
D:\DMD\dmd2\windows\bin\..\..\src\phobos\std\typetuple.d(576): Error:
template instance F is not a template declaration, it is a overloadset
This took a good while to figure out what went wrong. std.traits
defines isNumeric, but std.string defines it too. allSatisfy takes an
alias type parameter with no constraints, so maybe some constraints
could be added so it doesn't get instantiated with regular functions
but only template functions?
Well, the simple solution is to just pass it std.traits.isNumeric. As
annoying as it may be at times, conflicting functions is something that
can happen in D and has been planned for, so there are simple ways around
the problem. However, if you're absolutely certain that it doesn't make
sense for allSatisfy to work with a function as opposed to an eponymous
template (and I'm not at all certain that that's true), then you can open
an enhancement request.
Though given that allSatisfy!(isNumeric, int, short) will work with
std.traits.isNumeric and not std.string.isNumeric, I suspect that a template
constraint could be added which would fix the problem simply by checking
whether the compilation succeeds or not with the given arguments. And that
would be a better solution regardless of whether any normal functions
should work with allSatisfy or not.
- Jonathan M Davis
Re: allSatisfy could use some constraints
On 9/23/11, Jonathan M Davis jmdavisp...@gmx.com wrote: Though given that allSatisfy!(isNumeric, int, short) will work with std.traits.isNumeric and not std.string.isNumeric, I suspect that a template constraint could be added which would fix the problem simply by checking whether the compilation succeeds or not with the given arguments. I'm not sure if allSatisfy was meant to be used with regular functions, it's used with templates and types (hence it's in typetuple). I think an alternative all template for runtime arguments was already proposed. My problem is not the name clashes but the fact that the error message is in the body of the allSatisfy template, and this is exactly where constraints come in handy. It took me a while before I figured out that std.string had the same function name, but I'm using an alias now to remedy this.
Re: allSatisfy could use some constraints
On Thursday, September 22, 2011 17:03 Andrej Mitrovic wrote: On 9/23/11, Jonathan M Davis jmdavisp...@gmx.com wrote: Though given that allSatisfy!(isNumeric, int, short) will work with std.traits.isNumeric and not std.string.isNumeric, I suspect that a template constraint could be added which would fix the problem simply by checking whether the compilation succeeds or not with the given arguments. I'm not sure if allSatisfy was meant to be used with regular functions, it's used with templates and types (hence it's in typetuple). I think an alternative all template for runtime arguments was already proposed. Yeah, but functions can be used in template constraints and the like too, so it may be valid. I don't know. I'd have to look at it in more detail. My problem is not the name clashes but the fact that the error message is in the body of the allSatisfy template, and this is exactly where constraints come in handy. It took me a while before I figured out that std.string had the same function name, but I'm using an alias now to remedy this. Yeah. In general, templates really should have template constraints on them (_especially_ public ones), and there are several in Phobos which forward to other templates that don't have template constraints on them when they should. And it appears that allSatisfy is one of them. - Jonathan M Davis
