From aa99136b8b6d7ecd749651147a303ac5f9534eca Mon Sep 17 00:00:00 2001 From: Nathaniel Theis Date: Thu, 26 Jun 2014 16:33:23 -0700 Subject: [PATCH 1/6] literally amazing --- active/0000-fromliteral.md | 58 ++++++++++++++++++++++++++++++++++++++ 1 file changed, 58 insertions(+) create mode 100644 active/0000-fromliteral.md diff --git a/active/0000-fromliteral.md b/active/0000-fromliteral.md new file mode 100644 index 00000000000..1e91d04d7ad --- /dev/null +++ b/active/0000-fromliteral.md @@ -0,0 +1,58 @@ +- Start Date: 2014-06-26 +- RFC PR #: (leave this empty) +- Rust Issue #: (leave this empty) + +# Summary + +Create new traits, FromStringLiteral, FromVectorLiteral. Types implementing these traits can be automatically constructed from literals automatically. Literals will effectively have their actual types inferred statically. + +# Motivation + +The biggest usecase for this will be that creating a String from a literal will no longer require calling .to_string(). It also eliminates the need for the vec! macro. In general, it saves typing and adds substantial extensibility to the language. + +Before, this compiles: + +let x = "Hello, world!".to_string(); + +while this doesn't: +let x: String = "Hello, world!"; + +If this is implemented, both would compile. + +# Detailed design + +trait FromStringLiteral { + fn from_string_literal(lit: &'static str) -> Self; +} +trait FromVectorLiteral { + fn from_vector_literal(lit: &[T]) -> Self; +} + +A string or vector literal would be considered a "generic string" or "generic vector", similar to generic ints. All types implementing FromStringLiteral/FromVectorLiteral would be considered subtypes of generic strings/vectors (respectively); if the compiler encounters a literal being used where a type implementing one of these traits is expected, the compiler generates code to call the trait's from_string_literal/from_vector_literal method with a reference to a string or vector containing the literal data. + +Although from_string_literal takes a reference with static lifetime, from_vector_literal does not constrain the lifetime. This is because vector literals may have elements constructed dynamically. + +# Drawbacks +Complexity is added to the compiler, as it must infer the type of literals. + +Integral / floating point literals are not included in this, and would behave as they do now. This may be confusing; if it is, traits could be added to include all literals. + +A type could potentially implement FromStringLiteral/FromVectorLiteral in an expensive manner, surprising the user. Programmers should be told not to do this. + +Wrapper types around strings/vectors which carry semantic information in their type could implement FromStringLiteral/FromVectorLiteral, thus allowing one to "accidentally" construct a type which might represent "safe" unsanitized data, etc. Programmers should be told not to implement FromStringLiteral/FromVectorLiteral on types where accidental construction is a concern. + +# Alternatives + +Not implementing this leaves nasty calls to .to_string/.to_owned littered around code. This gets annoying quickly. + +A full C++-style constructor system could be added, allowing types to be secretly constructed from any other type. This is overly general and very prone to mistakes. + +Literals could be treated as String/Vec instead of &'static str and fixed-size vectors. This ties the language far too closely to the standard library, and should be avoided. + +Add generic literal types to the language officially (not just in the compiler), and create a single FromLiteral type or reuse FromPrimitive. + +# Unresolved questions + +As always, naming is bikesheddable. + +Is there enough of a use-case for a FromIntegerLiteral or FromFloatLiteral? \ No newline at end of file From b8df0e232a139c45f0047da6b6ac76af12f65974 Mon Sep 17 00:00:00 2001 From: Nathaniel Theis Date: Thu, 26 Jun 2014 16:48:51 -0700 Subject: [PATCH 2/6] Mention possibility of just FromStringLiteral --- active/0000-fromliteral.md | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/active/0000-fromliteral.md b/active/0000-fromliteral.md index 1e91d04d7ad..e40d0d6922c 100644 --- a/active/0000-fromliteral.md +++ b/active/0000-fromliteral.md @@ -51,8 +51,12 @@ Literals could be treated as String/Vec instead of &'static str and fixed-size v Add generic literal types to the language officially (not just in the compiler), and create a single FromLiteral type or reuse FromPrimitive. +Only FromStringLiteral could be added, as it is the most needed (rust contains >300 uses of .to_string and only 20 uses of .to_owned) and the type of the argument from_vector_literal should take is quite hard to decide on. + # Unresolved questions As always, naming is bikesheddable. -Is there enough of a use-case for a FromIntegerLiteral or FromFloatLiteral? \ No newline at end of file +Is there enough of a use-case for a FromIntegerLiteral or FromFloatLiteral? + +DST being implemented could allow better ways to pass vector literals around. This isn't a question, is it? \ No newline at end of file From cdfc2767c03ef83a72ae710bab01458b7e30c4d1 Mon Sep 17 00:00:00 2001 From: Nathaniel Theis Date: Thu, 26 Jun 2014 16:59:10 -0700 Subject: [PATCH 3/6] Markdown syntax --- active/0000-fromliteral.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/active/0000-fromliteral.md b/active/0000-fromliteral.md index e40d0d6922c..46118b9e6cc 100644 --- a/active/0000-fromliteral.md +++ b/active/0000-fromliteral.md @@ -12,21 +12,21 @@ The biggest usecase for this will be that creating a String from a literal will Before, this compiles: -let x = "Hello, world!".to_string(); +```let x = "Hello, world!".to_string(); ``` while this doesn't: -let x: String = "Hello, world!"; +```let x: String = "Hello, world!";``` If this is implemented, both would compile. # Detailed design -trait FromStringLiteral { +```trait FromStringLiteral { fn from_string_literal(lit: &'static str) -> Self; } trait FromVectorLiteral { fn from_vector_literal(lit: &[T]) -> Self; -} +}``` A string or vector literal would be considered a "generic string" or "generic vector", similar to generic ints. All types implementing FromStringLiteral/FromVectorLiteral would be considered subtypes of generic strings/vectors (respectively); if the compiler encounters a literal being used where a type implementing one of these traits is expected, the compiler generates code to call the trait's from_string_literal/from_vector_literal method with a reference to a string or vector containing the literal data. From 3d104f3128cf351c5b6a62e8c7eb00b4427cde99 Mon Sep 17 00:00:00 2001 From: Nathaniel Theis Date: Thu, 26 Jun 2014 17:01:09 -0700 Subject: [PATCH 4/6] more formatting fixes --- active/0000-fromliteral.md | 9 ++++++--- 1 file changed, 6 insertions(+), 3 deletions(-) diff --git a/active/0000-fromliteral.md b/active/0000-fromliteral.md index 46118b9e6cc..bfc6985bfc8 100644 --- a/active/0000-fromliteral.md +++ b/active/0000-fromliteral.md @@ -12,7 +12,7 @@ The biggest usecase for this will be that creating a String from a literal will Before, this compiles: -```let x = "Hello, world!".to_string(); ``` +```let x = "Hello, world!".to_string();``` while this doesn't: ```let x: String = "Hello, world!";``` @@ -21,11 +21,14 @@ If this is implemented, both would compile. # Detailed design -```trait FromStringLiteral { +```rust +trait FromStringLiteral { fn from_string_literal(lit: &'static str) -> Self; } trait FromVectorLiteral { + fn from_vector_literal(lit: &[T]) -> Self; + }``` A string or vector literal would be considered a "generic string" or "generic vector", similar to generic ints. All types implementing FromStringLiteral/FromVectorLiteral would be considered subtypes of generic strings/vectors (respectively); if the compiler encounters a literal being used where a type implementing one of these traits is expected, the compiler generates code to call the trait's from_string_literal/from_vector_literal method with a reference to a string or vector containing the literal data. @@ -49,7 +52,7 @@ A full C++-style constructor system could be added, allowing types to be secretl Literals could be treated as String/Vec instead of &'static str and fixed-size vectors. This ties the language far too closely to the standard library, and should be avoided. -Add generic literal types to the language officially (not just in the compiler), and create a single FromLiteral type or reuse FromPrimitive. +Add generic literal types to the language officially (not just in the compiler), and create a single `FromLiteral` type or reuse FromPrimitive. Only FromStringLiteral could be added, as it is the most needed (rust contains >300 uses of .to_string and only 20 uses of .to_owned) and the type of the argument from_vector_literal should take is quite hard to decide on. From da0ffae957b68314d1882f70027fb0faedcf1dc6 Mon Sep 17 00:00:00 2001 From: Nathaniel Theis Date: Thu, 26 Jun 2014 17:03:12 -0700 Subject: [PATCH 5/6] Add line breaks for formatting Markdown is hard without a preview. --- active/0000-fromliteral.md | 10 ++++++---- 1 file changed, 6 insertions(+), 4 deletions(-) diff --git a/active/0000-fromliteral.md b/active/0000-fromliteral.md index bfc6985bfc8..c02c6a28ea3 100644 --- a/active/0000-fromliteral.md +++ b/active/0000-fromliteral.md @@ -25,11 +25,13 @@ If this is implemented, both would compile. trait FromStringLiteral { fn from_string_literal(lit: &'static str) -> Self; } -trait FromVectorLiteral { +``` +```rust +trait FromVectorLiteral { fn from_vector_literal(lit: &[T]) -> Self; - -}``` +} +``` A string or vector literal would be considered a "generic string" or "generic vector", similar to generic ints. All types implementing FromStringLiteral/FromVectorLiteral would be considered subtypes of generic strings/vectors (respectively); if the compiler encounters a literal being used where a type implementing one of these traits is expected, the compiler generates code to call the trait's from_string_literal/from_vector_literal method with a reference to a string or vector containing the literal data. @@ -62,4 +64,4 @@ As always, naming is bikesheddable. Is there enough of a use-case for a FromIntegerLiteral or FromFloatLiteral? -DST being implemented could allow better ways to pass vector literals around. This isn't a question, is it? \ No newline at end of file +DST being implemented could allow better ways to pass vector literals around. This isn't a question, is it? From ff8663712f72c921dbaf26644a420023cb8117da Mon Sep 17 00:00:00 2001 From: Nathaniel Theis Date: Fri, 27 Jun 2014 15:30:57 -0700 Subject: [PATCH 6/6] formatting and general pedantry --- active/0000-fromliteral.md | 9 ++++----- 1 file changed, 4 insertions(+), 5 deletions(-) diff --git a/active/0000-fromliteral.md b/active/0000-fromliteral.md index bfc6985bfc8..ed73952c80d 100644 --- a/active/0000-fromliteral.md +++ b/active/0000-fromliteral.md @@ -4,7 +4,7 @@ # Summary -Create new traits, FromStringLiteral, FromVectorLiteral. Types implementing these traits can be automatically constructed from literals automatically. Literals will effectively have their actual types inferred statically. +Create new traits, FromStringLiteral, FromVectorLiteral. Types implementing these traits can be automatically constructed from literals. Literals will effectively have their actual types inferred statically. # Motivation @@ -23,12 +23,11 @@ If this is implemented, both would compile. ```rust trait FromStringLiteral { - fn from_string_literal(lit: &'static str) -> Self; + fn from_string_literal(lit: &'static str) -> Self; } -trait FromVectorLiteral { - fn from_vector_literal(lit: &[T]) -> Self; - +trait FromVectorLiteral { + fn from_vector_literal(lit: &[T]) -> Self; }``` A string or vector literal would be considered a "generic string" or "generic vector", similar to generic ints. All types implementing FromStringLiteral/FromVectorLiteral would be considered subtypes of generic strings/vectors (respectively); if the compiler encounters a literal being used where a type implementing one of these traits is expected, the compiler generates code to call the trait's from_string_literal/from_vector_literal method with a reference to a string or vector containing the literal data.