You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
If you want to write a function that works on a span(integer), it's trivial: you just accept the value and use it. If you want to write a function that works on a span of any type, you have higher-effort options with some downsides:
edit the function into the make_spanT that creates all of the specialized functions. (downside: your function can't go where you wanted to put it. You have to 'upstream' it.)
accept an auto instead (downside: callsite type inference is less helpful, you can start passing arrays when you wanted to construct a span() and pass that)
write a concept that handles type inference and has appropriate errors (downside: this is more work, it's less clear what you're intending)
write your own generic type and have callers specialize it to pull out the function (downside: lots of ceremony for the caller to do vs. calling a function, and the caller very easily hits "cannot do type cast on generics" errors)
Currently that's a "cannot do type cast on generics" error, but it seems like reasonable syntax. Trying to avoid that error exposes others:
print(@spanlength(byte)('hello')) -- unclosed parenthesisprint((@spanlength(byte))('hello')) -- error in generic instantiation: expected a symbol holding a type in generic return, but got something else
This feels more like D or C++ style generics with a second set of arguments, but it retains the flexibility of the current system to specialize arbitrarily over multiple types or values.
Alternatives
Accepting auto in generic parameters. This is natural for the simple case, but you still have to add explicit checks if you want, for example, two spans of the same inner type.
Zig-like generics: permitting comptime type arguments to appear elsewhere in the function parameters. This is also flexible but more verbose when the type inferencer might not need the help.
require'span'localfunctionspanlength(T: type <comptime>, sp: span(T))
return#spendprint(spanlength(byte, 'hello'))
The text was updated successfully, but these errors were encountered:
Feature motivation
If you want to write a function that works on a
span(integer)
, it's trivial: you just accept the value and use it. If you want to write a function that works on a span of any type, you have higher-effort options with some downsides:edit the function into the
make_spanT
that creates all of the specialized functions. (downside: your function can't go where you wanted to put it. You have to 'upstream' it.)accept an
auto
instead (downside: callsite type inference is less helpful, you can start passing arrays when you wanted to construct aspan()
and pass that)write a concept that handles type inference and has appropriate errors (downside: this is more work, it's less clear what you're intending)
write your own generic type and have callers specialize it to pull out the function (downside: lots of ceremony for the caller to do vs. calling a function, and the caller very easily hits "cannot do type cast on generics" errors)
Feature description
Skip the need for the dummy record and its metafield:
Currently that's a "cannot do type cast on generics" error, but it seems like reasonable syntax. Trying to avoid that error exposes others:
This feels more like D or C++ style generics with a second set of arguments, but it retains the flexibility of the current system to specialize arbitrarily over multiple types or values.
Alternatives
auto
in generic parameters. This is natural for the simple case, but you still have to add explicit checks if you want, for example, two spans of the same inner type.The text was updated successfully, but these errors were encountered: