Considering something like this:
auto stuff = [1, 2, 3];
struct Foo
{
typeof(stuff.filter!("a != 2")) foo;
this(int = 0)
{
// assume we must initialize foo in ctor,
// for instance because it needs ctor args;
// in this con
Luís Marques:
If the language allowed foo to be declared using auto (which
would be deduced from the assignment in the ctor), that would
be nice, right?
This is a kind of flow typing, it's rather useful but it
introduces several complexities, so I think it's now too much
late to add it to D
On Tuesday, 27 May 2014 at 15:06:53 UTC, bearophile wrote:
BTW, why doesn't this example work with lambdas (a => a != 2)
instead of a string mixin ("a != 2")?
I think lambda instantiations defines a different type. So it's
incompatible.
Incompatible with what? I meant changing it in both the
On Tuesday, 27 May 2014 at 15:40:04 UTC, Luís Marques wrote:
On Tuesday, 27 May 2014 at 15:06:53 UTC, bearophile wrote:
BTW, why doesn't this example work with lambdas (a => a != 2)
instead of a string mixin ("a != 2")?
I think lambda instantiations defines a different type. So
it's incompati
On Tuesday, 27 May 2014 at 15:06:53 UTC, bearophile wrote:
Luís Marques:
If the language allowed foo to be declared using auto (which
would be deduced from the assignment in the ctor), that would
be nice, right?
This is a kind of flow typing, it's rather useful but it
introduces several com
On 5/27/14, 6:26 AM, Idan Arye wrote:
On Tuesday, 27 May 2014 at 15:40:04 UTC, Luís Marques wrote:
On Tuesday, 27 May 2014 at 15:06:53 UTC, bearophile wrote:
BTW, why doesn't this example work with lambdas (a => a != 2)
instead of a string mixin ("a != 2")?
I think lambda instantiations defin
On Tuesday, 27 May 2014 at 17:23:24 UTC, Marc Schütz wrote:
Not necessarily. The first assignment of a member in a
constructor is already treated as special, so I guess we're
halfway there.
That's what I was thinking. *crosses fingers*
On Tuesday, 27 May 2014 at 17:22:43 UTC, Andrei Alexandrescu
wrote:
I think there was either or both a discussion and a bug report
on this, but can't find either. Basically we need to clarify
what it means to compare two function literals for equality. --
Andrei
I remember the thread where th
On 5/27/14, 7:51 AM, Meta wrote:
On Tuesday, 27 May 2014 at 17:22:43 UTC, Andrei Alexandrescu wrote:
I think there was either or both a discussion and a bug report on
this, but can't find either. Basically we need to clarify what it
means to compare two function literals for equality. -- Andrei
On Tue, May 27, 2014 at 08:17:26AM -1000, Andrei Alexandrescu via Digitalmars-d
wrote:
> On 5/27/14, 7:51 AM, Meta wrote:
> >On Tuesday, 27 May 2014 at 17:22:43 UTC, Andrei Alexandrescu wrote:
> >>I think there was either or both a discussion and a bug report on
> >>this, but can't find either. Ba
On Tuesday, 27 May 2014 at 18:54:05 UTC, H. S. Teoh via
Digitalmars-d wrote:
Honestly, I don't see the need even for alpha-renaming -- I
can't
imagine a use case where you'd want to do something like that.
I think
straight up hashing of the function body is Good Enough(tm).
T
Hashing the fu
On Tuesday, 27 May 2014 at 19:39:23 UTC, Idan Arye wrote:
Hashing the function body is not enough - you must also
consider the closure!
template Template(alias func){
bool Template=func();
}
void foo(){
int a;
writeln(Template!(()=>is(typeof(a) : char))); //
On Tuesday, 27 May 2014 at 20:02:34 UTC, Meta wrote:
On Tuesday, 27 May 2014 at 19:39:23 UTC, Idan Arye wrote:
Hashing the function body is not enough - you must also
consider the closure!
template Template(alias func){
bool Template=func();
}
void foo(){
int a;
On Tuesday, 27 May 2014 at 23:18:12 UTC, Idan Arye wrote:
Well, it won't work for the example that opened this
thread(converted to use lambdas).
As for limiting the delegate version to ones that use @pure and
@nogc, take another look at my example. The lambdas don't
allocate anything so they'
On Wednesday, 28 May 2014 at 02:05:43 UTC, Meta wrote:
On Tuesday, 27 May 2014 at 23:18:12 UTC, Idan Arye wrote:
Well, it won't work for the example that opened this
thread(converted to use lambdas).
As for limiting the delegate version to ones that use @pure
and @nogc, take another look at m
On Wednesday, 28 May 2014 at 06:20:29 UTC, Idan Arye wrote:
From what I know(don't know how it is implemented in D. I know
it doesn't work that way in languages that emulate closures
like C++ and Java) delegates don't "allocate a closure" -
rather, they use a the callstack frame that was alread
On Wednesday, 28 May 2014 at 14:06:38 UTC, Meta wrote:
What I meant to say by "allocate a closure" is that variables
in the stack frame that the delegate has a pointer to are moved
to the heap when they go out of scope. I believe this implies
GC allocation, but I'm not 100% sure. If that *were*
On Tuesday, 27 May 2014 at 14:55:33 UTC, Luís Marques wrote:
BTW 2, is `this(int = 0)' the best workaround (still?) for the
fact that I want the ctor to be called, even if it doesn't
really require any parameter?
AFAIK, no, since "Foo()" will actually do nothing. "this(Arg =
dummy)" is actual
18 matches
Mail list logo
