Re: Why this doesn't compile?
On Sat, 11 Oct 2014 23:38:37 -0400 Shammah Chancellor via Digitalmars-d digitalmars-d@puremagic.com wrote: I've withheld from responding to you for a good long while. But, what is your deal Ketmar? You're constantly trolling on this newsgroup. It's not appreciated. you are wrong. i have strong reasons to write my posts in my way. but you aren't interested in that reasons, you are interested in flamewar. there was choice: either ask me for explanation (which is a right thing when you don't understand something) or call me troll (in a form of a fake question). you choose second. what answer do you expect now? i don't want to speak with person who uses presumtion of guilt, and i don't want to explain anything to such person. good day to you. signature.asc Description: PGP signature
Re: Why this doesn't compile?
On Sunday, 12 October 2014 at 08:59:16 UTC, ketmar via Digitalmars-d wrote: On Sat, 11 Oct 2014 23:38:37 -0400 Shammah Chancellor via Digitalmars-d digitalmars-d@puremagic.com wrote: I've withheld from responding to you for a good long while. But, what is your deal Ketmar? You're constantly trolling on this newsgroup. It's not appreciated. you are wrong. i have strong reasons to write my posts in my way. but you aren't interested in that reasons, you are interested in flamewar. there was choice: either ask me for explanation (which is a right thing when you don't understand something) or call me troll (in a form of a fake question). you choose second. what answer do you expect now? i don't want to speak with person who uses presumtion of guilt, and i don't want to explain anything to such person. good day to you. Shammah ignore this douche hes our resident troll.
Why this doesn't compile?
When I want to pass generic String by const reference I get an
error. As far as I understand const should accept both mutable
and immutable data. And there I want to pass it by reference. Is
it possible? Or is there any reason why it is not? Is it a bug?
void doSmth(String)(ref const(String) str) {}
void main()
{
doSmth(Foo);
}
Compilation output:
/d198/f399.d(5): Error: template f399.doSmth does not match any
function template declaration. Candidates are:
/d198/f399.d(1):f399.doSmth(String)(ref const(String) str)
/d198/f399.d(5): Error: template f399.doSmth(String)(ref
const(String) str) cannot deduce template function from argument
types !()(string)
Re: Why this doesn't compile?
On Sat, 11 Oct 2014 18:01:39 + Uranuz via Digitalmars-d digitalmars-d@puremagic.com wrote: Is it a bug? yes. this is a bug in your code. and it's not alone. signature.asc Description: PGP signature
Re: Why this doesn't compile?
On Saturday, 11 October 2014 at 18:01:41 UTC, Uranuz wrote:
When I want to pass generic String by const reference I get an
error. As far as I understand const should accept both mutable
and immutable data. And there I want to pass it by reference.
Is it possible? Or is there any reason why it is not? Is it a
bug?
void doSmth(String)(ref const(String) str) {}
void main()
{
doSmth(Foo);
}
Compilation output:
/d198/f399.d(5): Error: template f399.doSmth does not match any
function template declaration. Candidates are:
/d198/f399.d(1):f399.doSmth(String)(ref const(String)
str)
/d198/f399.d(5): Error: template f399.doSmth(String)(ref
const(String) str) cannot deduce template function from
argument types !()(string)
Try doSmth!String(bla);
Also, the type is string, not String ?
Re: Why this doesn't compile?
On Saturday, 11 October 2014 at 18:01:41 UTC, Uranuz wrote: When I want to pass generic String by const reference I get an error. Strings are passed by reference automatically, so you wouldn't want to double reference them anyway. As far as I understand const should accept both mutable and immutable data. And there I want to pass it by reference. Yes, but since foo isn't an lvalue (variable), you can't pass it by ref in D, even if it is const. This differs from C++, but I don't recall the reason, I think there's just too many weird edge cases that D wanted to avoid. But in the case of strings, arrays, classes, pointers, and user defined structs that wrap these, you don't need to pass it as ref at all, just use plain const.
Re: Why this doesn't compile?
yaOn Saturday, 11 October 2014 at 18:11:07 UTC, ketmar via Digitalmars-d wrote: On Sat, 11 Oct 2014 18:01:39 + Uranuz via Digitalmars-d digitalmars-d@puremagic.com wrote: Is it a bug? yes. this is a bug in your code. and it's not alone. You said you leave. Why dont you just go? Don't be a liar. Bye ketmar!
Re: Why this doesn't compile?
On 2014-10-11 18:10:52 +, ketmar via Digitalmars-d said: On Sat, 11 Oct 2014 18:01:39 + Uranuz via Digitalmars-d digitalmars-d@puremagic.com wrote: Is it a bug? yes. this is a bug in your code. and it's not alone. image I've withheld from responding to you for a good long while. But, what is your deal Ketmar? You're constantly trolling on this newsgroup. It's not appreciated.
Re: Why this doesn't compile?
On 2014-10-11 18:10:22 +, Adam D. Ruppe said: On Saturday, 11 October 2014 at 18:01:41 UTC, Uranuz wrote: When I want to pass generic String by const reference I get an error. Strings are passed by reference automatically, so you wouldn't want to double reference them anyway. That's not entirely true. They're passed by value unless something changed. By value in that the struct representation is passed. That is to say, the length and a pointer. As far as I understand const should accept both mutable and immutable data. And there I want to pass it by reference. Yes, but since foo isn't an lvalue (variable), you can't pass it by ref in D, even if it is const. This differs from C++, but I don't recall the reason, I think there's just too many weird edge cases that D wanted to avoid. But in the case of strings, arrays, classes, pointers, and user defined structs that wrap these, you don't need to pass it as ref at all, just use plain const. That's because string literals are stored in the data segment and are immutable rvalues. You can't have a ref to an rvalue.
Re: Why it doesn't compile in D 2.0?
aarti_pl wrote:
W dniu 2010-01-17 19:38, Don pisze:
aarti_pl wrote:
class Test {
string t1 = test; //Ok!
char[] t2 = test.dup; //Compile error
}
void main(char[][] args) {
}
Error:
hello.d(3): Error: cannot evaluate _adDupT((
D12TypeInfo_Aya6__initZ),test) at compile time
hello.d(3): Error: cannot evaluate _adDupT((
D12TypeInfo_Aya6__initZ),test) at compile time
Is there workaround?
BR
Marcin Kuszczak
(aarti_pl)
Workaround: It works in dmd2, svn 337 and later g.
Wow. I even could not report it as a bug. That is really fast bug fixing
:-)
It wasn't specifically a fix of this bug. Some long-standing CTFE
limitations were fixed, which make lots of things start working.
Could you please explain what has initialization of variables to do with
CTFE? As far as I understand it should be done on runtime... So why is
there compile time execution involved?
It shouldn't be happening. There's a bug somewhere.
And other questions. Would it be possible to initialize more complex
types with better CTFE? I see it as quite major issue when I can not
write in class definition or in global scope:
auto serializer = new Serializer!(TextArchive)();
If you can't do that now, that's a serious bug.
But classes will eventually work in CTFE.
Re: Why it doesn't compile in D 2.0?
W dniu 2010-01-17 20:56, Simen kjaeraas pisze: aarti_pl aa...@interia.pl wrote: Well, I don't get it... IMHO .dup makes mutable copy of data (so copy of test) in mutable area of memory. And it should mean that every pointer points to different area of memory... Am I wrong? You're mostly right. However, this happens at compile time, so the mutable data is mutable no longer once its been stored in the executable. IOW, Test.dup is executed once at compile time, and the result stored in Test.init. Then, at runtime, Test.init is copied onto each new instance of the struct/class. Test.dup is not executed at runtime. As Lutger pointed out, this smells of a bug. Sadly, fixing that bug would not overcome the problem of having no default constructors for structs. -- Simen Well, in such a case you are right. It's not what I would like to have... It will be indeed source of bugs. BR Marcin Kuszczak (aarti_pl)
Re: Why it doesn't compile in D 2.0?
aarti_pl wrote:
class Test {
string t1 = test;//Ok!
char[] t2 = test.dup;//Compile error
}
void main(char[][] args) {
}
Error:
hello.d(3): Error: cannot evaluate _adDupT((
D12TypeInfo_Aya6__initZ),test) at compile time
hello.d(3): Error: cannot evaluate _adDupT((
D12TypeInfo_Aya6__initZ),test) at compile time
Is there workaround?
BR
Marcin Kuszczak
(aarti_pl)
Workaround: It works in dmd2, svn 337 and later g.
Re: Why it doesn't compile in D 2.0?
W dniu 2010-01-17 12:54, Lutger pisze:
On 01/17/2010 01:38 AM, Simen kjaeraas wrote:
Lutger lutger.blijdest...@gmail.com wrote:
Perhaps this is or should be a bug. You can override dup to work in
ctfe:
char[] dup(string str)
{
return str.dup;
}
class Test {
string t1 = test; //Ok!
char[] t2 = test.dup; //Compile error
char[] t3 = test.dup(); //Ok!
}
The problem with this approach is that you now have a pointer to mutable
data, the contents of which are stored in the static data segment, and
thus
actually immutable.
Second (and this is related to the first), the pointer will be the
same for
all instances, and thus changing the contents of one will change the
contents of all.
IOW, what one (probably) wants in this situation, is a constructor.
Thanks man, this is a big error of mine. Trying to manipulate the char[]
does indeed do a segfault! I can't seem to find an explanation in the
spec of how initializers are supposed to work, so I assumed incorrectly
it would be ok.
I find it a bit disturbing that you can end up with a mutable reference
to immutable data so easily, without casting or anything.
Well, I don't get it...
IMHO .dup makes mutable copy of data (so copy of test) in mutable area
of memory. And it should mean that every pointer points to different
area of memory...
Am I wrong?
BR
Marcin Kuszczak
(aarti_pl)
Re: Why it doesn't compile in D 2.0?
W dniu 2010-01-17 19:38, Don pisze:
aarti_pl wrote:
class Test {
string t1 = test; //Ok!
char[] t2 = test.dup; //Compile error
}
void main(char[][] args) {
}
Error:
hello.d(3): Error: cannot evaluate _adDupT((
D12TypeInfo_Aya6__initZ),test) at compile time
hello.d(3): Error: cannot evaluate _adDupT((
D12TypeInfo_Aya6__initZ),test) at compile time
Is there workaround?
BR
Marcin Kuszczak
(aarti_pl)
Workaround: It works in dmd2, svn 337 and later g.
Wow. I even could not report it as a bug. That is really fast bug fixing :-)
Could you please explain what has initialization of variables to do with
CTFE? As far as I understand it should be done on runtime... So why is
there compile time execution involved?
And other questions. Would it be possible to initialize more complex
types with better CTFE? I see it as quite major issue when I can not
write in class definition or in global scope:
auto serializer = new Serializer!(TextArchive)();
BR
Marcin Kuszczak
(aarti_pl)
Re: Why it doesn't compile in D 2.0?
aarti_pl aa...@interia.pl wrote: Well, I don't get it... IMHO .dup makes mutable copy of data (so copy of test) in mutable area of memory. And it should mean that every pointer points to different area of memory... Am I wrong? You're mostly right. However, this happens at compile time, so the mutable data is mutable no longer once its been stored in the executable. IOW, Test.dup is executed once at compile time, and the result stored in Test.init. Then, at runtime, Test.init is copied onto each new instance of the struct/class. Test.dup is not executed at runtime. As Lutger pointed out, this smells of a bug. Sadly, fixing that bug would not overcome the problem of having no default constructors for structs. -- Simen
Why it doesn't compile in D 2.0?
class Test {
string t1 = test; //Ok!
char[] t2 = test.dup; //Compile error
}
void main(char[][] args) {
}
Error:
hello.d(3): Error: cannot evaluate _adDupT((
D12TypeInfo_Aya6__initZ),test) at compile time
hello.d(3): Error: cannot evaluate _adDupT((
D12TypeInfo_Aya6__initZ),test) at compile time
Is there workaround?
BR
Marcin Kuszczak
(aarti_pl)
Re: Why it doesn't compile in D 2.0?
aarti_pl aa...@interia.pl wrote:
class Test {
string t1 = test; //Ok!
char[] t2 = test.dup; //Compile error
}
void main(char[][] args) {
}
Error:
hello.d(3): Error: cannot evaluate _adDupT((
D12TypeInfo_Aya6__initZ),test) at compile time
hello.d(3): Error: cannot evaluate _adDupT((
D12TypeInfo_Aya6__initZ),test) at compile time
Is there workaround?
Constant strings are saved in the static data segment of the executable, so
the .dup call would need to be executed at runtime. In other words, what
this would do is cast const to mutable.
If this did compile, changing the contents of t2 would change those
contents
for all instances of Test, which I assume is not your intention.
As for the workaround, write a constructor:
class Test {
string t1 = test;
string t2;
this( ) {
t2 = test.dup;
}
}
--
Simen
Re: Why it doesn't compile in D 2.0?
W dniu 2010-01-16 13:26, Simen kjaeraas pisze:
aarti_pl aa...@interia.pl wrote:
class Test {
string t1 = test; //Ok!
char[] t2 = test.dup; //Compile error
}
void main(char[][] args) {
}
Error:
hello.d(3): Error: cannot evaluate _adDupT((
D12TypeInfo_Aya6__initZ),test) at compile time
hello.d(3): Error: cannot evaluate _adDupT((
D12TypeInfo_Aya6__initZ),test) at compile time
Is there workaround?
Constant strings are saved in the static data segment of the executable, so
the .dup call would need to be executed at runtime. In other words, what
this would do is cast const to mutable.
If this did compile, changing the contents of t2 would change those
contents
for all instances of Test, which I assume is not your intention.
As for the workaround, write a constructor:
class Test {
string t1 = test;
string t2;
this( ) {
t2 = test.dup;
}
}
I want just simple initialization of variable. Casting of course is no
(sane) option.
Indeed, in case of classes your workaround will work.
But in case of struct? The same problem occurs for structs, but you can
not declare default constructor in structs...
IMHO .dup should work for initialization of classes/structs.
Any other ideas?
BR
Marcin Kuszczak
(aarti_pl)
Re: Why it doesn't compile in D 2.0?
On 01/16/2010 02:01 PM, aarti_pl wrote:
W dniu 2010-01-16 13:26, Simen kjaeraas pisze:
aarti_pl aa...@interia.pl wrote:
class Test {
string t1 = test; //Ok!
char[] t2 = test.dup; //Compile error
}
void main(char[][] args) {
}
Error:
hello.d(3): Error: cannot evaluate _adDupT((
D12TypeInfo_Aya6__initZ),test) at compile time
hello.d(3): Error: cannot evaluate _adDupT((
D12TypeInfo_Aya6__initZ),test) at compile time
Is there workaround?
Constant strings are saved in the static data segment of the
executable, so
the .dup call would need to be executed at runtime. In other words, what
this would do is cast const to mutable.
If this did compile, changing the contents of t2 would change those
contents
for all instances of Test, which I assume is not your intention.
As for the workaround, write a constructor:
class Test {
string t1 = test;
string t2;
this( ) {
t2 = test.dup;
}
}
I want just simple initialization of variable. Casting of course is no
(sane) option.
Indeed, in case of classes your workaround will work.
But in case of struct? The same problem occurs for structs, but you can
not declare default constructor in structs...
IMHO .dup should work for initialization of classes/structs.
Any other ideas?
BR
Marcin Kuszczak
(aarti_pl)
Perhaps this is or should be a bug. You can override dup to work in ctfe:
char[] dup(string str)
{
return str.dup;
}
class Test {
string t1 = test;//Ok!
char[] t2 = test.dup;//Compile error
char[] t3 = test.dup(); //Ok!
}
The spec even mentions it under ctfe:
6. as a special case, the following properties can be executed at
compile time:
.dup
.length
.keys
.values
http://www.digitalmars.com/d/2.0/function.html
Re: Why it doesn't compile in D 2.0?
W dniu 2010-01-16 15:30, Lutger pisze:
Perhaps this is or should be a bug. You can override dup to work in ctfe:
char[] dup(string str)
{
return str.dup;
}
class Test {
string t1 = test; //Ok!
char[] t2 = test.dup; //Compile error
char[] t3 = test.dup(); //Ok!
}
The spec even mentions it under ctfe:
6. as a special case, the following properties can be executed at
compile time:
..dup
..length
..keys
..values
http://www.digitalmars.com/d/2.0/function.html
Thanks! I will use function dup() as a workaround for now, and will put
bug to bugzilla.
I still wonder what has CTFE to do with this case. Do you know?
I am asking because it's not possible in general case to initialize all
variables in classes/structs and in global namespace.
E.g. I had to use:
Serializer!(TextArchive) serializer;
static this() {
serializer = new typeof(serializer);
}
to initialize serializer. I am wondering if with better CTFE we could
get it working?
BR
Marcin Kuszczak
(aarti_pl)
Re: Why it doesn't compile in D 2.0?
On 01/16/2010 04:18 PM, aarti_pl wrote:
W dniu 2010-01-16 15:30, Lutger pisze:
Perhaps this is or should be a bug. You can override dup to work in ctfe:
char[] dup(string str)
{
return str.dup;
}
class Test {
string t1 = test; //Ok!
char[] t2 = test.dup; //Compile error
char[] t3 = test.dup(); //Ok!
}
The spec even mentions it under ctfe:
6. as a special case, the following properties can be executed at
compile time:
..dup
..length
..keys
..values
http://www.digitalmars.com/d/2.0/function.html
Thanks! I will use function dup() as a workaround for now, and will put
bug to bugzilla.
I still wonder what has CTFE to do with this case. Do you know?
I am asking because it's not possible in general case to initialize all
variables in classes/structs and in global namespace.
E.g. I had to use:
Serializer!(TextArchive) serializer;
static this() {
serializer = new typeof(serializer);
}
to initialize serializer. I am wondering if with better CTFE we could
get it working?
BR
Marcin Kuszczak
(aarti_pl)
ctfe is basically a user defined extension of constant folding, which is
also mentioned in the spec that way. So to use it for more complex
initialization makes sense, but this is constrained to compile time.
From the example of the serializer, all we know is that it allocates
memory. Array dup-ing also allocates memory however, so theoretically I
see no immediate reason why it would not (eventually) be possible to use
ctfe in that case. But it may be difficult to prove statically by the
compiler that it is indeed safe to do so.
