I was curious too, so found in Section 7.1.5.1 the description of
opAssign using a swap. That explains it I think.
Section 7.1.5.1 does not apply because it concerns the case where you define
your own
overload of the assignment operator. In my example the default assignment is
used.
The
The essence of my problem is why is the destructor called as a
result of the assignment in the first place? There is no
information about this behaviour in the language reference. Can
anyone explain this?
It sounds reasonable. But I cannot find information about this behaviour in the
Language Reference or TDPL book. Can you point to a relevant source?
It is OK if I write
int[char[]] asr;
asr[hello] = 10;
but the following does not compile:
char[] car = hello;
What is the explanation for this behaviour?
int[char[]] is consistently used D's Language
reference to illustrate associative arrays. For me it
looks like something that should not compile. Of
course int[string] works without problem so I wonder
why int[char[]] was used as an example. Was it carried
over from D1 reference perhaps?
Of course, by saying it should not compile I mean
things like asr[hello] should not compile.
After clicking on Template in the left menu of Language Reference on
http://d-programming-language.org/ page, the menu collapses to start menu,
while for other items it remains visible.
The following section from the Language Reference does not correspond to
the current dmd compiler (v2.052, Windows) behaviour:
Integer values cannot be implicitly converted to another type that cannot
represent the integer bit pattern after integral promotion. For example:
ubyte u1 =
The section 12.9 (page 380) in the TDPL books presents foreach overloading.
However the example shown is problematic because there is no
method of automatic initializing of the _root variable without which foreach
overloading cannot work properly (obviously the loop steering
variable has to be
import std.stdio;
void Foo(T:T*)(T arg) if(!is(T==int)) {
writeln(arg of Foo:, arg, typeid(T));
}
void Foo(T:T*)(T arg) if(is(T==int)) {
writeln(int Foo!);
}
void main() {
Foo!(long*)(54);
}
I did not ask what to do to compile it. I knew that 54L would do. The problem is
that in the example I explicitely specify the template parameter as long* so
there
is no reason for the compiler to try and guess T from the type of the function
argument. There is something wrong here.
The program below compiles. Clearly the if constraints in my original example
are causing trouble. It seems like a bug to me.
import std.stdio;
void Foo(T:T*)(T arg) {
writeln(arg of Foo:, arg, typeid(T));
}
void main() {
Foo!(long*)(54);
}
The library refernce has the following text concerning the is expression:
5. is ( Type Identifier : TypeSpecialization )
The condition is satisfied if Type is the same as TypeSpecialization, or if
Type is a class and TypeSpecialization is a base class or base interface of
it. The Identifier is
While trying to understand the expand mechanism presented in the TDPL book I
tried to read std.typetuple and std.typecons files. I found a true nightmare
in those files in the form of an almost infinite chain of aliases and macro
processing. How can one understand a written text if the words are
I try to read the language reference on
http://d-programming-language.org/lex.html but no menu opens on clicking the
language reference item, and only one article about lexical conventions is
available. There used to be more information there so probably the recent
changes (addition of the
15 matches
Mail list logo
