www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - How to declare "type of function, passed as an argument, which should

reply Gavin Ray <user example.com> writes:
Brief question, is it possible to write this so that the "alias 
fn" here appears as the final argument?

   auto my_func(alias fn)(string name, string description, auto 
otherthing)

The above seems to work, since the type of "fn" can vary and it 
gets called inside of "my_func", but from an ergonomics point I'd 
love to be able to put the function last and write it inline:

   my_func("name", "description", "otherthing", (x, y, z) {
     auto foo = 1;
     return foo + 2;
   })


Currently I am calling it like:

   auto some_func = (x, y, z) {
     auto foo = 1;
     return foo + 2;
   };

   my_func!some_func("name", "description", "otherthing");

Which is fine, it's just that from a readability perspective it 
doesn't really allow for writing the function inline and you need 
to declare it separately.

Not a huge deal, just learning and thought I would ask =)

Thank you!
Mar 29
next sibling parent reply =?UTF-8?Q?Ali_=c3=87ehreli?= <acehreli yahoo.com> writes:
On 3/29/21 8:13 AM, Gavin Ray wrote:

 Brief question, is it possible to write this so that the "alias fn" here
 appears as the final argument?

    auto my_func(alias fn)(string name, string description, auto 
otherthing) Yes, as a type template parameter but you would have to constrain the parameter yourself (if you care): import std.stdio; import std.traits; import std.meta; auto myFunc(F)(string name, F func) { // This condition could be a template constraint but they don't // support error messages. static assert (is (Parameters!func == AliasSeq!(string)), "'func' must be a callable that takes 'string'."); return func(name); } void main() { // One trouble with this "solution" is that for the compiler to // know the return type of the lambda, the parameter must be // declared as 'string' (in this case). writeln(myFunc("foo", (string a) => a ~ '.')); } Ali
Mar 29
parent reply Paul Backus <snarwin gmail.com> writes:
On Monday, 29 March 2021 at 16:20:59 UTC, Ali Çehreli wrote:
 auto myFunc(F)(string name, F func)
 {
   // This condition could be a template constraint but they 
 don't
   // support error messages.
   static assert (is (Parameters!func == AliasSeq!(string)),
                  "'func' must be a callable that takes 
 'string'.");
   return func(name);
 }

 void main() {
   // One trouble with this "solution" is that for the compiler 
 to
   // know the return type of the lambda, the parameter must be
   // declared as 'string' (in this case).
   writeln(myFunc("foo", (string a) => a ~ '.'));
 }

 Ali
Alternatively: auto myFunc(F)(string name, F func) { static assert (__traits(compiles, (string s) => func(s)), "'func' must be a callable that takes 'string'."); return func(name); } void main() { // No need to write out the argument type writeln(myFunc("foo", a => a ~ '.')); } You can generalize this into a helper template: enum bool isCallableWith(alias fun, ArgTypes...) = __traits(compiles, (ArgTypes args) => fun(args)); Usage: static assert(isCallableWith!(func, string));
Mar 29
parent Gavin Ray <user example.com> writes:
On Monday, 29 March 2021 at 16:31:49 UTC, Paul Backus wrote:
 On Monday, 29 March 2021 at 16:20:59 UTC, Ali Çehreli wrote:
 auto myFunc(F)(string name, F func)
 {
   // This condition could be a template constraint but they 
 don't
   // support error messages.
   static assert (is (Parameters!func == AliasSeq!(string)),
                  "'func' must be a callable that takes 
 'string'.");
   return func(name);
 }

 void main() {
   // One trouble with this "solution" is that for the compiler 
 to
   // know the return type of the lambda, the parameter must be
   // declared as 'string' (in this case).
   writeln(myFunc("foo", (string a) => a ~ '.'));
 }

 Ali
Alternatively: auto myFunc(F)(string name, F func) { static assert (__traits(compiles, (string s) => func(s)), "'func' must be a callable that takes 'string'."); return func(name); } void main() { // No need to write out the argument type writeln(myFunc("foo", a => a ~ '.')); } You can generalize this into a helper template: enum bool isCallableWith(alias fun, ArgTypes...) = __traits(compiles, (ArgTypes args) => fun(args)); Usage: static assert(isCallableWith!(func, string));
------------------------------------------------------------------------ Ah that was even easier than I had made it out to be, thank you folks! The part about needing to define the argument types to the lambda is no problem either (it was a silly transcription mistake on my end). I actually need those argument types for later, to generate code based on them (translating D arg types -> a subset of C types, for building a translated function signature string to give to another app) so it works out =D Much appreciated.
Mar 29
prev sibling parent reply evilrat <evilrat666 gmail.com> writes:
On Monday, 29 March 2021 at 15:13:04 UTC, Gavin Ray wrote:
 Brief question, is it possible to write this so that the "alias 
 fn" here appears as the final argument?

   auto my_func(alias fn)(string name, string description, auto 
 otherthing)

 The above seems to work, since the type of "fn" can vary and it 
 gets called inside of "my_func", but from an ergonomics point 
 I'd love to be able to put the function last and write it 
 inline:

   my_func("name", "description", "otherthing", (x, y, z) {
     auto foo = 1;
     return foo + 2;
   })


 Currently I am calling it like:

   auto some_func = (x, y, z) {
     auto foo = 1;
     return foo + 2;
   };

   my_func!some_func("name", "description", "otherthing");

 Which is fine, it's just that from a readability perspective it 
 doesn't really allow for writing the function inline and you 
 need to declare it separately.

 Not a huge deal, just learning and thought I would ask =)

 Thank you!
Also with delegates (lazy), you get the type checks however you must have to declare parameters on call site, which can be PITA in the future when doing refactoring will be necessary. Better plan ahead as the number of changes will explode when you make quite a number of these and decide to change params/returns. ``` import std.stdio; void my_func(T, XS)(string a, string b, string c, lazy T function(XS)[] t...) { // call function, just the first one, can call all of them as well t[0](a); // can get the result too, mind the future refactoring needs tho // T res = t[0](); } void main() { my_func("name", "description", "otherthing", (string x) { writeln(x); return x; }); // no function, compile error // my_func("name", "description", "otherthing"); } ```
Mar 29
parent reply Gavin Ray <user example.com> writes:
On Monday, 29 March 2021 at 17:02:40 UTC, evilrat wrote:
 Also with delegates (lazy), you get the type checks however you 
 must have to declare parameters on call site, which can be PITA 
 in the future when doing refactoring will be necessary.

 Better plan ahead as the number of changes will explode when 
 you make quite a number of these and decide to change 
 params/returns.

 ```
   import std.stdio;

   void my_func(T, XS)(string a, string b, string c, lazy T 
 function(XS)[] t...)
   {
     // call function, just the first one, can call all of them 
 as well
     t[0](a);

     // can get the result too, mind the future refactoring 
 needs tho
     // T res = t[0]();
   }

   void main()
   {
     my_func("name", "description", "otherthing", (string x) {
       writeln(x);
       return x;
     });

     // no function, compile error
     // my_func("name", "description", "otherthing");
   }
 ```
----------------------------------------------------------------------- Trying to read this function signature: void my_func(T, XS)(string a, string b, string c, lazy T function(XS)[] t...) Does this say "Generic void function 'my_func', which takes two generic/type params "T" and "XS", and is a function of type "string a, string b, string c", and..." (this is where it starts to get hazy for me): How does one interpret/read this: lazy T function(XS)[] t... Also I noticed that no explicit generic types were provided in your call. I assume this means that D's type system is similar to Typescript's then, where it's a logical constraints and will try to "fit the holes" so to speak. In Typescript it works like this: function myFunc<T>(arg: T) {} myFunc(1) // T is inferred to be type "number" myFunc("a") // T is inferred to be type "string" myFunc<number>(1) // Same as above, but explicit, maybe useful if you want to verify arg, else pointless It seems like potentially D is similar here?
Mar 29
parent evilrat <evilrat666 gmail.com> writes:
On Monday, 29 March 2021 at 17:52:13 UTC, Gavin Ray wrote:
 Trying to read this function signature:

     void my_func(T, XS)(string a, string b, string c, lazy T 
 function(XS)[] t...)

 Does this say "Generic void function 'my_func', which takes two 
 generic/type params "T" and "XS", and is a function of type 
 "string a, string b, string c", and..." (this is where it 
 starts to get hazy for me):

 How does one interpret/read this:

    lazy T function(XS)[] t...
A tuple of functions that takes XS argument(s) and returns T. '...' part is a tuple/variadic arguments, however with function it is somewhat wacky and requires an array notation [], otherwise compiler treats it like a mere pointer for some reason, same with t[0]() call. Also even though it says just XS in function parameters it has this special meaning, basically 'argument list'. (you can do cool tricks like this https://dlang.org/phobos/std_traits.html#Parameters) lazy is parameter storage on function argument.
 Also I noticed that no explicit generic types were provided in 
 your call. I assume this means that D's type system is similar 
 to Typescript's then, where it's a logical constraints and will 
 try to "fit the holes" so to speak.

 In Typescript it works like this:

   function myFunc<T>(arg: T) {}
   myFunc(1) // T is inferred to be type "number"
   myFunc("a") // T is inferred to be type "string"
   myFunc<number>(1) // Same as above, but explicit, maybe 
 useful if you want to verify arg, else pointless

 It seems like potentially D is similar here?
I'm not that familiar with TypeScript but it looks close enough except explicit types is not to verify but to force it to be of that type when compiler is too confused or you need to use some specific base class or interface.
Mar 29