View mode: basic / threaded / horizontal-split · Log in · Help
January 31, 2011
Re: Partially instantiating templates?
Magnus Lie Hetland:

> Well... I had a tuple return at first, but one of the advantages of 
> returning multiple values that I'm accustomed to is the ability to 
> assign to multiple variables, such as
> 
>   arg, val = minArg(...)
> 
> (Yeah, I'm a Python guy... ;)

I will eventually add a detailed enhancement request on this topic.

Bye,
bearophile
February 01, 2011
Re: Partially instantiating templates?
On 2011-01-31 22:21:40 +0100, bearophile said:

> Magnus Lie Hetland:
[snip]
>> I'm accustomed to is the ability to
>> assign to multiple variables, such as
>> 
>> arg, val = minArg(...)
>> 
>> (Yeah, I'm a Python guy... ;)
> 
> I will eventually add a detailed enhancement request on this topic.

Great! I think this is really useful -- also for swapping things around 
(a, b = b, a). For multiple return values it makes a huge difference, 
IMO.

-- 
Magnus Lie Hetland
http://hetland.org
February 01, 2011
Re: Partially instantiating templates?
On 2011-01-31 19:46:53 +0100, Simen kjaeraas said:

> Magnus Lie Hetland <magnus@hetland.org> wrote:
> 
>> Hm. Using code quite similar to you, supplying a lambda in the second 
>> aliasing, I get this error:
>> 
>> something.d(93): Error: template instance cannot use local 
>> '__dgliteral2(__T3)' as parameter to non-global template optArg(alias 
>> fun)
[snip]
> 
> This is a bug. Please report it.

Ah -- OK. Will do.

-- 
Magnus Lie Hetland
http://hetland.org
February 01, 2011
Re: Partially instantiating templates?
On 2011-02-01 10:11:53 +0100, Magnus Lie Hetland said:

> On 2011-01-31 22:21:40 +0100, bearophile said:
> 
>> Magnus Lie Hetland:
> [snip]
>>> I'm accustomed to is the ability to
>>> assign to multiple variables, such as
>>> 
>>> arg, val = minArg(...)
>>> 
>>> (Yeah, I'm a Python guy... ;)
>> 
>> I will eventually add a detailed enhancement request on this topic.
> 
> Great! I think this is really useful -- also for swapping things around 
> (a, b = b, a). For multiple return values it makes a huge difference, 
> IMO.

Saw your post on digitalmars.D now, about the currying of templates 
(i.e., the main topic here). I guess perhaps that was what you were 
talking about?

That would certainly be great, too :)

-- 
Magnus Lie Hetland
http://hetland.org
February 01, 2011
Re: Partially instantiating templates?
Magnus Lie Hetland:

> Saw your post on digitalmars.D now, about the currying of templates 
> (i.e., the main topic here). I guess perhaps that was what you were 
> talking about?

Tuple unpacking syntax and template currying  are two different things.

Bye,
bearophile
February 01, 2011
Re: Partially instantiating templates?
On 2011-02-01 10:49:23 +0100, bearophile said:

> Magnus Lie Hetland:
> 
>> Saw your post on digitalmars.D now, about the currying of templates
>> (i.e., the main topic here). I guess perhaps that was what you were
>> talking about?
> 
> Tuple unpacking syntax and template currying  are two different things.

Yes, certainly. That was the point of this post -- that I misunderstood 
what you were talking about in the original post (where you said "this 
topic" right after my tuple unpacking paragraph) :)

-- 
Magnus Lie Hetland
http://hetland.org
February 01, 2011
Re: Partially instantiating templates?
On 2011-02-01 10:12:44 +0100, Magnus Lie Hetland said:

> On 2011-01-31 19:46:53 +0100, Simen kjaeraas said:
> 
>> Magnus Lie Hetland <magnus@hetland.org> wrote:
>> 
>>> Hm. Using code quite similar to you, supplying a lambda in the second 
>>> aliasing, I get this error:
>>> 
>>> something.d(93): Error: template instance cannot use local 
>>> '__dgliteral2(__T3)' as parameter to non-global template optArg(alias 
>>> fun)
> [snip]
>> 
>> This is a bug. Please report it.
> 
> Ah -- OK. Will do.

Hm. Just to make sure this *is* a bug, and I'm not just being a dumbass 
... this is a tiny program that illustrates the problem (i.e., gives 
the error above). Perhaps the use of a local function here really is 
prohibited...?

template A(int op) {
   template A(alias fun) {
       auto A(T)(T x) {
           return 0;
       }
   }
}
alias A!0 B;
int gun() {
   return 0;
}
void main() {
   int fun() {return 0;}
   // alias B!((){return 0;}) C; // Won't compile
   // alias B!(fun) C;           // Won't compile
   alias B!(gun) C;              // Works
}

-- 
Magnus Lie Hetland
http://hetland.org
February 01, 2011
Re: Partially instantiating templates?
Magnus Lie Hetland <magnus@hetland.org> wrote:

> Hm. Just to make sure this *is* a bug, and I'm not just being a dumbass  
> ... this is a tiny program that illustrates the problem (i.e., gives the  
> error above). Perhaps the use of a local function here really is  
> prohibited...?

Maybe it is. It really shouldn't be, though. If this is not a bug, then
Walter has a bug for not accepting this as a bug. :p


-- 
Simen
February 01, 2011
Re: Partially instantiating templates?
Magnus Lie Hetland:

> Yes, certainly. That was the point of this post -- that I misunderstood 
> what you were talking about in the original post (where you said "this 
> topic" right after my tuple unpacking paragraph) :)

I will eventually add to bugzilla a request for tuple unpacking syntax, see here:
http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D&article_id=118601

Bye,
bearophile
February 01, 2011
Re: Partially instantiating templates?
On 2011-02-01 12:37:05 +0100, Simen kjaeraas said:

> Magnus Lie Hetland <magnus@hetland.org> wrote:
> 
>> Hm. Just to make sure this *is* a bug, and I'm not just being a dumbass 
>> ... this is a tiny program that illustrates the problem (i.e., gives 
>> the error above). Perhaps the use of a local function here really is 
>> prohibited...?
> 
> Maybe it is. It really shouldn't be, though. If this is not a bug, then
> Walter has a bug for not accepting this as a bug. :p

Hehe :)

Sort of related (though perhaps only remotely) is the following, which 
won't compile (Error: static assert "Bad unary function: f(a) for type 
int"):

 import std.functional, std.stdio;
 int f(int x) {return x;}
 void main() {
     alias unaryFun!("f(a)") g;
     writeln(g(3));
 }

It may not be related -- but I've been trying to use the string 
representation instead of lambda in some places, and I thought maybe a 
similar name lookup problem may be present in the unaryFun template? 
(The detauls of the implementation are a bit beyond me at the moment...)

Maybe there's an unstated restriction against using functions in the 
unaryFun string parameter (at least I couldn't find it in the docs) -- 
but ... there is the following example in the docs for std.algorithms:

 sort!("hashFun(a) < hashFun(b)")(array);

So it would seem like this *should* work?

-- 
Magnus Lie Hetland
http://hetland.org
1 2 3
Top | Discussion index | About this forum | D home