On 2012-09-11 07:57, Chris Cain wrote:
Ah, I see now.
Well regardless, it couldn't be done so conveniently/transparently
because Serializable!B wouldn't exist in the binary unless it was
actually created in code.
Hence proper runtime reflection is needed. I see no way out of this.
--
/Jacob
On 09/10/2012 02:49 AM, monarch_dodra wrote:
On Sunday, 9 September 2012 at 23:54:45 UTC, Jonathan M Davis
wrote:
[SNIP]
the default assignment operator illegal. You could overload it, and as
long as
it doesn't touch any of the const member variables, it would work, but
the
const member
On Tuesday, 11 September 2012 at 09:00:15 UTC, Ali Çehreli wrote:
On 09/10/2012 02:49 AM, monarch_dodra wrote:
On Sunday, 9 September 2012 at 23:54:45 UTC, Jonathan M Davis
wrote:
[SNIP]
the default assignment operator illegal. You could overload
it, and as
long as
it doesn't touch any
This is related to:
http://d.puremagic.com/issues/show_bug.cgi?id=5193
Basically:
---
struct S
{
const int i;
}
struct C(T)
{
private T val;
@property void front(T value)
{val = value;} //HERE
}
void main()
{
C!S test;
}
I wrote a generic template C(T), with a
monarch_dodra:
Is this not the case for D? Or is it currently a limitation?
In this case I think D is working as designed. All functions
inside a template are created when you instantiate it.
Can I ever expect we'll get a conditionally compiled on
requirement functionality for template
Hi.
I would like some sample code which demonstrates how can I modify
a DirectX 9 texture. (C++ or D, doesn't matter.) I have a
texture, like a billboard, and I would like to draw on that.
I already looked on google, on different gamedev sites etc.
haven't fount a working solution. I try
On Tuesday, 11 September 2012 at 11:33:05 UTC, bearophile wrote:
This doesn't look bad, just remember this doesn't work:
struct C(T) {
private T val;
@property void front()(T value) {
val = value;
}
}
void main() {
C!int ci;
auto f = ci.front;
assert(ci.val ==
On Tuesday, 11 September 2012 at 11:33:05 UTC, bearophile wrote:
monarch_dodra:
Is this not the case for D? Or is it currently a limitation?
In this case I think D is working as designed. All functions
inside a template are created when you instantiate it.
[SNIP]
Bye,
bearophile
Well,
monarch_dodra:
and forces the implementer to think about the required
conditions to use the function,
I think this is usually considered a good practice in D, just
like using template constraints.
If you look in Phobos, similar situations are handled with static
ifs. As example see the
On Tuesday, 11 September 2012 at 13:33:08 UTC, bearophile wrote:
monarch_dodra:
and forces the implementer to think about the required
conditions to use the function,
I think this is usually considered a good practice in D, just
like using template constraints.
If you look in Phobos,
On 09/10/2012 10:50 PM, Russel Winder wrote:
Python 2 and Python 3 are totally different in this regard. I don't have
a obvious proposal to make to avoid having PyD for Python 2 and a
different PyD for Python 3, but the six package might have some hints as
it is intended to support creating
monarch_dodra:
I'd argue it's horrible! Why should the coder bother making
these conditional, if calling them would have failed anyways?
If you see, some of those static ifs also have an else clause.
Bye,
bearophile
On Tuesday, September 11, 2012 15:12:57 monarch_dodra wrote:
On Tuesday, 11 September 2012 at 11:33:05 UTC, bearophile wrote:
monarch_dodra:
Is this not the case for D? Or is it currently a limitation?
In this case I think D is working as designed. All functions
inside a template are
On Tuesday, 11 September 2012 at 15:35:33 UTC, bearophile wrote:
monarch_dodra:
I'd argue it's horrible! Why should the coder bother making
these conditional, if calling them would have failed anyways?
If you see, some of those static ifs also have an else clause.
Bye,
bearophile
The only
On Tuesday, 11 September 2012 at 15:43:56 UTC, Jonathan M Davis
wrote:
Anything inside a template is not compiled unless the template
is
instantiated, but if the template is instantiated, the entire
template is
instantiated and compiled (save for static if branches which
aren't followed
or
On Tuesday, 11 September 2012 at 16:34:33 UTC, monarch_dodra
wrote:
At the very least, I wish we could write:
struct S(T)
{
@property void front(T value)
if(isAssignable!(T,T))
{
...
}
}
..Yeah... that wouldn't work would it?
That would just
On Tuesday, 11 September 2012 at 10:51:35 UTC, monarch_dodra
wrote:
[SNIP]
One of my gripes was that the static if creates a new block,
which brakes a struct/class's natural flow. The code gets
indented, the DDoc gets placed further away from the function's
name, teh condition gets placed kind
On Tuesday, September 11, 2012 19:37:02 monarch_dodra wrote:
However, when written like this:
struct C(T)
{
private T val;
// Gets front
@property T front()
{val = value;}
//Writes to front
static if(isAssignable!(T,T))
@property void
I have this code, but it works not as expected:
http://dpaste.dzfl.pl/6ce5b4dd
I get 0 instead of 42 if my type is Int.
My value is correct (as you can see) but writeln prints still 0
instead of 42.
I think auto compiles first to float and cannot handle then
integers.
Am I right? And could
On 09/11/2012 11:10 AM, Namespace wrote:
I have this code, but it works not as expected:
http://dpaste.dzfl.pl/6ce5b4dd
I get 0 instead of 42 if my type is Int.
My value is correct (as you can see) but writeln prints still 0
instead of 42.
I think auto compiles first to float and cannot
On Tuesday, 11 September 2012 at 17:52:44 UTC, Jonathan M Davis
wrote:
On Tuesday, September 11, 2012 19:37:02 monarch_dodra wrote:
However, when written like this:
struct C(T)
{
private T val;
// Gets front
@property T front()
{val = value;}
//Writes to front
On Tue, 2012-09-11 at 10:40 -0700, Ellery Newcomer wrote:
how do you pass compiler flags through scons?
e.g. -unittest, -property
Depends on the SConstruct (and optionally SConscript), but you need to
get a list of the options into the DFLAGS of the environment you are
compiling in.
--
On 09/11/2012 11:40 AM, Namespace wrote:
Here is a reduced code:
import std.stdio;
enum Type { Int, Float }
auto foo(Type t)
{
final switch (t) {
case Type.Int:
return 42;
case Type.Float:
return 1.5;
}
}
void main()
{
writeln(foo(Type.Int));
writeln(foo(Type.Float));
}
The
That's not what i want. I would avoid casting if it's possible.
I hope it is a bug and will fixed in 2.061.
On Tuesday, 11 September 2012 at 18:32:47 UTC, Ali Çehreli wrote:
Here is a reduced code:
I guess it may be reduced to:
auto foo(bool val)
{
if (val)
return 42;
else
return 1.5;
}
void main()
{
assert(foo(true) == 42); // assertion failure
assert(foo(false) == 1.5);
On Tue, 11 Sep 2012 20:48:25 +0200, Ali Çehreli acehr...@yahoo.com wrote:
Or you can write or find a template that produces the largest type among
the members of a union.
std.traits.CommonType.
--
Simen
I think it is UB rather than a bug. The spec says that return
types must match exactly. AFAIK auto is a feature to infer
return type, not to magically adjust to multiple incompatible
types.
But i thought Variant is one. ;)
On 09/11/2012 11:42 AM, Russel Winder wrote:
On Tue, 2012-09-11 at 10:40 -0700, Ellery Newcomer wrote:
how do you pass compiler flags through scons?
e.g. -unittest, -property
Depends on the SConstruct (and optionally SConscript), but you need to
get a list of the options into the DFLAGS of
On Tuesday, 11 September 2012 at 19:03:56 UTC, Namespace wrote:
I think it is UB rather than a bug. The spec says that return
types must match exactly. AFAIK auto is a feature to infer
return type, not to magically adjust to multiple incompatible
types.
But i thought Variant is one. ;)
I
With multiple alias this this should work.
int getInt() const { return this.ivalue; }
alias getInt this;
float getFloat() const { return this.fvalue; }
alias getFloat this;
Or with a class method for implicit conversion.
On Tuesday, 11 September 2012 at 19:07:52 UTC, Simen Kjaeraas
wrote:
On Tue, 11 Sep 2012 20:57:07 +0200, Maxim Fomin
ma...@maxim-fomin.ru wrote:
I think it is UB rather than a bug. The spec says that return
types must match exactly. AFAIK auto is a feature to infer
return type, not to
On 09/11/2012 08:57 PM, Maxim Fomin wrote:
I think it is UB rather than a bug.
No, this is a bug.
The spec says that return types must match exactly.
Exactly. If it was UB, the spec would say the behaviour is undefined if
they don't match exactly.
AFAIK auto is a feature to infer
On 09/11/2012 09:29 PM, Namespace wrote:
On Tuesday, 11 September 2012 at 19:27:40 UTC, Timon Gehr wrote:
On 09/11/2012 08:57 PM, Maxim Fomin wrote:
I think it is UB rather than a bug.
No, this is a bug.
The spec says that return types must match exactly.
Exactly. If it was UB, the spec
Ah ok. That's sad.
On Tuesday, 11 September 2012 at 19:35:58 UTC, Timon Gehr wrote:
According to the spec it should fail compilation.
After rethinking it I agree that bug is in faulty compilation
(assuming spec is correct), not in returning zero at runtime,
which was thought previously.
My final implementation:
http://dpaste.dzfl.pl/4d2a045a
Any suggestions?
Namespace:
I have this code, but it works not as expected:
http://dpaste.dzfl.pl/6ce5b4dd
I suggest to file a bug:
auto foo(bool b) {
final switch (b) {
case true:
return 10;
case false:
return 20.0;
}
}
void main() {
import std.stdio:
On Tuesday, 11 September 2012 at 21:13:02 UTC, bearophile wrote:
Namespace:
I have this code, but it works not as expected:
http://dpaste.dzfl.pl/6ce5b4dd
I suggest to file a bug:
auto foo(bool b) {
final switch (b) {
case true:
return 10;
case false:
11.09.2012 22:48, Ali Çehreli пишет:
return to!(ReturnType!(typeof(foo)))(42);
typeof(return)
See http://dlang.org/declaration.html#typeof
Anyway don't use it as a type of the first return. You will get:
---
Error: cannot use typeof(return) inside function foo with inferred
return
On Tuesday, September 11, 2012 20:39:55 monarch_dodra wrote:
Is one of these what you are suggesting?
//One
static if(isAssignable!(T,T)) @property void front(T value)
{
enforce(someCondition)
value = value;
}
or
//Two
static if(isAssignable!(T,T))
@property void
On Tuesday, September 11, 2012 23:31:43 Namespace wrote:
Sure that is the first i will do tomorrow.
But so far no suggestions?
Use a cast. auto _cannot_ be different types depending on what you return. It
must always resolve to the same type. So, in this case, either it needs to
resolve to
Namespace:
But so far no suggestions?
This seems to work, but solutions that use cast() are sometimes
fragile (and dangerous):
auto foo(bool b) {
final switch (b) {
case false:
return 20.0;
case true:
return cast(typeof(return))10;
}
}
void
On Tuesday, September 11, 2012 23:55:40 bearophile wrote:
Namespace:
But so far no suggestions?
This seems to work, but solutions that use cast() are sometimes
fragile (and dangerous):
auto foo(bool b) {
final switch (b) {
case false:
return 20.0;
On Tuesday, September 11, 2012 15:14:43 Jonathan M Davis wrote:
If you're going to use a cast, then use one where you give the type
explicitly. Using typeof(return) is just asking for it when the compiler is
clearly already having issues with the return type.
And actually, in all honesty, I
You mean so?
ref Variant get() {
return this._num; // with Variant _num;
}
alias get this;
and then:
int i = zahl.get!int?
No. Then I use my solution as you can see on DPaste. If Variant
works only this way I can also set float to the return type an
cast if I need to int.
And with my
On Wednesday, September 12, 2012 00:29:32 Namespace wrote:
You mean so?
ref Variant get() {
return this._num; // with Variant _num;
}
alias get this;
and then:
int i = zahl.get!int?
No. Then I use my solution as you can see on DPaste. If Variant
works only this way I can also set
On Tuesday, 11 September 2012 at 21:31:17 UTC, Namespace wrote:
On Tuesday, 11 September 2012 at 21:13:02 UTC, bearophile wrote:
Namespace:
I have this code, but it works not as expected:
http://dpaste.dzfl.pl/6ce5b4dd
I suggest to file a bug:
auto foo(bool b) {
final switch (b) {
On 09/05/2012 07:10 PM, bearophile wrote:
Ellery Newcomer:
Yep.
Oh, good.
Have any suggestions for supported conversion out of the box?
There are several important cases, like:
Some D lazy ranges == Python lazy iterators/generators
array.array == D arrays
NumPy arrays == D arrays
48 matches
Mail list logo
