Re: extern(C++) in win32.mak
On Wednesday, 7 February 2018 at 08:28:23 UTC, Seb wrote: On Wednesday, 7 February 2018 at 06:05:54 UTC, Paul D Anderson wrote: Is there anyone who knows the ins and outs of the makefile that can shed some light? Thanks, Paul I recommend cloning DMD directly from git if you want to compile from source. There are many CIs in place that ensure that it always works. I downloaded from git but still get an error, though it's no longer the ddoc file error. At this line (316-7), $G\lexer.lib: $(LEXER_SRCS) $(ROOT_SRCS) $(STRING_IMPORT_FILES) $G $(HOST_DC) -of$@ -vtls -lib -J$G $(DFLAGS) $(LEXER_SRCS) $(ROOT_SRCS) I get Error: 'of..\generated\windows\release\32\lexer.lib' not found It looks to me as if at ' -of$@ ', the '-of' flag is supposed to specify the output file, but is being interpreted as part of the filename. Does anyone know what the problem is? Paul
Re: extern(C++) in win32.mak
On Wednesday, 7 February 2018 at 06:18:04 UTC, rikki cattermole
wrote:
On 07/02/2018 6:05 AM, Paul D Anderson wrote:
I don't understand the following line in dmd/src/win32.mak:
extern (C++) __gshared const(char)* ddoc_default = import
("default_ddoc_theme.ddoc");
That is a string import (-J).
What does the word "import" mean in this context? I can't find
any documentation on the use of import in this way, and the
line fails to compile during the make.
https://dlang.org/spec/expression.html#import_expressions
Thank you. I did not know that.
The error was caused by an over-zealous virus checker preventing
some dmc executables from downloading.
Paul
extern(C++) in win32.mak
I don't understand the following line in dmd/src/win32.mak:
extern (C++) __gshared const(char)* ddoc_default = import
("default_ddoc_theme.ddoc");
What does the word "import" mean in this context? I can't find
any documentation on the use of import in this way, and the line
fails to compile during the make.
The error message is:
file "default_ddoc_theme.ddoc" cannot be found or not in a path
specified with -J
The file is in the directory dmd2/src/res, which is specified
with -J../res in the build.
Is there anyone who knows the ins and outs of the makefile that
can shed some light?
Thanks,
Paul
Re: DMD win32.mak error
On Saturday, 11 March 2017 at 18:02:00 UTC, Stefan Koch wrote: On Saturday, 11 March 2017 at 02:25:15 UTC, Paul D Anderson wrote: On Saturday, 11 March 2017 at 00:34:03 UTC, Paul D Anderson wrote: On Friday, 10 March 2017 at 22:04:23 UTC, Paul D Anderson wrote: [...] I see John Colvin has already filed a bug report (issue 17165) addressing this. Apparently the missing file is available on GitHub. I copied the missing file John referenced to my src/dmd file but this did not have any effect. I've created a bug report (17253) addressing this problem. Paul verstring is created automatically I think the problem is a failure in the process of creating verstring. The missing file is "dmd/res/default_ddoc_theme/ddoc"
Re: DMD win32.mak error
On Saturday, 11 March 2017 at 00:34:03 UTC, Paul D Anderson wrote: On Friday, 10 March 2017 at 22:04:23 UTC, Paul D Anderson wrote: While building DMD -- "make -fwin32.mak release" -- I received the following error message: echo "2.073.2" > verstr.h Error: don't know how to make '../res/default_ddoc_theme/ddoc' --- error level 1 I'm guessing it might be a build configuration problem on my end, but what is the problem? Paul I see John Colvin has already filed a bug report (issue 17165) addressing this. Apparently the missing file is available on GitHub. I copied the missing file John referenced to my src/dmd file but this did not have any effect. I've created a bug report (17253) addressing this problem. Paul
Re: DMD win32.mak error
On Friday, 10 March 2017 at 22:04:23 UTC, Paul D Anderson wrote: While building DMD -- "make -fwin32.mak release" -- I received the following error message: echo "2.073.2" > verstr.h Error: don't know how to make '../res/default_ddoc_theme/ddoc' --- error level 1 I'm guessing it might be a build configuration problem on my end, but what is the problem? Paul I see John Colvin has already filed a bug report (issue 17165) addressing this. Apparently the missing file is available on GitHub.
DMD win32.mak error
While building DMD -- "make -fwin32.mak release" -- I received the following error message: echo "2.073.2" > verstr.h Error: don't know how to make '../res/default_ddoc_theme/ddoc' --- error level 1 I'm guessing it might be a build configuration problem on my end, but what is the problem? Paul
Re: bigint compile time errors
On Sunday, 5 July 2015 at 20:35:03 UTC, Kai Nacke wrote: On Friday, 3 July 2015 at 04:08:32 UTC, Paul D Anderson wrote: On Friday, 3 July 2015 at 03:57:57 UTC, Anon wrote: On Friday, 3 July 2015 at 02:37:00 UTC, Paul D Anderson wrote: [...] Should be plusTwo(in BigInt n) instead. Yes, I had aliased BigInt to bigint. And I checked and it compiles for me too with Windows m64. That makes it seem more like a bug than a feature. I'll open a bug report. Paul The point here is that x86 uses an assembler-optimized implementation (std.internal.math.biguintx86) and every other cpu architecture (including x64) uses a D version (std.internal.math.biguintnoasm). Because of the inline assembler, the x86 version is not CTFE-enabled. Regards, Kai Could we add a version or some other flag that would allow the use of .biguintnoasm with the x86? Paul
Re: bigint compile time errors
On Friday, 3 July 2015 at 02:37:00 UTC, Paul D Anderson wrote: The following code fails to compile and responds with the given error message. Varying the plusTwo function doesn't work; as long as there is an arithmetic operation the error occurs. [...] https://issues.dlang.org/show_bug.cgi?id=14767
bigint compile time errors
The following code fails to compile and responds with the given
error message. Varying the plusTwo function doesn't work; as
long as there is an arithmetic operation the error occurs.
It seems to mean that there is no way to modify a BigInt at
compile time. This seriously limits the usability of the type.
enum BigInt test1 = BigInt(123);
enum BigInt test2 = plusTwo(test1);
public static BigInt plusTwo(in bigint n)
{
return n + 2;
}
void main()
{
}
Error message:
C:\D\dmd2\windows\bin\..\..\src\phobos\std\internal\math\biguintx86.d(226):
Error: asm statements cannot be interpreted at compile time
C:\D\dmd2\windows\bin\..\..\src\phobos\std\internal\math\biguintcore.d(1248):
called from here: multibyteIncrementAssign(result[0..__dollar - 1u], lo)
C:\D\dmd2\windows\bin\..\..\src\phobos\std\internal\math\biguintcore.d(515):
called from here: addInt(x.data, y)
C:\D\dmd2\windows\bin\..\..\src\phobos\std\bigint.d(118):
called from here: addOrSubInt(this.data, u, cast(int)this.sign !=
cast(int)(y 0u), this.sign)
C:\D\dmd2\windows\bin\..\..\src\phobos\std\bigint.d(118):
called from here: addOrSubInt(this.data, u, cast(int)this.sign !=
cast(int)(y 0u), this.sign)
C:\D\dmd2\windows\bin\..\..\src\phobos\std\bigint.d(258):
called from here: r.opOpAssign(y)
called from here: n.opBinary(2)
called from here: plusTwo(BigInt(BigUint([123u], false))
Re: bigint compile time errors
On Friday, 3 July 2015 at 03:57:57 UTC, Anon wrote: On Friday, 3 July 2015 at 02:37:00 UTC, Paul D Anderson wrote: enum BigInt test1 = BigInt(123); enum BigInt test2 = plusTwo(test1); public static BigInt plusTwo(in bigint n) Should be plusTwo(in BigInt n) instead. Yes, I had aliased BigInt to bigint. And I checked and it compiles for me too with Windows m64. That makes it seem more like a bug than a feature. I'll open a bug report. Paul
Re: function default parameters lost
On Thursday, 25 June 2015 at 14:17:13 UTC, Paul D Anderson wrote: On Thursday, 25 June 2015 at 07:10:57 UTC, tcak wrote: On Thursday, 25 June 2015 at 04:43:51 UTC, Paul D Anderson wrote: I'm trying to pass a function pointer while keeping the default parameter values intact. Given the following: [...] I filed a bug about 2-3 months ago about default parameters similar to yours. My guess is that it hasn't been fixed yet, and you have hit the same issue. Thanks Turns out this is expected behavior. Default parameter values are stripped from function pointers.
Re: function default parameters lost
On Thursday, 25 June 2015 at 07:10:57 UTC, tcak wrote: On Thursday, 25 June 2015 at 04:43:51 UTC, Paul D Anderson wrote: I'm trying to pass a function pointer while keeping the default parameter values intact. Given the following: [...] I filed a bug about 2-3 months ago about default parameters similar to yours. My guess is that it hasn't been fixed yet, and you have hit the same issue. Thanks
Re: Compiles but does not link
On Thursday, 25 June 2015 at 00:24:23 UTC, Paul D Anderson wrote:
The code snippet below compiles but the linker fails with Error
42: Symbol undefined.
What am I doing wrong?
void main()
{
int foo(int a);
alias FP = int delegate(int);
FP fp = foo;
}
Paul
Uh, never mind. I got so focused on the delegate I forgot to give
the function a body.
Compiles but does not link
The code snippet below compiles but the linker fails with Error
42: Symbol undefined.
What am I doing wrong?
void main()
{
int foo(int a);
alias FP = int delegate(int);
FP fp = foo;
}
Paul
function default parameters lost
I'm trying to pass a function pointer while keeping the default
parameter values intact. Given the following:
import std.traits;
import std.stdio;
int foo(int a, int b = 1)
{
return a;
}
alias FOOP = int function(int, int = 1);
struct ST(POOF)
{
FOOP fctn;
this(POOF fctn)
{
this.fctn = fctn;
}
void details()
{
alias PDVA = ParameterDefaultValueTuple!fctn;
writefln(typeid(PDVA[0]) = %s, typeid(PDVA[0]));
writefln(typeid(PDVA[1]) = %s, typeid(PDVA[1]));
}
}
void main()
{
FOOP fp = foo;
auto st = ST!FOOP(fp);
st.details;
}
The default parameter value types are void, int: a has no default
and b has an int value as its default.
If I change line 14 from
FOOP fctn;
to
POOF fctn;
The default parameter value types are void, void. In other words
the default value for b is no longer there.
Why doesn't invoking the template (ST!FOOP) replace POOF in line
14 with FOOP?
Paul
Re: mixin template question
On Sunday, 12 April 2015 at 04:04:43 UTC, lobo wrote:
On Sunday, 12 April 2015 at 03:51:03 UTC, Paul D Anderson wrote:
I don't understand why the following code compiles and runs
without an error:
import std.stdio;
mixin template ABC(){
int abc() { return 3; }
}
mixin ABC;
int abc() { return 4; }
void main()
{
writefln(abc() = %s, abc());
}
Doesn't the mixin ABC create a function with the same
signature as the actual function abc()?
It compiles with both included and writes abc() = 4. If I
comment out the actual function then it writes abc() = 3.
The actual function takes precedence, but why don't they
conflict?
Paul
As the manual says (snippet below) the surrounding scope
overrides mixin
http://dlang.org/template-mixin.html
---
Mixin Scope
The declarations in a mixin are ‘imported’ into the surrounding
scope. If the name of a declaration in a mixin is the same as a
declaration in the surrounding scope, the surrounding
declaration overrides the mixin one:
int x = 3;
mixin template Foo()
{
int x = 5;
int y = 5;
}
mixin Foo;
int y = 3;
void test()
{
writefln(x = %d, x); // prints 3
writefln(y = %d, y); // prints 3
}
---
bye,
lobo
Thanks.
Re: Function name from function pointer
On Saturday, 11 April 2015 at 19:08:50 UTC, Marco Leise wrote:
Am Sat, 11 Apr 2015 18:28:35 +
schrieb Paul D Anderson claude.re...@msnmail.com:
Is there a way to return the name of a function (a string)
from a pointer to that function?
Function pointer example from D Reference:
---
int function() fp;
void test()
{
static int a = 7;
static int foo() { return a + 3; }
fp = foo;
}
void bar()
{
test();
int i = fp(); // i is set to 10
}
---
Can I get foo from fp?
Paul
Nope, that would require that fp not only contains a pointer
to the function but also a pointer to the name. That's not how
it works. But continuing that thought, you could add the
function's name as an additional variable and set that every
time you set fp.
Okay, thanks, I can see that.
Paul
Function name from function pointer
Is there a way to return the name of a function (a string) from a
pointer to that function?
Function pointer example from D Reference:
---
int function() fp;
void test()
{
static int a = 7;
static int foo() { return a + 3; }
fp = foo;
}
void bar()
{
test();
int i = fp(); // i is set to 10
}
---
Can I get foo from fp?
Paul
mixin template question
I don't understand why the following code compiles and runs
without an error:
import std.stdio;
mixin template ABC(){
int abc() { return 3; }
}
mixin ABC;
int abc() { return 4; }
void main()
{
writefln(abc() = %s, abc());
}
Doesn't the mixin ABC create a function with the same signature
as the actual function abc()?
It compiles with both included and writes abc() = 4. If I
comment out the actual function then it writes abc() = 3. The
actual function takes precedence, but why don't they conflict?
Paul
Re: Template Parameter Deduction
On Wednesday, 11 March 2015 at 23:04:15 UTC, Ali Çehreli wrote:
On 03/11/2015 03:44 PM, Paul D Anderson wrote:
This used to work in D2.065:
given
1) public T mul(T)(in T x, in T y,
Context context = T.context) if (isDecimal!T)
// one template parameter for the two input values
and
2) public T mul(T, U)(in T x, U n, Context context = T.context)
if (isDecimal!T isIntegral!U)
// two different template parameters for the two input
values
then
3) dec9 arg1 = dec9(1.20);
long arg2 = 3;
result = mul(arg1, arg2);
// correctly deduced function
But now (D2.066.1) either 1) has to be changed to
1) public T mul(T, U)(in T x, U y, Context context = T.context)
if (isDecimal!T isDecimal!U)
// two identical template parameters for the two input
values
or 3) has to be changed to
3) dec9 arg1 = dec9(1.20);
long arg2 = 3;
result = mul!(dec9,long)(arg1, arg2);
// template parameters have to be made explicit
Is this expecded behavior?
Paul
Hint: It makes it much simpler to work with complete code. The
following code took a while for me to put together:
template isDecimal(T)
{
enum isDecimal = true;
}
template isIntegral(T)
{
enum isIntegral = true;
}
public T mul(T)(in T x, in T y,
Context context = T.context) if (isDecimal!T)
// one template parameter for the two input values
{
return x;
}
alias Context = int;
public T mul(T, U)(in T x, U n, Context context = T.context)
if (isDecimal!T isIntegral!U)
// two different template parameters for the two input
values
{
return x;
}
struct dec9
{
string s;
enum context = 42;
}
void main()
{
dec9 arg1 = dec9(1.20);
long arg2 = 3;
dec9 result = mul(arg1, arg2);
// correctly deduced function
}
Yes, it fails with 2.066.1 but compiles fine with git head.
Ali
Thanks to you and John for taking the time to work this out. I
didn't mean for anyone to rebuild the example -- I was just
hoping there was a quick answer based on known language changes.
I should have included complete example code.
At any rate, it looks like there is a hiccup in the template
parameter deduction code and that it is being fixed. And it's
easy to work around. I'll dig a little deeper to see if I can
find a related bug report.
Paul
Re: Template Parameter Deduction
On Wednesday, 11 March 2015 at 22:44:12 UTC, Paul D Anderson wrote: This used to work in D2.065: given 1) public T mul(T)(in T x, in T y, Context context = T.context) if (isDecimal!T) // one template parameter for the two input values and 2) public T mul(T, U)(in T x, U n, Context context = T.context) if (isDecimal!T isIntegral!U) // two different template parameters for the two input values then 3) dec9 arg1 = dec9(1.20); long arg2 = 3; result = mul(arg1, arg2); // correctly deduced function But now (D2.066.1) either 1) has to be changed to 1) public T mul(T, U)(in T x, U y, Context context = T.context) if (isDecimal!T isDecimal!U) // two identical template parameters for the two input values or 3) has to be changed to 3) dec9 arg1 = dec9(1.20); long arg2 = 3; result = mul!(dec9,long)(arg1, arg2); // template parameters have to be made explicit Is this expecded behavior? Paul or *expected* behavior
Template Parameter Deduction
This used to work in D2.065: given 1) public T mul(T)(in T x, in T y, Context context = T.context) if (isDecimal!T) // one template parameter for the two input values and 2) public T mul(T, U)(in T x, U n, Context context = T.context) if (isDecimal!T isIntegral!U) // two different template parameters for the two input values then 3) dec9 arg1 = dec9(1.20); long arg2 = 3; result = mul(arg1, arg2); // correctly deduced function But now (D2.066.1) either 1) has to be changed to 1) public T mul(T, U)(in T x, U y, Context context = T.context) if (isDecimal!T isDecimal!U) // two identical template parameters for the two input values or 3) has to be changed to 3) dec9 arg1 = dec9(1.20); long arg2 = 3; result = mul!(dec9,long)(arg1, arg2); // template parameters have to be made explicit Is this expecded behavior? Paul
Re: new error message in 2.066, type bool (const)
On Wednesday, 20 August 2014 at 20:46:20 UTC, Paul D Anderson
wrote:
Re-compiling existing code with version 2.066 generates a lot
of errors complaining about implicit conversion to const.
Typical is this call (inside a struct with properties 1 2):
z.sign = x.sign ^ y.sign;
Error: None of the overloads of 'sign' are callable using
argument types bool (const), candidates are:
1) @property
@safe
bool sign() const
{
return signed;
}
2) @property
@safe
bool sign(in bool value)
{
signed = value;
return signed;
}
What changed? It ran okay with early beta versions, but not
with the release.
Paul
The problem (not obvious from the above) is that a templated type
is bringing its qualifiers into the template.
Here is a small example:
T add(T)(in T x, in T y)
{
T z;
z = x + y;
return z;
}
void main()
{
const double a = 1.0;
const double b = 2.0;
double c;
c = add(a,b);
}
Error: Cannot modify immutable expression z
---
Since a and b are const double the deduced template type is also
const double. Then when z is declared as type T it is also const.
This compiled and ran in beta 5 but not in beta 6.
If I modify the above so that declaration and assignment are
performed at the same time:
T z = x + y;
This compiles and assigns the (const double) value 3.0 to z.
After the function call c contains the double value 3.0, but it
is no longer const.
The error can be avoided by declaring z to be of type Unqual!T in
most cases.
I don't know if this is expected behavior that just wasn't
enforced before, or if this is something new. Either way I don't
like it. And I'm a little surprised I'm the only one affected by
this. I'll keep digging.
Paul
Re: new error message in 2.066, type bool (const)
On Friday, 22 August 2014 at 01:25:05 UTC, Paul D Anderson wrote: On Wednesday, 20 August 2014 at 20:46:20 UTC, Paul D Anderson I don't know if this is expected behavior that just wasn't enforced before, or if this is something new. Either way I don't like it. And I'm a little surprised I'm the only one affected by this. I'll keep digging. Paul https://issues.dlang.org/show_bug.cgi?id=13351
new error message in 2.066, type bool (const)
Re-compiling existing code with version 2.066 generates a lot of
errors complaining about implicit conversion to const. Typical is
this call (inside a struct with properties 1 2):
z.sign = x.sign ^ y.sign;
Error: None of the overloads of 'sign' are callable using
argument types bool (const), candidates are:
1) @property
@safe
bool sign() const
{
return signed;
}
2) @property
@safe
bool sign(in bool value)
{
signed = value;
return signed;
}
What changed? It ran okay with early beta versions, but not with
the release.
Paul
Re: new error message in 2.066, type bool (const)
What changed? It ran okay with early beta versions, but not with the release. Paul It compiles in beta-5 but not beta-6. Is the list of changes in the beta testing wiki complete? None seem pertinent. monarch_dodra: Thanks for checking. I was trying to avoid tearing everything down. I was hoping someone would recognize the error. Looks like I'll have to chase it down. Paul
Templates and function parametes
When I try to compile these two functions, the second function is
flagged with an already defined error:
bool testRoundTrip(T, U)(T first, U second) if (isIntegral!T
isFloatingPoint!U)
{
return false;
}
bool testRoundTrip(U, T)(U first, T second) if (isIntegral!T
isFloatingPoint!U)
{
return false;
}
They look to me to be distinct functions, one with an integral
parameter followed by a floating point parameter and the other
with a floating point parameter followed by an integral parameter.
At first I thought this was a template problem, but the following
code also raises the same error.
bool testRoundTrip(int first, double second)
{
return false;
}
bool testRoundTrip(double first, int second)
{
return false;
}
What's the problem?
Re: Templates and function parametes
On Saturday, 9 August 2014 at 07:07:42 UTC, Rikki Cattermole wrote: Cannot reproduce on either 2.065 or git head (according to dpaste). You are right. I had the functions in a unittest block that got executed more than once so the second execution was a redefinition. Thanks for taking the time to check. Paul
Re: template mixins for boilerplate
On Saturday, 21 June 2014 at 11:12:18 UTC, Artur Skawina via
Digitalmars-d-learn wrote:
On 06/21/14 05:32, Paul D Anderson via Digitalmars-d-learn
wrote:
I can't use a template mixin:
mixin template Function(string name)
{
const char[] Function =
public static int ~ name ~ () { return other.module.
~ name ~; };
}
Error: mixin templates are not regular templates.
mixin template Function(string name) {
mixin(public static int ~ name ~ () { return
other.module. ~ name ~; });
}
struct S {
mixin Function!fctn1;
}
artur
Beautiful! That's it.
Thanks,
Paul
template mixins for boilerplate
I am misunderstanding something about using mixins for
boilerplate code.
I've got a set of functions all of which do the same thing:
public static int fctn1() { return other.place.fctn1; }
I can't use a string mixin to generate the code:
template Function(string name)
{
const char[] Function =
public static int ~ name ~ () { return other.place. ~
name ~; };
}
struct S {
mixin (Function!(fctn1));
}
Error: cannot use a template to add field to aggregate S.
I can't use a template mixin:
mixin template Function(string name)
{
const char[] Function =
public static int ~ name ~ () { return other.module. ~
name ~; };
}
Error: mixin templates are not regular templates.
Is there a way to duplicate fctn1 with a different name each time?
Paul
enum functions
Does enum have any effect on functions?
Is this:
mixin (Constant!(ln2));
package enum T ln2(T)(Context context) {
return log(T.TWO, context, false);
}
different from this:
mixin (Constant!(ln2));
package /*enum*/ T ln2(T)(Context context) {
return log(T.TWO, context, false);
}
The spec says that enums are used to declare constants. I'm not
sure what it means for a function to be constant. My guess would
be that the value of the function is CTFE'd and that value is
stored as if it were a manifest constant, but that's not what
happens. The enum functions operate exactly like the non-enum
functions.
So either enum functions are different in some way or they're
not. If they are different that should be in the spec. If not,
enum before a function declaration should not be allowed.
Paul
Casting Structs
I'm working on the decimal number package for D. A decimal is a struct with precision, max exponent and rounding mode parameters: Decimal!(PRECISION, MAX_EXPO, ROUNDING). I was trying to overload the opCast operator for this struct and I found that it does not seem necessary. I can cast decimals with different precisions, etc., back and forth without overloading opCast. This code works: alias dec9 = Decimal!(9,99); alias dec10 = Decimal!(10,99); dec9 bingo = dec9(123.45); dec10 little = cast(dec10(bingo)); assert(little == dec10(123.45)); Is this expected behavior? Paul
Re: enums
On Saturday, 31 May 2014 at 20:14:59 UTC, bearophile wrote: Miles Stoudenmire: In contrast to those two examples where immutable can be used at compile time, what are some other cases where it is necessary to use enum instead of immutable? By default use enum if you define a compile-time-known value, unless it's composed data like an array, etc. Bye, bearophile 'enum' as a manifest constant keyword has been an unpopular decision from its introduction. Everybody agrees that it should be changed. Everybody but Walter -- at DConf2014 Walter said (again) that using enum was okay because people get used to it! The only reason given is that re-using a keyword is supposed to be easier than introducing a new one. That is manifestly false. ;)
Re: Casting Structs
On Saturday, 31 May 2014 at 22:34:45 UTC, Timon Gehr wrote:
On 06/01/2014 12:25 AM, Ali Çehreli wrote:
dec10 little = cast(dec10(bingo));
You meant cast(dec10)(bingo).
assert(little == dec10(123.45));
Is this expected behavior?
Paul
That is surprising. I've discovered that if the template has
members
that depend on a template parameter than the code fails to
compile. I
think it should fail to compile in other cases as well because
a
separate instantiation of a template is a separate type
potentially with
completely different invariants.
This behaviour is independent of templates. Struct values of
the same size can be reinterpret-cast to each other this way
even if their types are completely unrelated.
struct A{
int a,b;
}
struct B{
long x;
}
void main(){
auto a=A();
auto b=cast(B)a;
}
So, although this works it is undocumented and will probably be
modified at some point. I won't use it and I'll file a bug report
if I can't find one that covers it already. Thanks for your help.
