Type name vs name: Type
Closed this issue · 8 comments
This is a meta issue to explore to bikeshed how types are declared.
Options
var variable: Type = ...;
var variable = ...;
const CONSTANT: Type = ...;
const CONSTANT = ...;
// vs
var variable = ...;
Type variable = ...;
const CONSTANT = ...;
const Type CONSTANT = ...;
Type variable
This would be closer to what C# uses. The upsides there are that it traditionally is more familiar to users and it means that var
is a standin for the type for gradual typing. You can replace var
with a type to make it explicit.
The downsides are that it can be harder to parse and that constants might be a bit more confusing. This syntax might look a bit confusing for explicitly typed class members.
variable: Type
This is what Rust, JavaScript and others are using now. The upside is easier to parse and that the variable name is always in the same position. Downsides is that it's less familiar to C/C# programmers and might be more confusing.
Personally not particularly sure about this one. I did a twitter poll about what people think not mentioning the language: https://twitter.com/mitsuhiko/status/888296650271313920
58% int foo
42% foo: int
741 votes
I definitely prefer "int foo". I don't think parsing is a serious issue cough
When the type is optional, I think the suffix is easier to keep consistent across different places in the syntax:
var foo: Type = ...
def bar(a: T, b: U): Type { ... }
vs something like
Type foo = ...
Type bar(T a, U b) { ... }
or
var Type foo = ...
def Type bar(T a, U b) { ... }
Other reason for foo: int
(side: can it be foo int
?) is that it can make the types of functions easier to read.
fn filter(fn(a): bool, [a]): bool
vs
[a] filter(bool fn(a), [a])
The former emphasises the pipeline-ish nature of functions. (This argument stolen from Go's Declaration Syntax).
I still like def foo() -> Type
nicer to read than def foo(): Type
though.
I still like
def foo() -> Type
nicer to read thandef foo(): Type
though.
Yeah, me too, but I like def foo() Type
best of all. It's one of the few things that I prefer about Go.
Note that def foo() -> Str
does not really preclude Str foo
. It does break symmetry, but only a little bit. I definitely dislike var Str foo
, but var is unnecessary here, you can just say Str foo
. Please explain to me how exactly tab-completion gets better with types being after though :-)
So it's settled on foo: Int. I'm closing that one