lter does.
The combining and filtering is interesting (in this case, it'd be like doing
a list comprehension).
But the real challenge in the SO question is the 'going back in time' part,
which I have trouble to understand : how can you modify x and y through a
multiplication and
On Sat, Sep 4, 2010 at 23:55, bearophile wrote:
>
> It computes the result (ghc-6.8.2) in 0.93s using only 8.7 MB of memory.
>
OK, so that may the difference between GHCi and GHC proper. Less than 1s is
impressive.
I see I have GHC 6.12.3 on my system. I may give this code a try one day. I
tend
Philippe Sigaud wrote:
I guess the D syntax would be
auto x = amb([1,2,3]);
auto y =amb([4,5,6]);
x*y == 8; // forces desambiguation => the ambs explore the possibilities.
assert(x == amb([2]));
assert(y == amb([4]));
There is only one value left, no more ambiguity.
But what happens in the c
Philippe Sigaud:
>It's crystal clear & short (but we should aim for J! :-), but being lazy I
>don't see how it can use less memory than a strict version of the same algo.
>Got to store all those thunks somewhere.<
I have appreciated how the Haskell version allows me to generate a sequence
lazi
On Fri, Sep 3, 2010 at 21:43, bearophile wrote:
> Don:
> > That's not a very useful problem, because the timing depends entirely on
> > BigInt, which is completely unoptimised for small values.
>
> You are usually right, but this time what you say is useless. There are
> other means to judge how
On Sat, Sep 4, 2010 at 01:40, Simen kjaeraas wrote:
> Simen kjaeraas wrote:
>
> I believe this will only work with arrays as input. Either that, or I need
>> a way to make this work:
>>
>> struct Foo( R ) if ( isForwardRange!R ) {
>> bool delegate( ElementType!R ) bar;
>> Filter!( bar,
Simen kjaeraas wrote:
I believe this will only work with arrays as input. Either that, or I
need
a way to make this work:
struct Foo( R ) if ( isForwardRange!R ) {
bool delegate( ElementType!R ) bar;
Filter!( bar, R ) range;
}
Or, well, something like it. I need a static type for
Philippe Sigaud wrote:
Now, the 'real'/intriguing/mind-bending amb operator (from the 60's) does
like the Haskell implementation linked in SO does: backtracking on the
results to avoid some condition. If someone is up to the challenge of
implementing it in D, great! Maybe w
Peter Alexander wrote:
== Quote from Simen kjaeraas (simen.kja...@gmail.com)'s article
Yes, very much so. However, Peter Alexander has misunderstood the
ambiguous operator.
Hey, I was just going by what the guy posted :) He mentioned
nothing of tuples, and his examples certainly didn't show
Don:
> Well, I would hate for somebody to waste their time trying to optimise
> that problem either for speed or memory consumption, when both are
> limited by a fairly simple, short-term library issue.
What is the short-term Phobos issue that limits the memory usage? In the
current Phobos2 I h
bearophile wrote:
Don:
That's not a very useful problem, because the timing depends entirely on
BigInt, which is completely unoptimised for small values.
You are usually right, but this time what you say is useless. There are other
means to judge how good a program is, beside running time:
-
Don:
> That's not a very useful problem, because the timing depends entirely on
> BigInt, which is completely unoptimised for small values.
You are usually right, but this time what you say is useless. There are other
means to judge how good a program is, beside running time:
- Total line count
== Quote from Don (nos...@nospam.com)'s article
> That's not a very useful problem, because the timing depends entirely on
> BigInt, which is completely unoptimised for small values.
True, but it would be nice to get it as concise as Haskell's.
In an ideal world, we'd simply write it as:
auto H(
On Fri, Sep 3, 2010 at 16:30, Justin Johansson wrote:
> On 02/09/10 05:38, Philippe Sigaud wrote:
>
>> Hey, this question on SO makes for a good challenge:
>>
>>
>> http://stackoverflow.com/questions/3608834/is-it-possible-to-generically-implement-the-amb-operator
for you? As I said, here with
2.048, it doesn't.
Now, the 'real'/intriguing/mind-bending amb operator (from the 60's) does
like the Haskell implementation linked in SO does: backtracking on the
results to avoid some condition. If someone is up to the challenge of
implementing it in
bearophile wrote:
Justin Johansson:
Bearophile, if you are reading this perhaps you might like
to repost some of you previous "challenges" which have not
received much attention with the [challenge] annotation in
the subject line.
See:
http://www.digitalmars.com/webnews/news
== Quote from Simen kjaeraas (simen.kja...@gmail.com)'s article
> Yes, very much so. However, Peter Alexander has misunderstood the
> ambiguous operator.
Hey, I was just going by what the guy posted :) He mentioned
nothing of tuples, and his examples certainly didn't show any
tuples.
Justin Johansson:
> Bearophile, if you are reading this perhaps you might like
> to repost some of you previous "challenges" which have not
> received much attention with the [challenge] annotation in
> the subject line.
See:
http://www.digitalmars.com/webnews/ne
On 02/09/10 05:38, Philippe Sigaud wrote:
Hey, this question on SO makes for a good challenge:
http://stackoverflow.com/questions/3608834/is-it-possible-to-generically-implement-the-amb-operator-in-d
It's great to see someone doing the first D discussion topic
with the [challenge] annot
Philippe Sigaud wrote:
Hey, this question on SO makes for a good challenge:
http://stackoverflow.com/questions/3608834/is-it-possible-to-generically-implement-the-amb-operator-in-d
The amb operator does this:
amb([1, 2]) * amb([3, 4, 5]) == amb([3, 4, 5, 6, 8, 10])
amb(["hello&quo
== Quote from Nick Sabalausky (a...@a.a)'s article
> Interesting thing, but devil's advocate: What would be the
uses/benefits of
> that versus just having "for each element" versions of the
operators?
Well the obvious benefit is that you don't have to create all
those extra version -- you get them
"Nick Sabalausky" wrote in message
news:i5p68t$2pt...@digitalmars.com...
> "Philippe Sigaud" wrote in message
> news:mailman.42.1283371696.858.digitalmar...@puremagic.com...
>> Hey, this question on SO makes for a good challenge:
>>
>> http://stacko
"Philippe Sigaud" wrote in message
news:mailman.42.1283371696.858.digitalmar...@puremagic.com...
> Hey, this question on SO makes for a good challenge:
>
> http://stackoverflow.com/questions/3608834/is-it-possible-to-generically-implement-the-amb-operator-in-d
>
> T
On Thu, Sep 2, 2010 at 09:06, Peter Alexander
wrote:
> On 2/09/10 7:34 AM, Pelle wrote:
>
>> It needs opEquals :-)
>>
>
> Yeah, it needs a lot of things :)
>
> You could easily add unary operators as well (e.g. so that -amb([1, 2]) ==
> [-1, -2]. I didn't bother adding more than I did because it w
On 2/09/10 7:34 AM, Pelle wrote:
It needs opEquals :-)
Yeah, it needs a lot of things :)
You could easily add unary operators as well (e.g. so that -amb([1, 2])
== [-1, -2]. I didn't bother adding more than I did because it would
make the post too large, and wouldn't really add anything (I t
On 09/01/2010 11:49 PM, Peter Alexander wrote:
On 1/09/10 9:08 PM, Philippe Sigaud wrote:
Peter, can we discuss your solution here?
Sure, I'd be interested to hear any improvements. Like I said in my
answer, I'm still learning D so I'm sure there's many issues. For
example, I made no attempt f
On 1/09/10 9:08 PM, Philippe Sigaud wrote:
Peter, can we discuss your solution here?
Sure, I'd be interested to hear any improvements. Like I said in my
answer, I'm still learning D so I'm sure there's many issues. For
example, I made no attempt for const-correctness or anything like that
(m
Hey, this question on SO makes for a good challenge:
http://stackoverflow.com/questions/3608834/is-it-possible-to-generically-implement-the-amb-operator-in-d
The amb operator does this:
amb([1, 2]) * amb([3, 4, 5]) == amb([3, 4, 5, 6, 8, 10])
amb(["hello", "world"]) ~ am
On Sat, 27 Feb 2010 04:56:00 -0500, Norbert Nemec
wrote:
Robert Jacques wrote:
That sounds sensible. However, extensive experience in Matlab has
taught me that resorting to custom for-loop indicates you've failed to
sufficiently think in arrays. :)
Indeed, most use cases are simple enou
Robert Jacques wrote:
That sounds sensible. However, extensive experience in Matlab has taught
me that resorting to custom for-loop indicates you've failed to
sufficiently think in arrays. :)
Indeed, most use cases are simple enough to be handled in array
notation. I have worked with Matlab a
On Fri, 26 Feb 2010 10:49:30 -0500, Norbert Nemec
wrote:
Ary Borenszweig wrote:
Norbert Nemec wrote:
Hi everybody,
thinking about array expressions, I have stumbled over an interesting
challenge for which I still have no idea:
Consider the mathematical sum notation:
\sum_i a_i
On Fri, 26 Feb 2010 03:58:59 -0500, Norbert Nemec
wrote:
Robert Jacques wrote:
Well there is std.algorithm's map and reduce. Somehow, I feel slicing,
ranges/generators and array expressions should be able to handle this.
For example: \sum_i i*a_i*b_i-1 => sum(iota * a * b[1..$]) But then
On Fri, Feb 26, 2010 at 10:07, Norbert Nemec wrote:
> Jason House wrote:
>
>> Would sum!( "i", "a[i]*b[i]" ) be acceptable? That should be achievable
>> with a template mixin that does string mixins under the hood.
>>
>
> It is indeed a solution for the problem, but I still don't like it too
> muc
Ary Borenszweig wrote:
Norbert Nemec wrote:
Hi everybody,
thinking about array expressions, I have stumbled over an interesting
challenge for which I still have no idea:
Consider the mathematical sum notation:
\sum_i a_i*b_i
here, the variable i is defined only at the scope inside the
Norbert Nemec wrote:
Hi everybody,
thinking about array expressions, I have stumbled over an interesting
challenge for which I still have no idea:
Consider the mathematical sum notation:
\sum_i a_i*b_i
here, the variable i is defined only at the scope inside the expression.
A
Norbert Nemec wrote:
Jason House wrote:
Would sum!( "i", "a[i]*b[i]" ) be acceptable? That should be
achievable with a template mixin that does string mixins under the hood.
It is indeed a solution for the problem, but I still don't like it too
much. For one, writing expressions as strings al
"Jason House" wrote in message
news:hm75nn$1a2...@digitalmars.com...
> Norbert Nemec Wrote:
>
>> Hi everybody,
>>
>> thinking about array expressions, I have stumbled over an interesting
>> challenge for which I still have no idea:
>>
>> Cons
Daniel Keep wrote:
BLADE may also be of some interest to you.
http://www.dsource.org/projects/mathextra/browser/trunk/blade
Thanks for the hint! I had seen BLADE sometimes before, but I realize
that I should really study it in more detail.
Jason House wrote:
Would sum!( "i", "a[i]*b[i]" ) be acceptable? That should be achievable with a
template mixin that does string mixins under the hood.
It is indeed a solution for the problem, but I still don't like it too
much. For one, writing expressions as strings always feels awkward. E
Robert Jacques wrote:
Well there is std.algorithm's map and reduce. Somehow, I feel slicing,
ranges/generators and array expressions should be able to handle this.
For example: \sum_i i*a_i*b_i-1 => sum(iota * a * b[1..$]) But then
again I'm having trouble thinking of real examples off the top
On Thu, 25 Feb 2010 18:57:32 -0500, Norbert Nemec
wrote:
Hi everybody,
thinking about array expressions, I have stumbled over an interesting
challenge for which I still have no idea:
Consider the mathematical sum notation:
\sum_i a_i*b_i
here, the variable i is defined only at
BLADE may also be of some interest to you.
http://www.dsource.org/projects/mathextra/browser/trunk/blade
Norbert Nemec Wrote:
> Hi everybody,
>
> thinking about array expressions, I have stumbled over an interesting
> challenge for which I still have no idea:
>
> Consider the mathematical sum notation:
>
> \sum_i a_i*b_i
>
> here, the variable i is define
Hi everybody,
thinking about array expressions, I have stumbled over an interesting
challenge for which I still have no idea:
Consider the mathematical sum notation:
\sum_i a_i*b_i
here, the variable i is defined only at the scope inside the expression.
A analogous D syntax could
Guillaume B. wrote:
Andrei Alexandrescu wrote:
For starters, I'd like to present you with the following challenge.
Given any class C, e.g.:
class C
{
void foo(int) { ... }
int bar(string) { ... }
}
define a template class Finalize(T) such that Finalize!(C) is the same
a
Andrei Alexandrescu wrote:
>
> For starters, I'd like to present you with the following challenge.
> Given any class C, e.g.:
>
> class C
> {
> void foo(int) { ... }
> int bar(string) { ... }
> }
>
> define a template class Finalize(T) such
在 Tue, 19 May 2009 05:29:09 +0800，Jarrett Billingsley
写道:
On Mon, May 18, 2009 at 5:12 PM, Jarrett Billingsley
wrote:
...
Aaand for contrast, if we had __ident and static foreach:
final class Finalize(T) : T
{
this(T...)(T args) if(is(typeof(new T(args { super(args); }
Daniel Keep wrote:
These magic tuples have a horrible habit of losing this invisible extra
information when you so much as think about them. I didn't realise you
could safely index them.
What bothers me more is that as far as I can work out,
ParameterTuple!(T) shouldn't exist in D in its curre
Andrei Alexandrescu wrote:
> Daniel Keep wrote:
>> ...
>>
>> It's hardly fair to issue a challenge which can only be completed [1]
>> with an unreleased compiler only you have seen.
>
> I don't have 2.031 and I don't know whether it will fix t
.
It doesn't work. Let me guess: 2.031. :P
It's hardly fair to issue a challenge which can only be completed [1]
with an unreleased compiler only you have seen.
I don't have 2.031 and I don't know whether it will fix the template
constructor bug.
Actually, that *still
Ary Borenszweig wrote:
> Jarrett Billingsley wrote:
>> ... For
>> the love of all that is holy, can we PLEASE get something like
>> __ident("blah")? This would be so much easier and would probably
>> drastically reduce my use of string mixins in general.
>
> Better __traits(ident, "blah")?
Th
t; I was about to say the same thing.
>>
>
> It doesn't work. Let me guess: 2.031. :P
It's hardly fair to issue a challenge which can only be completed [1]
with an unreleased compiler only you have seen.
Actually, that *still* isn't going to cut it: it won't handle r
Andrei Alexandrescu wrote:
Christopher Wright wrote:
Andrei Alexandrescu wrote:
I think you need to operate exclusively with string mixins in
Finalize, so __ident would be of marginal help there. Also, static
foreach is much more necessary.
That is a huge problem.
Let's say that the class y
Christopher Wright wrote:
Andrei Alexandrescu wrote:
I think you need to operate exclusively with string mixins in
Finalize, so __ident would be of marginal help there. Also, static
foreach is much more necessary.
That is a huge problem.
Let's say that the class you want to finalize, Target,
On Mon, May 18, 2009 at 6:54 PM, Christopher Wright wrote:
> Andrei Alexandrescu wrote:
>>
>> I think you need to operate exclusively with string mixins in Finalize, so
>> __ident would be of marginal help there. Also, static foreach is much more
>> necessary.
>
> That is a huge problem.
>
> Let's
Andrei Alexandrescu wrote:
I think you need to operate exclusively with string mixins in Finalize,
so __ident would be of marginal help there. Also, static foreach is much
more necessary.
That is a huge problem.
Let's say that the class you want to finalize, Target, has a method like
this:
Frits van Bommel wrote:
Andrei Alexandrescu wrote:
Good point! Now define Unfinalize that opens the final methods of a
class for method overriding.
class A
{
final int foo(string) { ... }
}
class UnfinalizeA : A
{
int foo(string a) { return super.foo(a); }
}
DMD rightly doesn't allo
Jarrett Billingsley wrote:
The second is worse. __ctor (if it exists) is not virtual, so it's
not possible to get a list of overloads of it with __traits. One of
two things has to change: either __traits needs a way to get overloads
of nonvirtual functions (that seems like an incredible oversig
Jarrett Billingsley wrote:
On Mon, May 18, 2009 at 12:12 PM, Andrei Alexandrescu
wrote:
Have at it!
Well? Where's my cookie? ;)
As soon as I'm coming off my prostration and awe engendered by your
solution, I'll reply to that. I have to admit, though, that Denis'
insight sort of took th
On Mon, May 18, 2009 at 12:12 PM, Andrei Alexandrescu
wrote:
> Have at it!
Well? Where's my cookie? ;)
Jarrett Billingsley wrote:
> On Mon, May 18, 2009 at 2:57 PM, Andrei Alexandrescu
> wrote:
>> Andrei Alexandrescu wrote:
>>> I don't think "out" is doable.
>> I take that back. It is doable. The code below prints "void function(out int
>> _param_0)":
>>
>> struct S
>> {
>>void blah(out int) {}
Andrei Alexandrescu wrote:
Good point! Now define Unfinalize that opens the final methods of a
class for method overriding.
class A
{
final int foo(string) { ... }
}
class UnfinalizeA : A
{
int foo(string a) { return super.foo(a); }
}
DMD rightly doesn't allow this:
---
test.d(8): Er
On Mon, May 18, 2009 at 5:12 PM, Jarrett Billingsley
wrote:
> ...
Aaand for contrast, if we had __ident and static foreach:
final class Finalize(T) : T
{
this(T...)(T args) if(is(typeof(new T(args { super(args); }
static foreach(member; __traits(allMembers, T))
On Mon, May 18, 2009 at 5:12 PM, Jarrett Billingsley
wrote:
> Weird bug: if one of your methods takes a single int parameter (no
> more, no less, and it has to be 'int', no other basic type triggers
> it), DMD inserts a spurious pair of parens in the .stringof, as in
> "void function((int))", cau
On Mon, May 18, 2009 at 12:12 PM, Andrei Alexandrescu
wrote:
> Ok, now with the advent (or rediscovery) of allMembers which I had no idea
> existed, we're ready to start some serious butt-kick reflection facilities.
>
> For starters, I'd like to present you with the foll
u with the following challenge.
Given any class C, e.g.:
class C
{
void foo(int) { ... }
int bar(string) { ... }
}
define a template class Finalize(T) such that Finalize!(C) is the same
as the following hand-written class:
final class FinalizeC : C
{
final void foo(int a) { return s
On Mon, May 18, 2009 at 5:02 PM, Denis Koroskin <2kor...@gmail.com> wrote:
>
> template Finalize(T)
> {
> final class Finalize : T
> {
> this(Args...)(Args args)
> {
> super(args);
> }
> }
> }
>
> The following code /should/ work as you ask. There is no need to ite
On Mon, 18 May 2009 20:12:40 +0400, Andrei Alexandrescu
wrote:
Ok, now with the advent (or rediscovery) of allMembers which I had no
idea existed, we're ready to start some serious butt-kick reflection
facilities.
For starters, I'd like to present you with the following
On Mon, May 18, 2009 at 3:14 PM, Andrei Alexandrescu
wrote:
>
> Submit a bug report asking for documentation.
http://d.puremagic.com/issues/show_bug.cgi?id=3007
> You'd be able to whine to an
> eskimo that there's too much snow on your sidewalk.
The squeaky wheel gets the grease.
On Mon, May 18, 2009 at 3:11 PM, Andrei Alexandrescu
wrote:
>> No, you showed me how ctors would be done if I had a
>> correctly-functioning compiler. Which I don't.
>
> I'm not seeing the bugzilla you submitted.
Oh look at that, someone's already reported it.
http://d.puremagic.com/issues/sho
On Mon, 18 May 2009 14:37:51 -0400, Andrei Alexandrescu
wrote:
Steven Schveighoffer wrote:
Back to your idea...
This feature that you suggest seems very trivial for the compiler to
implement, while extremely hard to do it via reflection.
The problem is, there are a million things that a
Jarrett Billingsley wrote:
On Mon, May 18, 2009 at 2:55 PM, Andrei Alexandrescu
wrote:
I just showed you how to do ctors.
No, you showed me how ctors would be done if I had a
correctly-functioning compiler. Which I don't.
I'm not seeing the bugzilla you submitted.
I know how to do ref b
Jarrett Billingsley wrote:
On Mon, May 18, 2009 at 2:57 PM, Andrei Alexandrescu
wrote:
Andrei Alexandrescu wrote:
I don't think "out" is doable.
I take that back. It is doable. The code below prints "void function(out int
_param_0)":
struct S
{
void blah(out int) {}
}
void main()
{
wr
On Mon, May 18, 2009 at 2:57 PM, Andrei Alexandrescu
wrote:
> Andrei Alexandrescu wrote:
>>
>> I don't think "out" is doable.
>
> I take that back. It is doable. The code below prints "void function(out int
> _param_0)":
>
> struct S
> {
> void blah(out int) {}
> }
>
> void main()
> {
> writ
On Mon, May 18, 2009 at 2:55 PM, Andrei Alexandrescu
wrote:
> I just showed you how to do ctors.
No, you showed me how ctors would be done if I had a
correctly-functioning compiler. Which I don't.
> I know how to do ref but why don't you do
> your due diligence.
My "due dilligence"? I wasn't
Andrei Alexandrescu wrote:
I don't think "out" is doable.
I take that back. It is doable. The code below prints "void function(out
int _param_0)":
struct S
{
void blah(out int) {}
}
void main()
{
writeln(typeof(&S.blah).stringof);
}
Andrei
Jarrett Billingsley wrote:
On Mon, May 18, 2009 at 2:48 PM, Andrei Alexandrescu
wrote:
Then implement Finalize. Too much foreplay.
I thought it was already established that it's currently impossible.
Ctors? Ref/out params? Hello?
I just showed you how to do ctors. I know how to do ref bu
u with the following challenge. Given
any class C, e.g.:
class C
{
void foo(int) { ... }
int bar(string) { ... }
}
define a template class Finalize(T) such that Finalize!(C) is the same as
the following hand-written class:
final class FinalizeC : C
{
final void foo(int a) { return super.foo(a);
On Mon, May 18, 2009 at 2:48 PM, Andrei Alexandrescu
wrote:
>
> Then implement Finalize. Too much foreplay.
I thought it was already established that it's currently impossible.
Ctors? Ref/out params? Hello?
Jarrett Billingsley wrote:
On Mon, May 18, 2009 at 2:34 PM, Andrei Alexandrescu
wrote:
I think you need to operate exclusively with string mixins in Finalize, so
__ident would be of marginal help there. Also, static foreach is much more
necessary.
I have used string mixins extensively in my
On Mon, May 18, 2009 at 2:34 PM, Andrei Alexandrescu
wrote:
> I think you need to operate exclusively with string mixins in Finalize, so
> __ident would be of marginal help there. Also, static foreach is much more
> necessary.
I have used string mixins extensively in my own code, not just in thi
Steven Schveighoffer wrote:
Back to your idea...
This feature that you suggest seems very trivial for the compiler to
implement, while extremely hard to do it via reflection.
The problem is, there are a million things that are trivial for the
compiler to implement and harder with libraries.
Jarrett Billingsley wrote:
On Mon, May 18, 2009 at 2:20 PM, Andrei Alexandrescu
wrote:
I want this too, but first let's become able to do things we can't do and
then to do things we can do, easier. The __ident thing has been on the table
for literally years, I seem to recall I called it new ali
On Mon, 18 May 2009 12:12:40 -0400, Andrei Alexandrescu
wrote:
Ok, now with the advent (or rediscovery) of allMembers which I had no
idea existed, we're ready to start some serious butt-kick reflection
facilities.
For starters, I'd like to present you with the following
On Mon, May 18, 2009 at 2:20 PM, Andrei Alexandrescu
wrote:
>
> I want this too, but first let's become able to do things we can't do and
> then to do things we can do, easier. The __ident thing has been on the table
> for literally years, I seem to recall I called it new alias("blah").
I'm more
Jarrett Billingsley wrote:
On Mon, May 18, 2009 at 1:23 PM, Jarrett Billingsley
wrote:
The first is a more general statement about trying to generate
functions with D's metaprogramming. It is a huge pain in the ass to
actually create a function with a given name, because the only way
that I k
On Mon, May 18, 2009 at 1:23 PM, Jarrett Billingsley
wrote:
> The first is a more general statement about trying to generate
> functions with D's metaprogramming. It is a huge pain in the ass to
> actually create a function with a given name, because the only way
> that I know this can be done i
Christian Kamm wrote:
Unless there's been a change in D2 I have missed, I don't think you can
forward functions with ref/out or default arguments correctly unless you
parse certain mangles or stringofs.
Time for a bug report.
Andrei
See
http://d.puremagic.com/issues/show_bug.cgi?id=1818
or
>> Unless there's been a change in D2 I have missed, I don't think you can
>> forward functions with ref/out or default arguments correctly unless you
>> parse certain mangles or stringofs.
>>
>>
>
> Time for a bug report.
>
> Andrei
See
http://d.puremagic.com/issues/show_bug.cgi?id=1818
or th
Christian Kamm wrote:
Andrei Alexandrescu wrote:
Ok, now with the advent (or rediscovery) of allMembers which I had no
idea existed, we're ready to start some serious butt-kick reflection
facilities.
For starters, I'd like to present you with the following challenge.
Unless ther
Andrei Alexandrescu wrote:
> Ok, now with the advent (or rediscovery) of allMembers which I had no
> idea existed, we're ready to start some serious butt-kick reflection
> facilities.
>
> For starters, I'd like to present you with the following challenge.
Unless ther
Andrei Alexandrescu wrote:
Jarrett Billingsley wrote:
On Mon, May 18, 2009 at 1:48 PM, Andrei Alexandrescu
wrote:
Jarrett Billingsley wrote:
The second is worse. __ctor (if it exists) is not virtual, so it's
not possible to get a list of overloads of it with __traits.
This is a simple one:
On Mon, May 18, 2009 at 1:57 PM, Jarrett Billingsley
wrote:
> On Mon, May 18, 2009 at 1:56 PM, Bill Baxter wrote:
>>
>> When did templated constructors start being allowed?! I see nothing
>> about it in the change log.
>
> I was about to say the same thing.
>
It doesn't work. Let me guess: 2.0
On Mon, May 18, 2009 at 1:56 PM, Bill Baxter wrote:
>
> When did templated constructors start being allowed?! I see nothing
> about it in the change log.
I was about to say the same thing.
On Mon, May 18, 2009 at 10:53 AM, Andrei Alexandrescu
wrote:
> Jarrett Billingsley wrote:
>>
>> On Mon, May 18, 2009 at 1:48 PM, Andrei Alexandrescu
>> wrote:
>>>
>>> Jarrett Billingsley wrote:
The second is worse. __ctor (if it exists) is not virtual, so it's
not possible to get
Jarrett Billingsley wrote:
On Mon, May 18, 2009 at 1:48 PM, Andrei Alexandrescu
wrote:
Jarrett Billingsley wrote:
The second is worse. __ctor (if it exists) is not virtual, so it's
not possible to get a list of overloads of it with __traits.
This is a simple one:
final class Finalize(C) : C
On Mon, May 18, 2009 at 1:48 PM, Andrei Alexandrescu
wrote:
> Jarrett Billingsley wrote:
>>
>> The second is worse. __ctor (if it exists) is not virtual, so it's
>> not possible to get a list of overloads of it with __traits.
>
> This is a simple one:
>
> final class Finalize(C) : C
> {
> this
Jarrett Billingsley wrote:
The second is worse. __ctor (if it exists) is not virtual, so it's
not possible to get a list of overloads of it with __traits.
This is a simple one:
final class Finalize(C) : C
{
this(A...)(A args) if (is(new C(args))
{
super(args);
}
}
Andrei
On Mon, May 18, 2009 at 12:12 PM, Andrei Alexandrescu
wrote:
> Ok, now with the advent (or rediscovery) of allMembers which I had no idea
> existed, we're ready to start some serious butt-kick reflection facilities.
>
> For starters, I'd like to present you with the foll
Ok, now with the advent (or rediscovery) of allMembers which I had no
idea existed, we're ready to start some serious butt-kick reflection
facilities.
For starters, I'd like to present you with the following challenge.
Given any class C, e.g.:
class C
{
void foo(int) { ... }
401 - 500 of 506 matches
Mail list logo
