On Sunday, 24 June 2012 at 23:04:14 UTC, Sean Kelly wrote:
On Jun 24, 2012, at 11:40 AM, Jarl André
jarl.an...@gmail.com@puremagic.com jarl.an...@gmail.com
wrote:
Is it wrong to badge myself with asynchronous sockets? :)
Nope. It's pretty weird stuff if you've never done event-based
Wait, you have a template mixin inside of Foo which passes Foo
to it? I don't
know if you can get away with that or not, since you're trying
to pass a type
to a template while you're adding stuff to it via that
template. So, the type
is incomplete. I'm willing to be that that's your problem,
On Monday, June 25, 2012 08:24:59 Namespace wrote:
Wait, you have a template mixin inside of Foo which passes Foo
to it? I don't
know if you can get away with that or not, since you're trying
to pass a type
to a template while you're adding stuff to it via that
template. So, the type
If you don't need to use any compile-time reflection on the
type itself (i.e.
you just need its name), you can use a string mixin.
- Jonathan M Davis
You mean i should pack the whole mixin template in a string?
Isn't that a little bit ugly?
Tobias Pankrath:
Maybe you should post this to the main newsgroup.
I don't know if the main newsgroup is the right place.
I would prefer a switch that does this per scope, i.e:
I think both a compiler switch for the compilation unit, and a
scope pragma to enable/disable locally, are
On Monday, June 25, 2012 10:18:19 Namespace wrote:
If you don't need to use any compile-time reflection on the
type itself (i.e.
you just need its name), you can use a string mixin.
- Jonathan M Davis
You mean i should pack the whole mixin template in a string?
Isn't that a little
Tongzhou Li:
Don't know what it means, I don't call any constructor in Line
19. Then I tried to use class instead of struct
(http://ideone.com/ZI2Tn), it worked fine.
So what's wrong with that?
At first sight your code seems OK.
There is a well known compiler bug that makes it call the
On 25-Jun-12 14:01, bearophile wrote:
Tobias Pankrath:
Maybe you should post this to the main newsgroup.
I don't know if the main newsgroup is the right place.
I would prefer a switch that does this per scope, i.e:
I think both a compiler switch for the compilation unit, and a scope
On Monday, 25 June 2012 at 06:05:34 UTC, Tongzhou Li wrote:
Hello! I'm learning D, and wrote some sample codes with D.
I wrote: http://ideone.com/VY7ES
It failed to compile; I got 2 errors:
main.d(19): Error: constructor
main.carry!(int,int,int,int,int).carry.this (int delegate(int,
int
On Sunday, 24 June 2012 at 13:16:53 UTC, simendsjo wrote:
import std.exception;
import std.traits;
struct Ranged(T, T min, T max) {
T _value = min;
typeof(this) opAssign(V : T)(V value) {
enforce(value = min);
enforce(value = max);
_value = value;
return
On 06/25/2012 02:48 AM, Jonathan M Davis wrote:
On Sunday, June 24, 2012 19:03:17 Namespace wrote:
This might work:
this(U)(U obj)
if(is(U : T) !is(U == typeof(null)))
{
}
- Jonathan M Davis
Interesting. With or wihtout that, if i add a method to Foo it
prints Stack overflow also.
On Monday, June 25, 2012 13:01:47 Timon Gehr wrote:
On 06/25/2012 02:48 AM, Jonathan M Davis wrote:
On Sunday, June 24, 2012 19:03:17 Namespace wrote:
This might work:
this(U)(U obj)
if(is(U : T) !is(U == typeof(null)))
{
}
- Jonathan M Davis
Interesting.
On Monday, 25 June 2012 at 10:08:03 UTC, Dmitry Olshansky wrote:
On 25-Jun-12 14:01, bearophile wrote:
Tobias Pankrath:
Maybe you should post this to the main newsgroup.
I don't know if the main newsgroup is the right place.
I would prefer a switch that does this per scope, i.e:
I
On 25-Jun-12 15:21, Tobias Pankrath wrote:
On Monday, 25 June 2012 at 10:08:03 UTC, Dmitry Olshansky wrote:
On 25-Jun-12 14:01, bearophile wrote:
Tobias Pankrath:
Maybe you should post this to the main newsgroup.
I don't know if the main newsgroup is the right place.
I would prefer a
Fine. But nothing of them explain the Stack overflow if i add an
additional method or disable/add an additional ctor.
Dmitry Olshansky:
Except for the fact, that someone has to implement it.
I am not seeing one of the posts of this thread. So I'll answer
here.
The good thing regarding the run-time overflow integral tests is
that they are already implemented and available as efficient
compiler intrinsics
On Sun, 24 Jun 2012 08:27:00 +0100, Johannes Pfau nos...@example.com
wrote:
Am Sat, 23 Jun 2012 16:51:14 -0700
schrieb Jonathan M Davis jmdavisp...@gmx.com:
On Saturday, June 23, 2012 20:23:26 Johannes Pfau wrote:
I'm working on the new design for std.hash and I hit an interesting
On Sun, 24 Jun 2012 23:52:35 +0200
bearophile bearophileh...@lycos.com wrote:
- Python language is not fit because it's too much slow and
because in certain cases I prefer a little stronger static type
safety, that's useful to not waste time debugging the usage of
intricate data
Am 25.06.2012 14:56, schrieb Gour:
On Sun, 24 Jun 2012 23:52:35 +0200
bearophile bearophileh...@lycos.com wrote:
- Python language is not fit because it's too much slow and
because in certain cases I prefer a little stronger static type
safety, that's useful to not waste time debugging the
import std.range;
struct Element {
//immutable // uncomment to break compilation
int _i;
this(int i) { _i = i; }
}
void main() {
auto arr = [Element.init];
arr.front;
}
Declaring _i immutable yields the following compilation error:
@property ref T front(T)(T[] a)
if (!isNarrowString!(T[]) !is(T[] == void[]))
{
assert(a.length, Attempting to fetch the front of an empty
array of ~
typeof(a[0]).stringof);
return a[0];
}
Why is front returned by ref even when it is not possible to do
so?
On Monday, 25 June 2012 at 10:10:56 UTC, Kenji Hara wrote:
On Monday, 25 June 2012 at 06:05:34 UTC, Tongzhou Li wrote:
Hello! I'm learning D, and wrote some sample codes with D.
I wrote: http://ideone.com/VY7ES
It failed to compile; I got 2 errors:
main.d(19): Error: constructor
On Fri, 01 Jun 2012 18:51:54 -0400, Era Scarecrow rtcv...@yahoo.com
wrote:
On Friday, 1 June 2012 at 21:15:18 UTC, Ali Çehreli wrote:
Don't forget inout, which seems to be working at least in this case:
I'd given up on trying to use inout, being as it's confusing to try
and use, when I
On Sat, 02 Jun 2012 06:49:39 -0400, Dmitry Olshansky
dmitry.o...@gmail.com wrote:
On 02.06.2012 14:39, Kevin Cox wrote:
On Jun 2, 2012 6:38 AM, bearophile bearophileh...@lycos.com
mailto:bearophileh...@lycos.com wrote:
Jonathan M Davis:
Personally, I wish that it weren't legal to
On Monday, June 25, 2012 16:27:20 Roman D. Boiko wrote:
@property ref T front(T)(T[] a)
if (!isNarrowString!(T[]) !is(T[] == void[]))
{
assert(a.length, Attempting to fetch the front of an empty
array of ~
typeof(a[0]).stringof);
return a[0];
}
Why is front
On 06/25/2012 04:27 PM, Roman D. Boiko wrote:
@property ref T front(T)(T[] a)
if (!isNarrowString!(T[]) !is(T[] == void[]))
{
assert(a.length, Attempting to fetch the front of an empty array of ~
typeof(a[0]).stringof);
return a[0];
}
Why is front returned by ref even when it is not possible
On 06/25/2012 02:18 PM, Namespace wrote:
Fine. But nothing of them explain the Stack overflow if i add an
additional method or disable/add an additional ctor.
It does not have to be explained: it is a compiler bug.
On Monday, 25 June 2012 at 15:39:07 UTC, Jonathan M Davis wrote:
On Monday, June 25, 2012 16:27:20 Roman D. Boiko wrote:
@property ref T front(T)(T[] a)
if (!isNarrowString!(T[]) !is(T[] == void[]))
{
assert(a.length, Attempting to fetch the front of an
empty
array of ~
On Monday, 25 June 2012 at 15:39:19 UTC, Timon Gehr wrote:
On 06/25/2012 02:18 PM, Namespace wrote:
Fine. But nothing of them explain the Stack overflow if i add
an
additional method or disable/add an additional ctor.
It does not have to be explained: it is a compiler bug.
Then it will
On Monday, 25 June 2012 at 15:38:09 UTC, Timon Gehr wrote:
It should always be possible to do so. What you are
experiencing seems to be a compiler bug.
I couldn't find it reported before. The closest are:
d.puremagic.com/issues/show_bug.cgi?id=6480
On Monday, 25 June 2012 at 15:58:14 UTC, Roman D. Boiko wrote:
On Monday, 25 June 2012 at 15:38:09 UTC, Timon Gehr wrote:
It should always be possible to do so. What you are
experiencing seems to be a compiler bug.
I couldn't find it reported before. The closest are:
Many of them get fixed quite fast if they are reported properly.
But since I have had other experiences. But no matter.
It is always a compiler bug if compilation crashes.
Only that a simple @disable this(typeof(null)); fails, is crap.
Because so you cannot test at compile time for such
My fault, Ref!(Foo) rf = new Foo(); work as expected.
-
struct A { bool a; alias a this; }
struct B { int b; alias b this; }
A a = false; // works
B b = 12; // works
struct C
{
A aa;
B ab;
}
C c = { false, 12 }; // does not work, because the implicit
conversion does not happen.
-
What is the reason to allow the first two
the function std.file.copy do not overwrite a file if dest already
exist and they are nothing about this into documentation:
http://dlang.org/phobos/std_file.html#copy
maybe a boolean to force copy could help
void copy(in char[] from, in char[] to, in bool force = false);
In any case explain
On Tuesday, June 26, 2012 02:08:00 bioinfornatics wrote:
the function std.file.copy do not overwrite a file if dest already
exist and they are nothing about this into documentation:
http://dlang.org/phobos/std_file.html#copy
maybe a boolean to force copy could help
void copy(in char[]
On Monday, 25 June 2012 at 14:23:25 UTC, Roman D. Boiko wrote:
import std.range;
struct Element {
//immutable // uncomment to break compilation
int _i;
this(int i) { _i = i; }
}
void main() {
auto arr = [Element.init];
arr.front;
}
Declaring _i immutable yields the following
37 matches
Mail list logo
