From e53057417ac72dbf4e83b1b5a60b38d37c20e5b2 Mon Sep 17 00:00:00 2001 From: Daniel Fagnan Date: Mon, 30 Jun 2014 18:46:59 -0600 Subject: [PATCH 01/11] New syntax proposal --- active/0000-square-brackets.md | 64 ++++++++++++++++++++++++++++++++++ 1 file changed, 64 insertions(+) create mode 100644 active/0000-square-brackets.md diff --git a/active/0000-square-brackets.md b/active/0000-square-brackets.md new file mode 100644 index 00000000000..e3bce6ebc86 --- /dev/null +++ b/active/0000-square-brackets.md @@ -0,0 +1,64 @@ +- Start Date: 2014-06-30 +- RFC PR #: (leave this empty) +- Rust Issue #: (leave this empty) + +# Summary + +Switching (back) the current type parameter syntax from `<>` to `[]`. + +# Motivation + +Recently there has been a lot of talks on simplifying the syntax. Starting from removing the sigils `@` and `~` and making lifetimes less syntax heavy (through various proposals). I think changing the current generic syntax to `[]` will make it that much better and clearer (`[]` is much easier to read). + +1. We would remove the current ambiguities surround the current syntax `<>`. That means, we could be able to have: + +```rust +struct Vec[T] { + // ... +} + +fn foo[T]() -> Vec[T] { + // ... +} + +fn main() { + let something = foo[int](); +} +``` + +2. `[]` composes **much** better than the more cryptic `<>` form. This is a common readability issue when working with any nested types (such as encoders and decoders). + +```rust +fn parse['a, T: Encodable[Encoder['a], IoError]](value: T) { + // ... +} +``` + +3. It would bring the ability to have much nicer syntax when dealing with HKTs (there are a few different proposals I have in mind in terms of syntax, but it's mostly inferred.). + +```rust +// Possible syntax for HKTs. +pub trait Monad[M[T]] { + // ... +} +``` + +4. There's precendence for it. Scala's syntax for generics is awesome. It imposes very little effort when reading and understanding. + +5. Somewhat related to the first point in that it would bring a consistent syntax for generic everywhere. No more `foo::<>()` that tends to confuse people (not those already aware of the syntax, of course). + +6. Because it's consistent and has no ambiguities, one can finally use motions like `%` in Vim (and alternatives in other editors.). + +# Detailed design + +This is a very easy change to make. + +## Downsides + +* The syntax is used quite a bit. Automation could potentially do some, if not most of the changes (The tricky part is the ambiguities in the current syntax) + +# Alternatives + +* Keep it like it currently is and end up with the current syntax forever. + +# Unresolved questions From 69620ab6b7eb7a840263bbf9705ce088bd6689d3 Mon Sep 17 00:00:00 2001 From: Daniel Fagnan Date: Mon, 30 Jun 2014 18:49:13 -0600 Subject: [PATCH 02/11] Unresolved questions --- active/0000-square-brackets.md | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/active/0000-square-brackets.md b/active/0000-square-brackets.md index e3bce6ebc86..2d5478d0372 100644 --- a/active/0000-square-brackets.md +++ b/active/0000-square-brackets.md @@ -55,10 +55,12 @@ This is a very easy change to make. ## Downsides -* The syntax is used quite a bit. Automation could potentially do some, if not most of the changes (The tricky part is the ambiguities in the current syntax) +* The syntax is used quite a bit. Automation could potentially do some, if not most of the changes (The tricky part is the ambiguities in the current syntax). However, of the changes we've had in the past, I think this syntax change is a whole lot easier to work with than semantic changes, or more complex syntax changes. # Alternatives * Keep it like it currently is and end up with the current syntax forever. # Unresolved questions + +* Why was did Rust originally have `[]` but decided to switch to `<>`? I heard it was related to try and be consistent with C-class languages (C++, Java, etc...), is this correct? From af716da0d71fa0b421aea36c34326af11ca245ff Mon Sep 17 00:00:00 2001 From: Daniel Fagnan Date: Mon, 30 Jun 2014 19:03:43 -0600 Subject: [PATCH 03/11] Cleared things up --- active/0000-square-brackets.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/active/0000-square-brackets.md b/active/0000-square-brackets.md index 2d5478d0372..ed3133236a0 100644 --- a/active/0000-square-brackets.md +++ b/active/0000-square-brackets.md @@ -8,7 +8,7 @@ Switching (back) the current type parameter syntax from `<>` to `[]`. # Motivation -Recently there has been a lot of talks on simplifying the syntax. Starting from removing the sigils `@` and `~` and making lifetimes less syntax heavy (through various proposals). I think changing the current generic syntax to `[]` will make it that much better and clearer (`[]` is much easier to read). +Recently there has been a lot of talks on simplifying the syntax. Starting from removing the sigils `@` and `~` and making lifetimes less syntax heavy (through various proposals). I think changing the current generic syntax to `[]` will make it that much better and clearer (I think `[]` is much easier to read). 1. We would remove the current ambiguities surround the current syntax `<>`. That means, we could be able to have: @@ -43,9 +43,7 @@ pub trait Monad[M[T]] { } ``` -4. There's precendence for it. Scala's syntax for generics is awesome. It imposes very little effort when reading and understanding. - -5. Somewhat related to the first point in that it would bring a consistent syntax for generic everywhere. No more `foo::<>()` that tends to confuse people (not those already aware of the syntax, of course). +4. There's precendence for it. Scala's syntax for generics is awesome. It imposes very little effort (I think) when reading and understanding. 6. Because it's consistent and has no ambiguities, one can finally use motions like `%` in Vim (and alternatives in other editors.). @@ -57,6 +55,8 @@ This is a very easy change to make. * The syntax is used quite a bit. Automation could potentially do some, if not most of the changes (The tricky part is the ambiguities in the current syntax). However, of the changes we've had in the past, I think this syntax change is a whole lot easier to work with than semantic changes, or more complex syntax changes. +* One that I forgot about is the issue with the indexing syntax. + # Alternatives * Keep it like it currently is and end up with the current syntax forever. From 4f9b61a528c5bd3c42e8163f08c3098e20fa630f Mon Sep 17 00:00:00 2001 From: Daniel Fagnan Date: Mon, 30 Jun 2014 19:13:33 -0600 Subject: [PATCH 04/11] Better points. --- active/0000-square-brackets.md | 22 +++++----------------- 1 file changed, 5 insertions(+), 17 deletions(-) diff --git a/active/0000-square-brackets.md b/active/0000-square-brackets.md index ed3133236a0..b455b9c47b8 100644 --- a/active/0000-square-brackets.md +++ b/active/0000-square-brackets.md @@ -10,23 +10,11 @@ Switching (back) the current type parameter syntax from `<>` to `[]`. Recently there has been a lot of talks on simplifying the syntax. Starting from removing the sigils `@` and `~` and making lifetimes less syntax heavy (through various proposals). I think changing the current generic syntax to `[]` will make it that much better and clearer (I think `[]` is much easier to read). -1. We would remove the current ambiguities surround the current syntax `<>`. That means, we could be able to have: +1. `[]` is easier to type than `<>`. -```rust -struct Vec[T] { - // ... -} - -fn foo[T]() -> Vec[T] { - // ... -} - -fn main() { - let something = foo[int](); -} -``` +2. `[]` delimeters are always matching. -2. `[]` composes **much** better than the more cryptic `<>` form. This is a common readability issue when working with any nested types (such as encoders and decoders). +2. IMO `[]` composes (nesting) **much** better than the more cryptic `<>` form. This is a common readability issue when working with any nested types (such as encoders and decoders). ```rust fn parse['a, T: Encodable[Encoder['a], IoError]](value: T) { @@ -45,7 +33,7 @@ pub trait Monad[M[T]] { 4. There's precendence for it. Scala's syntax for generics is awesome. It imposes very little effort (I think) when reading and understanding. -6. Because it's consistent and has no ambiguities, one can finally use motions like `%` in Vim (and alternatives in other editors.). +6. Because it's consistent, one can finally use motions like `%` in Vim (and alternatives in other editors.). # Detailed design @@ -55,7 +43,7 @@ This is a very easy change to make. * The syntax is used quite a bit. Automation could potentially do some, if not most of the changes (The tricky part is the ambiguities in the current syntax). However, of the changes we've had in the past, I think this syntax change is a whole lot easier to work with than semantic changes, or more complex syntax changes. -* One that I forgot about is the issue with the indexing syntax. +* One that I forgot about is the issue with the indexing syntax, so there might still be ambiguity. # Alternatives From 3a787ff7448579f6c0ec0a4fd88e1a899b770db5 Mon Sep 17 00:00:00 2001 From: Daniel Fagnan Date: Mon, 30 Jun 2014 19:16:26 -0600 Subject: [PATCH 05/11] Removed some subjectiveness --- active/0000-square-brackets.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/active/0000-square-brackets.md b/active/0000-square-brackets.md index b455b9c47b8..aeed68f781d 100644 --- a/active/0000-square-brackets.md +++ b/active/0000-square-brackets.md @@ -31,7 +31,7 @@ pub trait Monad[M[T]] { } ``` -4. There's precendence for it. Scala's syntax for generics is awesome. It imposes very little effort (I think) when reading and understanding. +4. There's precendence for it. Scala's syntax for generics is awesome. At the time when Rust switched form `[]` to `<>` there was no precedence in a C-style language for `[]` generics. That's no longer true. 6. Because it's consistent, one can finally use motions like `%` in Vim (and alternatives in other editors.). From bbba79126dcc880d6739170bd93a1eabe831f6f1 Mon Sep 17 00:00:00 2001 From: Daniel Fagnan Date: Mon, 30 Jun 2014 19:24:33 -0600 Subject: [PATCH 06/11] Fixed generalizing statement --- active/0000-square-brackets.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/active/0000-square-brackets.md b/active/0000-square-brackets.md index aeed68f781d..20ec69ea168 100644 --- a/active/0000-square-brackets.md +++ b/active/0000-square-brackets.md @@ -10,7 +10,7 @@ Switching (back) the current type parameter syntax from `<>` to `[]`. Recently there has been a lot of talks on simplifying the syntax. Starting from removing the sigils `@` and `~` and making lifetimes less syntax heavy (through various proposals). I think changing the current generic syntax to `[]` will make it that much better and clearer (I think `[]` is much easier to read). -1. `[]` is easier to type than `<>`. +1. `[]` is easier to type than `<>` on *most* keyboards. 2. `[]` delimeters are always matching. From d7dd8ea4d2125f2de956a7e1b7600ec070b46c3e Mon Sep 17 00:00:00 2001 From: Daniel Fagnan Date: Mon, 30 Jun 2014 19:25:19 -0600 Subject: [PATCH 07/11] Removed subjectiveness --- active/0000-square-brackets.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/active/0000-square-brackets.md b/active/0000-square-brackets.md index 20ec69ea168..c6bb6e15c1d 100644 --- a/active/0000-square-brackets.md +++ b/active/0000-square-brackets.md @@ -31,7 +31,7 @@ pub trait Monad[M[T]] { } ``` -4. There's precendence for it. Scala's syntax for generics is awesome. At the time when Rust switched form `[]` to `<>` there was no precedence in a C-style language for `[]` generics. That's no longer true. +4. There's precendence for it. Scala's syntax for generics uses `[]`. At the time when Rust switched form `[]` to `<>` there was no precedence in a C-style language for `[]` generics. That's no longer true. 6. Because it's consistent, one can finally use motions like `%` in Vim (and alternatives in other editors.). From ddabf81652351791d807acb71a6ed5bcefe2bbe6 Mon Sep 17 00:00:00 2001 From: Daniel Fagnan Date: Mon, 30 Jun 2014 19:39:25 -0600 Subject: [PATCH 08/11] Merged two points. Expanded on another one --- active/0000-square-brackets.md | 12 +++++++++--- 1 file changed, 9 insertions(+), 3 deletions(-) diff --git a/active/0000-square-brackets.md b/active/0000-square-brackets.md index c6bb6e15c1d..4560a571eae 100644 --- a/active/0000-square-brackets.md +++ b/active/0000-square-brackets.md @@ -12,9 +12,15 @@ Recently there has been a lot of talks on simplifying the syntax. Starting from 1. `[]` is easier to type than `<>` on *most* keyboards. -2. `[]` delimeters are always matching. +2. IMO `[]` composes **much** better than the more cryptic `<>` form; `[]` separates the different pieces more so than `<>`. `<>` elongates everything and it mashes it's contents. This is a common readability issue when working with any nested types (such as encoders and decoders). -2. IMO `[]` composes (nesting) **much** better than the more cryptic `<>` form. This is a common readability issue when working with any nested types (such as encoders and decoders). +```rust +fn parse<'a, T: Encodable, IoError>>(value: T) { + // ... +} +``` + +vs ```rust fn parse['a, T: Encodable[Encoder['a], IoError]](value: T) { @@ -33,7 +39,7 @@ pub trait Monad[M[T]] { 4. There's precendence for it. Scala's syntax for generics uses `[]`. At the time when Rust switched form `[]` to `<>` there was no precedence in a C-style language for `[]` generics. That's no longer true. -6. Because it's consistent, one can finally use motions like `%` in Vim (and alternatives in other editors.). +5. `[]` delimeters are always matching which then one can finally use motions like `%` in Vim (and alternatives in other editors.). # Detailed design From f330bdba30ff923bbf1e88deb6d34583490bf8d7 Mon Sep 17 00:00:00 2001 From: Daniel Fagnan Date: Mon, 30 Jun 2014 19:45:42 -0600 Subject: [PATCH 09/11] Removed useless points --- active/0000-square-brackets.md | 13 ++----------- 1 file changed, 2 insertions(+), 11 deletions(-) diff --git a/active/0000-square-brackets.md b/active/0000-square-brackets.md index 4560a571eae..a0edf5c87ff 100644 --- a/active/0000-square-brackets.md +++ b/active/0000-square-brackets.md @@ -28,18 +28,9 @@ fn parse['a, T: Encodable[Encoder['a], IoError]](value: T) { } ``` -3. It would bring the ability to have much nicer syntax when dealing with HKTs (there are a few different proposals I have in mind in terms of syntax, but it's mostly inferred.). +3. There's precendence for it. Scala's syntax for generics uses `[]`. At the time when Rust switched form `[]` to `<>` there was no precedence in a C-style language for `[]` generics. That's no longer true. -```rust -// Possible syntax for HKTs. -pub trait Monad[M[T]] { - // ... -} -``` - -4. There's precendence for it. Scala's syntax for generics uses `[]`. At the time when Rust switched form `[]` to `<>` there was no precedence in a C-style language for `[]` generics. That's no longer true. - -5. `[]` delimeters are always matching which then one can finally use motions like `%` in Vim (and alternatives in other editors.). +4. `[]` delimeters are always matching which then one can finally use motions like `%` in Vim (and alternatives in other editors.). # Detailed design From c8c3bd2e96cedba825322062c6d5ea91891c7cd4 Mon Sep 17 00:00:00 2001 From: Daniel Fagnan Date: Mon, 30 Jun 2014 19:46:12 -0600 Subject: [PATCH 10/11] ## to # --- active/0000-square-brackets.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/active/0000-square-brackets.md b/active/0000-square-brackets.md index a0edf5c87ff..42a9c7e1198 100644 --- a/active/0000-square-brackets.md +++ b/active/0000-square-brackets.md @@ -36,7 +36,7 @@ fn parse['a, T: Encodable[Encoder['a], IoError]](value: T) { This is a very easy change to make. -## Downsides +# Downsides * The syntax is used quite a bit. Automation could potentially do some, if not most of the changes (The tricky part is the ambiguities in the current syntax). However, of the changes we've had in the past, I think this syntax change is a whole lot easier to work with than semantic changes, or more complex syntax changes. From b493af0b95113d8bbec45d870cf5ab9e14bf4b2d Mon Sep 17 00:00:00 2001 From: Daniel Fagnan Date: Mon, 30 Jun 2014 19:55:50 -0600 Subject: [PATCH 11/11] Improved RFC from comments (Thanks @ChrisMorgan) --- active/0000-square-brackets.md | 28 +++++++++++++++++++++++----- 1 file changed, 23 insertions(+), 5 deletions(-) diff --git a/active/0000-square-brackets.md b/active/0000-square-brackets.md index 42a9c7e1198..c8c66293127 100644 --- a/active/0000-square-brackets.md +++ b/active/0000-square-brackets.md @@ -8,13 +8,14 @@ Switching (back) the current type parameter syntax from `<>` to `[]`. # Motivation -Recently there has been a lot of talks on simplifying the syntax. Starting from removing the sigils `@` and `~` and making lifetimes less syntax heavy (through various proposals). I think changing the current generic syntax to `[]` will make it that much better and clearer (I think `[]` is much easier to read). +Recently there has been a lot of talks on simplifying the syntax. Starting from removing the sigils `@` and `~` and making lifetimes less syntax heavy (through various proposals). I think changing the current generic syntax from `<>` to `[]` will make it that much better and clearer (I think `[]` is much easier to read). 1. `[]` is easier to type than `<>` on *most* keyboards. -2. IMO `[]` composes **much** better than the more cryptic `<>` form; `[]` separates the different pieces more so than `<>`. `<>` elongates everything and it mashes it's contents. This is a common readability issue when working with any nested types (such as encoders and decoders). +2. IMO `[]` composes **much** better than the more cryptic `<>` form. The `[]` syntax separates the different pieces more so than `<>`. The `<>` syntax elongates everything and it mashes it's contents. This is a common readability issue when working with any nested types (such as encoders and decoders). ```rust +// Current syntax fn parse<'a, T: Encodable, IoError>>(value: T) { // ... } @@ -23,18 +24,35 @@ fn parse<'a, T: Encodable, IoError>>(value: T) { vs ```rust +// New syntax fn parse['a, T: Encodable[Encoder['a], IoError]](value: T) { // ... } ``` -3. There's precendence for it. Scala's syntax for generics uses `[]`. At the time when Rust switched form `[]` to `<>` there was no precedence in a C-style language for `[]` generics. That's no longer true. +3. At the time when Rust switched from `[]` to `<>`, there was no precedence in a C-style language for `[]` generics; this is no longer true: Scala is an example of a language that has become fairly popular recently and which uses `[]` for its generics syntax. -4. `[]` delimeters are always matching which then one can finally use motions like `%` in Vim (and alternatives in other editors.). +4. `[]` delimeters are always matching, where one can finally use motions like `%` in Vim (and alternatives in other editors.). # Detailed design -This is a very easy change to make. +Type parameters would be encapsulated with `[]` instead of `<>`. + +```rust +struct Vec[T] { + // ... +} + +fn compile['a, T](input: &'a str, arg: T) -> CompiledArg[T] { + // ... +} +``` + +Ambiguities with vector indices are avoided the same way the current syntax works. + +```rust +foo::[int](); +``` # Downsides