[RFC] partial generic deduction

[timotheecour]

@Araq @dom96 @siliconvoodoo

Nim should support partial generic deduction.

• this matters, eg for allowing "true".to[bool] (otherwise it's not DRY, eg: "true".to[bool, string] ), cf https://github.com/nim-lang/Nim/issues/7430 and other use cases

• if partial generic deduction is not on the roadmap, it will cause https://github.com/nim-lang/Nim/issues/7517 ([RFC] guidelines for when to use typedesc vs generics) to be in clear favor of using typedesc, which, as discussed there, is not ideal.

# D20180406T122342
import typetraits

proc test_IFTI() =
  ## full IFTI
  proc foo[T](a:T): auto = return a*a
  echo foo 10

  ## partial IFTI

  ### proc
  proc foo1[T, T2](a:T2): auto = return T.name & ":" & T2.name
  echo foo1[string, int](10)
  when false:
    echo foo1[string](10) # Error: cannot instantiate: foo1[string]; got 1 type(s) but expected 2
    echo 10.foo1[string]() #  Error: cannot instantiate: 'T'

  ## side issue: named generic parametes
  when false:
    echo foo1[T:string](10) #  Error: invalid expression: 'T: string'
    echo foo1[T:string, T2:int](10) #  Error: invalid expression: 'T: string'
    echo 10.foo1[T:string]() #  Error: cannot instantiate: 'T'

  ### template
  template foo2[T, T2](a:T2): auto = T.name & ":" & T2.name
  echo foo2[string, int](10)
  echo foo2[string](10)
  when false:
    echo 10.foo2[string] # Error: cannot instantiate: 'T'

  ## workaround with typedesc
  template foo3[T2](a:T2, T: typedesc): auto = T.name & ":" & T2.name
  echo 10.foo3(string)

test_IFTI()

in C++ this works:

template<typename T, typename T2>
void fun(const T2& a){}

void test(){
  fun<float>(10);
}

in D this works and used extensively

void fun(T, T2)(T2 a){}
void test(){
  fun!string(10); // same as fun!(string)(10)
}

[andreaferretti]

I think that partial generic deduction unnecessarily complicates the language for the user. I would be very confused to see a call like "true".to[bool] when to is actually declared with two type parameters.

Which parameter gets bound to bool? Notice that the semantic here would be something like: the one which is not automatically inferred by the compiler. This seems to me brittle and confusing (it is completely unlike, say, a default value)

[siliconvoodoo]

@andreaferretti agreed and disagreed.
agreed: that's why I suggested named parameters to help this issue, just like other parameters. You could even make it forbidden to use partial deduction if the explicit parameters are left unnamed. Further, like python 3.5; variadic parameters could be accepted in conjunction with defaults and named parameters.

"true".to[Dst:bool] this way you are sure where it binds to in proc to[Src, Dst](Src s)
or I don't know, how about:
"true".to[_, bool]
Or left as a style choice (I like freedom):
proc to[Src, Dst](Src s) {.NoDeduceEllipsis.}

disagreed: man, the users are programmers, not the next idiot, they are used to rules and stuff done by the compiler. If C++ and D does it, you can assume that's probably not an unreasonable feature. When the tutos/manual/book are correctly written then the behavior is understandable and usable. The issue left is readability; that can either, be left as a style choice to the "user", to name or not his leftover explicit parameters; or be forced as stated in previous paragraph.
Also, this is Nim, not BASIC; a language that requires you to understand things like AST, and the difference between lexers and parsers, and know enough C too...

[data-man]

fmt template supports a custom format procs with an options.
to template can be implemented in a similar way.

[andreaferretti]

@siliconvoodoo I like "true".to[_, bool]. That said, this use case is perfectly covered by typedesc parameters today.

I know there are rules and people can follow them, but this is not a good reason to make them unnecessarily confusing.

[siliconvoodoo]

@andreaferretti

this use case is perfectly covered by typedesc parameters today.

ah ? ok, I don't know enough about Nim, can you show me a snippet that'd do it ?

[andreaferretti]

They are spelled out in this issue

[github-actions]

This RFC is stale because it has been open for 1095 days with no activity. Contribute a fix or comment on the issue, or it will be closed in 7 days.