Is this a bug?

Márcio Martins marcioapm at gmail.com
Tue Oct 16 07:21:27 UTC 2018


On Tuesday, 16 October 2018 at 02:13:21 UTC, Ali Çehreli wrote:
> On 10/15/2018 01:36 PM, Márcio Martins wrote:
>
> > Considering that the declaration is legal, and that the
> template
> > parameter deduction works when Args.length == 0, but stops
> working when
> > Args.length > 0.
>
> For deduction to work, there must be function arguments. So, 
> just add Args to the function parameter list and all works:
>
> import std.stdio;
>
> void incx(T, Args...)(ref T t, Args) {  // <-- Added Args
>     ++t.x;
> }
>
> static struct Test(T) {
>     T x;
> }
>
> void main() {
>     Test!uint t;
>     t.incx();
>     t.incx!();
>     incx(t);
>     t.incx(1, 2, 3);           // <-- Removed '!'
>     incx(t, 1, 2, 3);
>     writeln(t.x);
> }
>
> Ali

That's not exactly what I am trying to do.
Maybe I can share that - perhaps you guys know a better way that 
circumvents these:

I am trying to have have a method that takes as arguments a 
key-value pair,
where key is a string, and value is an alias to something 
callable.

So I want to do things like:

t.on!(
   "abc", {
     writeln("abc");
   },

   "cde", {
     writeln("cde");
   }
);

I want to be able to hash the keys at compile time, and have the 
callables not allocate at all.

The problem is that if `on` is a method on the aggregate `t`, 
then I can't do this because i am passing local function literal 
do non global template. I am not sure why this is a limitation, I 
supposed I'd have to dig in the compiler code to find that out. 
It certainly is an unexpected limitation, though.

So I tried to have the `on` be a global function, that has a 
first argument of type T, a template parameter, and then takes a 
compile-time alias sequence of the key-value pairs, as mentioned 
earlier. This mostly works, except that it can't deduce the first 
argument type, and forces me to write it up. The issue is that 
it's a `voldemort` type, and even if wasn't it would be a quite 
complex type to write, and I don't want my users to have to write 
typeof() statements.

How can I best do this? I suppose I could do pass all of it as a 
function argument instead, and have the first argument be 
correctly deduced, but the performance characteristics will be 
massively different, as I can no longer process the strings at 
compile time, and the delegates passed as parameter are 
guaranteed to allocate.

Help me understand if these are actual fundamental limitations, 
bugs, or just the current implementation. It's quite frustrating 
to invest a bunch of hours into a design that intuitively, IMO, 
should work, just to find out it doesn't work due to an arbitrary 
language limitation, and then spend time looking for an 
alternative, and again, hit some intuitive language limitation. 
If I understand the underlying limitation/implementation, I can 
avoid these frustrations in the future.


More information about the Digitalmars-d-learn mailing list