fijal/quill

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
fijal commented

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) { ... }
jml commented

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.

jml commented

I still like def foo() -> Type nicer to read than def 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.

fijal commented

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 :-)

fijal commented

So it's settled on foo: Int. I'm closing that one