Open glhrmfrts opened 8 years ago
please, use always-matching brackets, not c++-style c++
@vendethiel sorry, but can you give an example?
Sorry, i meant <>
, which are not always matched... Making parsing harder.
Yeah I don't see much sense in that being unmatched. Anyway, this syntax is very ugly to me:
map<string, int>{
"number": 2
}
But i can't think of anything else.
"Being unmatched" => they are when you use it as comparison operators.
map[string, int]{...}
map!(string, int){...}
(d-style)
I think if luna have a type inference, the syntax will be cool:
{"foo": "bar"} => map<string, string>
{"foo": "bar", "alist": [1, 2, 3]} => map<string, interable<any>>
{"foo": "bar", "truth": 42} => map<string, any>
But I think this will be a large project 😅
very, very large indeed. And can be very surprising – see Scala.
@vendethiel Yes, may be this is not luna's target simple, elegant, explicit
haha
@vendethiel Oh I see now :p
But maybe <>
would be easier than square brackets (because of subscript), unless it's context-dependent and we do some semantic analysis later.
@aisk Maybe it's possible to a large project achieve simplicity? lol
@glhrmfrts I think it's not just too complex to implement, but with this design luna's type system may be more complex, and make it more hard too learn and use.
Indeed, a more strict type system might be good for both sides.
I just noticed that the parser currently accepts only identifiers as a hash literal key, e.g.:
I think that when this was implemented it was meant to be temporary, but since Luna is planned to be a statically typed language I think we need to define a syntax for generic types.