Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[RFC] partial generic deduction #86

Closed
timotheecour opened this issue Apr 6, 2018 · 7 comments
Closed

[RFC] partial generic deduction #86

timotheecour opened this issue Apr 6, 2018 · 7 comments
Labels

Comments

@timotheecour
Copy link
Member

@Araq @dom96 @siliconvoodoo

Nim should support partial generic deduction.

# 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)
}
@timotheecour timotheecour changed the title [RFC] partial template deduction [RFC] partial generic deduction Apr 6, 2018
@andreaferretti
Copy link

andreaferretti commented Apr 9, 2018

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
Copy link

siliconvoodoo commented Apr 9, 2018

@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
Copy link

data-man commented Apr 9, 2018

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

@andreaferretti
Copy link

@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
Copy link

siliconvoodoo commented Apr 9, 2018

@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
Copy link

They are spelled out in this issue

@narimiran narimiran transferred this issue from nim-lang/Nim Jan 13, 2019
@github-actions
Copy link

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.

@github-actions github-actions bot added the Stale label Jun 15, 2023
@github-actions github-actions bot closed this as not planned Won't fix, can't repro, duplicate, stale Jul 15, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

4 participants