[RFC] default type parameter for generics

[timotheecour]

These should be supported IMO:

with typedesc (EDIT this one now works)

proc foo6(T:typedesc = typedesc[int]): auto = return T.name
echo foo6(int) # (or int.foo6) ok
echo foo6() #ok
echo foo6(string) # Error: type mismatch: got <type int> but expected 'type string'

with generics

proc foo3[T=string](): auto = return T.name
echo foo3() # Error: cannot instantiate: 'T'
echo foo3[]() # Error: type mismatch: got <proc [*missing parameters*](): untyped>

links

mentioned here: nim-lang/Nim#3502 (comment)

I like the idea of default generic parameters, maybe named ones like parse[Dest = int] could be cool too. Is there an RFC for this?

[andreaferretti]

I think your first example should be

import typetraits

proc foo6(T:typedesc = typedesc[int]): auto = return T.name
echo foo6(int) #ok
echo foo6(string) # Error: type mismatch: got  but expected 'type string'
echo foo6()

[timotheecour]

thanks, updated typos and clarified

[bluenote10]

It looks like this is working now on devel. Can be closed?

[andreaferretti]

@bluenote10 The version with typedesc works. The version with generics does not work currently on devel, but in fact it does not even look like valid nim. @zah ?

[timotheecour]

@zah thanks for addressing typedesc default params!

The version with generics does not work currently on devel, but in fact it does not even look like valid nim. @zah ?

well, currently Nim allows this proc foo3[T=string](): auto = return T.name but fails upon instantiation as shown in OP. I don't see why it shouldn't be supported though, it's a standard features in languages that have generics (eg C++, D, ... even typescript); not all though, eg not C#; it's being planned for swift (see https://github.com/apple/swift/blob/master/docs/GenericsManifesto.md)

[zah]

Default generic parameters are supported for types. For procs, they might be implemented at some point, but given the current compiler internals that would be a complicated patch, so I don't see this coming soon. More details here:
https://github.com/nim-lang/Nim/issues/7517#issuecomment-380272387

My recommendation is to stick with type (formerly typedesc) params as they have better overloading support.

[dom96]

Why should this be supported? What is a use case that warrants this feature?

[timotheecour]

Why should this be supported? What is a use case that warrants this feature?

myParser[T = DefaultType](a:string)

However, given all the recent improvements to typedesc that happened since this bug was created, I'm in support of the following plan:

• close this issue (https://github.com/nim-lang/Nim/issues/7516) as wontifx (once proc foo3[T=string]() = discard gives a compile error; it currently doesn't which is inconsistent), and clarify in docs that generics won't support default values
• close https://github.com/nim-lang/Nim/issues/7529 ([RFC] partial generic deduction #7529) as wontfix
• close https://github.com/nim-lang/Nim/issues/7517, settling once and for all in favor of guidelines provided here by @zah :

1. Use generic types for generic value params, where the types will be inferred from the call-site
2. Use typedesc for all params that must be explicitly specified by the user.

After that we can finally start profiting:

• revive [WIP] first pass at fixing #7430: universal to conversion template Nim#7488 to get started on Adding parse support in the stdlib, cf this comment form @Araq :

Adding parse support in the stdlib is fine once the "typedesc vs generic parameter" fight is settled though.

• merge @PMunch's PR Add ByteStream and generic read proc to streams Nim#7481 (Add ByteStream and generic read proc to streams #7481) the way he wrote it using typedesc (modulo addressing other comments if applicable)

[timotheecour]

/cc @Araq @dom96 @zah ping on this: ok to settle #7517 and go on a closing rampage as suggested above ?

[Clyybber]

I don't think we should rush too much here and close valid issues as wontfix just because fixing them will take longer/might be difficult.

[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.