why not use `a[:T]` instead of `a!T`, it's closer to the current syntax.
> It allows you to know at parse time that it's a generic instantiation,
> instead of after semantic phase. This is a big deal, as it would allow macros
> to know that some AST refers to a generic instantiation vs array indexing,
> whereas all you get now is the ambiguous nnkBracketExpr
This is
> That's one of these D myths as far as I'm concerned. It's still ambiguous,
> consider (Y) ! x, is that a type cast plus a unary ! operator or a generic
> instantiation?
it's not ambiguous.
void fun(T)(int a){}
void main(string[]args){
(fun)!double(3); // Error: C style
Well, we already left Nim <1.0 behind and the "free running" or strictly local
type parameters are here to stay with the [T] notation. It might be interesting
to think about module-wide type parameters though (extended scope). With
concept[T], we have (in principle) these in Nim. Haskell has typ
That's one of these D myths as far as I'm concerned. It's still ambiguous,
consider `(Y) ! x`, is that a type cast plus a unary `!` operator or a generic
instantiation?
(Plus the syntax is ugly.)
D has the best syntax here, a!T, a.b!T, a![T1,T2] No ambiguity between normal
and UFCS, and shorter syntax for the common case.
> None of these are perfect, ...
So why change anything... ;-)
> Well you can call printSqured(b) and have its T inferred and that makes all
> the difference.
True. Two different ways around this:
* calling it like this `printSquared()(b)` to indicate the inferred first
parameter list (sucky IMHO) or
* defining it in upper-case
proc Pri
> The most common point brought up is that expressions like
> foo[x](https://forum.nim-lang.org/postActivity.xml) would be ambiguous
The angle bracket version of this isn't great either, in Rust you have to do
`foo::()`, and Java requires you to do `Class.foo()`. Nim could easily
enforce `foo[:
> Solitude is right, but there is another problem with square brackets together
> with UFCS in Nim - a.b[T](https://forum.nim-lang.org/postActivity.xml)
> doesn't work, for that a new syntax extension was introduced -
> a.b[:T](https://forum.nim-lang.org/postActivity.xml) so it's not ambiguou
T
Well you can call `printSqured(b)` and have its `T` inferred and that makes all
the difference.
IMHO, in a meta-programming-heavy language like Nim, there shouldn't even be a
special type of bracket used for generic type parameters, `()` is good enough.
A "generic" just returns a concrete `type` or `proc` when called with type
parameters at compile time. The syntax element for call paramet
Solitude is right, but there is another problem with square brackets together
with UFCS in Nim - a.b[T](https://forum.nim-lang.org/postActivity.xml) doesn't
work, for that a new syntax extension was introduced -
a.b[:T](https://forum.nim-lang.org/postActivity.xml) so it's not ambiguous.
Well, you can't determine that at parse time. Which leads me to believe that
this is possible in Nim precisely because Nim's parser doesn't need to
distinguish between types and values, unlike other languages.
how is that ambiguous? one is collection, other is function.
On many programming subreddits, there are arguments about using square
brackets[] for generics instead of the cumbersome angle<> brackets,
particularly in Rust and Go. The most common point brought up is that
expressions like `foo[x]()` would be ambiguous — is it a generic function call,
16 matches
Mail list logo
