I don't think that _exactly_ would have survived but since we use .0 etc for tuple access I think arrays coulda been the same.
Conversation
Oh yeah, I think `()` for indexing like in Scala is fine too.
2
2
I love that collection access in scala looks like a function call like that.
2
2
how does Scala solve for making indexable user collections anyways?
3
1
I think the call operator is overloadable?
1
1
Kind of like in Rust, with the `Fn` traits (which are not yet overloadable in stable Rust due to the lack of variadic type params)
1
1
I'm gonna be honest with you if we have anything but arity overloading I am rioting.
1
2
not/1 and not/2: cool
two different not/1s: pistols at dawn
1
2
sorry, not sure I follow… is this a Prolog reference? Was more talking:
trait Fn<Input, ..., Output> { ... }
or:
trait Fn<(Input, ...), Output> { ... }
Seems like a tricky thing to figure out though, so I'm not holding my breath it will be available soon…
I guess that _would_ however possibly let folks sneak in function overloading based on the argument types/arities if you aren't careful though. Ie. statically dispatching multiple impls on a marker struct. Not sure if you could avoid this by using associated types instead…
1
1
I remember goofing around with this for funsies back when the Fn traits were added, and I don't think I was the only one!
2
it is common in many languages to notate functions as
name/arity
to disambiguate between the functions with the same name but different arity. Prolog, yes, but also Erlang and Elixir.
1
1
Also Mercury! 😊 I think the notation comes from Prolog, Elixir by way of Erlang.
1
2
Show replies