dnrops
/
rfcs
mirror of https://github.com/rust-lang/rfcs.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

Updated based on the feedback

This commit is contained in:
petrochenkov 2014-10-12 18:31:11 +04:00
parent 3bad80c997
commit 8cf7bbe148
1 changed files with 74 additions and 90 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

164
active/0000-statically-sized-literals.md
View File

@ -4,20 +4,27 @@
# Summary
Change the types of array, byte string and string literals to be references to statically sized types.
Introduce strings of fixed size.
Change the types of byte string literals to be references to statically sized types.
Ensure the same change can be performed backward compatibly for string literals in the future.
# Motivation
Currently byte string and string literals have types `&'static [u8]` and `&'static str`.
Therefore, although the sizes of the literals are known at compile time, they are erased from their types and inaccessible until runtime.
This RFC suggests to change the types to `&'static [u8, ..N]` and `&'static str[..N]` respectively.
Additionally this RFC suggests to change the types of array literals from `[T, ..N]` to `&'a [T, ..N]` for consistency and ergonomics.
This RFC suggests to change the type of byte string literals to `&'static [u8, ..N]`.
In addition this RFC suggest not to introduce any changes to `str` or string literals, that would prevent a backward compatible addition of strings of fixed size `FixedString<N>` (the name FixedString in this RFC is a placeholder and is open for bikeshedding) and the change of the type of string literals to `&'static FixedString<N>` in the future.
`FixedString<N>` is essentially a `[u8, ..N]` with UTF-8 invariants and additional string methods/traits.
It fills the gap in the vector/string chart:
`Vec<T>` | `String`
---------|--------
`[T, ..N]` | ???
`&[T]` | `&str`
Today, given the lack of non-type generic parameters and compile time (function) evaluation (CTE), strings of fixed size are not very useful.
But after introduction of CTE the need in compile time string operations will raise rapidly.
Even without CTE but with non-type generic parameters alone fixed size strings can be used in runtime for "heapless" string operations, which are useful in constrained environments or for optimization.
So the main motivation for changes today is forward compatibility and before 1.0 `str[..N]` can be implemented as marginally as possible to allow the change of the types of string literals.
Even without CTE but with non-type generic parameters alone fixed size strings can be used in runtime for "heapless" string operations, which are useful in constrained environments or for optimization. So the main motivation for changes today is forward compatibility.
Examples of use for new literals, that are not possible with old literals:
@ -27,9 +34,9 @@ let mut arr: [u8, ..3] = *b"abc";
arr[0] = b'd';
// Future with CTE: compile time string concatenation
static LANG_DIR: str[..5 /*The size should, probably, be inferred*/ ] = *"lang/";
static EN_FILE: str[.._] = LANG_DIR + *"en"; // str[..N] implements Add
static FR_FILE: str[.._] = LANG_DIR + *"fr";
static LANG_DIR: FixedString<5 /*The size should, probably, be inferred*/> = *"lang/";
static EN_FILE: FixedString<_> = LANG_DIR + *"en"; // FixedString<N> implements Add
static FR_FILE: FixedString<_> = LANG_DIR + *"fr";
// Future without CTE: runtime "heapless" string concatenation
let DE_FILE = LANG_DIR + *"de"; // Performed at runtime if not optimized
@ -37,33 +44,46 @@ let DE_FILE = LANG_DIR + *"de"; // Performed at runtime if not optimized
# Detailed design
### Proposed changes:
Change the type of byte string literals from `&'static [u8]` to `&'static [u8, ..N]`.
Leave the door open for a backward compatible change of the type of string literals from `&'static str` to `&'static FixedString<N>`.
1)
Change the types of array literals from `[T, ..N]` to `&'a [T, ..N]`.
Change the types of byte string literals from `&'static [u8]` to `&'static [u8, ..N]`.
Change the types of string literals form `&'static str` to `&'static str[..N]`.
2)
Introduce the missing family of types - strings of fixed size - `str[..N]`.
`str[..N]` is essentially a `[u8, ..N]` with UTF-8 invariants and, eventually, additional string methods/traits.
It fills the gap in the vector/string chart:
### Strings of fixed size
`Vec<T>` | `String`
---------|--------
`[T, ..N]` | ???
`&[T]` | `&str`
### Static lifetime
Although all the literals under consideration are similar and are essentially arrays of fixed size, array literals are different from byte string and string literals with regard to lifetimes.
While byte string and string literals can always be placed into static memory and have static lifetime, array literals can depend on local variables and can't have static lifetime in general case.
The chosen design potentially allows to trivially enhance *some* array literals with static lifetime in the future to allow use like
If `str` is moved to the library today, then strings of fixed size can be implemented like this:
```
fn f() -> &'static [int] {
[1, 2, 3]
}
struct str<Sized? T = [u8]>(T);
```
, but this RFC doesn't propose such an enhancement.
Then string literals will have types `&'static str<[u8, ..N]>`.
Drawbacks of this approach include unnecessary exposition of the implementation - underlying sized or unsized arrays `[u8]`/`[u8, ..N]` and generic parameter `T`.
The key requirement here is the autocoercion from reference to fixed string to string slice an we are unable to meet it now without exposing the implementation.
In the future, after gaining the ability to parameterize on integers, strings of fixed size could be implemented in a better way:
```
struct __StrImpl<Sized? T>(T); // private
pub type str = StrImpl<[u8]>; // unsized referent of string slice `&str`, public
pub type FixedString<const N: uint> = __StrImpl<[u8, ..N]>; // string of fixed size, public
// &FixedString<N> -> &str : OK, including &'static FixedString<N> -> &'static str for string literals
```
So, we don't propose to make these changes today and sugget to wait until parameterizing on integers is added to the language.
### Precedents
C and C++ string literals are lvalue `char` arrays of fixed size with static duration.
C++ library proposal for strings of fixed size ([link][1]), the paper also contains some discussion and motivation.
# Rejected alternatives and discussion
## Array literals
The types of array literals potentially can be changed from `[T, ..N]` to `&'a [T, ..N]` for consistency with the other literals and ergonomics.
The major blocker for this change is the inability to move out from a dereferenced array literal if `T` is not `Copy`.
```
let mut a = *[box 1i, box 2, box 3]; // Wouldn't work without special-casing of string literal with regard to moving out from dereferenced borrowed pointer
```
Despite that array literals as references have better usability, possible `static`ness and consistency with other literals.
### Usage statistics for array literals
@ -75,51 +95,18 @@ In the rest *10%* of cases the usage is unclear.
So, in most cases the change to the types of array literals will lead to shorter notation.
### Backward compatibility
### Static lifetime
No code using the literals as slices is broken, DST coercions `&[T, ..N] -> &[T], &str[..N] -> &str` do all the job for compatibility.
Although all the literals under consideration are similar and are essentially arrays of fixed size, array literals are different from byte string and string literals with regard to lifetimes.
While byte string and string literals can always be placed into static memory and have static lifetime, array literals can depend on local variables and can't have static lifetime in general case.
The chosen design potentially allows to trivially enhance *some* array literals with static lifetime in the future to allow use like
```
fn f(arg: &str) {}
f("Hello"); // DST coercion
static GOODBYE: &'static str = "Goodbye"; // DST coercion
fn main() {
let s = "Hello";
fn f(arg: &str) {}
f(s); // No breakage, DST coercion
fn f() -> &'static [int] {
[1, 2, 3]
}
fn g(arg: &[int]) {}
g([1i, 2, 3]); // DST coercion &[int, ..3] -> &[int]
```
Unfortunately, autocoercions from arrays of fixed size to slices was prohibited too soon and a lot of array literals like `[1, 2, 3]` were changed to `&[1, 2, 3]`. These changes have to be reverted (but the prohibition of autocoercions should stay in place).
Code using array literals as values is broken, but can be fixed easily.
```
// Array as a struct field
struct S {
arr: [int, ..3],
}
let s = S { arr: [1, 2, 3] }; // Have to be changed to let s = S { arr: *[1, 2, 3] };
// Mutable array
let mut a = [1i, 2, 3]; // Have to be changed to let mut a = *[1i, 2, 3];
```
This explicit dereference has some benefits - you have to opt-in to use arrays as values and potentially costly array copies become a bit more visible and searchable.
Anyway, array literals are less frequently used as values (see the statistics), but more often as slices.
### Precedents
C and C++ string literals are lvalue `char` arrays of fixed size with static duration.
C++ library proposal for strings of fixed size ([link][1]), the paper also contains some discussion and motivation.
# Drawbacks
Some breakage for array literals. See "Backward compatibility" section.
# Alternatives
## Alternatives
The alternative design is to make the literals the values and not the references.
@ -128,9 +115,9 @@ The alternative design is to make the literals the values and not the references
1)
Keep the types of array literals as `[T, ..N]`.
Change the types of byte literals from `&'static [u8]` to `[u8, ..N]`.
Change the types of string literals form `&'static str` to to `str[..N]`.
Change the types of string literals form `&'static str` to to `FixedString<N>`.
2)
Introduce the missing family of types - strings of fixed size - `str[..N]`.
Introduce the missing family of types - strings of fixed size - `FixedString<N>`.
...
3)
Add the autocoercion of array *literals* (not arrays of fixed size in general) to slices.
@ -147,9 +134,9 @@ let mut arr: [u8, ..3] = b"abc";
arr[0] = b'd';
// Future with CTE: compile time string concatenation
static LANG_DIR: str[.._] = "lang/";
static EN_FILE: str[.._] = LANG_DIR + "en"; // str[..N] implements Add
static FR_FILE: str[.._] = LANG_DIR + "fr";
static LANG_DIR: FixedString<_> = "lang/";
static EN_FILE: FixedString<_> = LANG_DIR + "en"; // FixedString<N> implements Add
static FR_FILE: FixedString<_> = LANG_DIR + "fr";
// Future without CTE: runtime "heapless" string concatenation
let DE_FILE = LANG_DIR + "de"; // Performed at runtime if not optimized
@ -191,28 +178,25 @@ Examples:
let mut arr: [u8, ..3] = [b'a', b'b', b'c']; // Have to use array literals
arr[0] = b'd';
// Future: str[..N] is added, CTE is added, but the literal types remain old
// Future: FixedString<N> is added, CTE is added, but the literal types remain old
let mut arr: [u8, ..3] = b"abc".to_fixed(); // Have to use a conversion method
arr[0] = b'd';
static LANG_DIR: str[.._] = "lang/".to_fixed(); // Have to use a conversion method
static EN_FILE: str[.._] = LANG_DIR + "en".to_fixed();
static FR_FILE: str[.._] = LANG_DIR + "fr".to_fixed();
static LANG_DIR: FixedString<_> = "lang/".to_fixed(); // Have to use a conversion method
static EN_FILE: FixedString<_> = LANG_DIR + "en".to_fixed();
static FR_FILE: FixedString<_> = LANG_DIR + "fr".to_fixed();
// Bad future: str[..N] is not added
// Bad future: FixedString<N> is not added
// "Heapless"/compile-time string operations aren't possible, or performed with "magic" like extended concat! or recursive macros.
```
Note, that in the "Future" scenario the return *type* of `to_fixed` depends on the *value* of `self`, so it requires sufficiently advanced CTE, for example C++14 with its powerful `constexpr` machinery still doesn't allow to write such a function.
# Drawbacks
None.
# Unresolved questions
If `str` is moved from core language to the library and implemented as a wrapper around u8 array, then strings of fixed size will require some additional attention. Moreover, the changes to string literals should, probably, be applied after this move.
Assume we implemented `str` like this:
```
struct str<Sized? T = [u8]> { underlying_array: T }
```
Then strings of fixed size will have library types `str<[u8, ..N]>` instead of built-in `str[..N]` and that's a clear improvement.
In that case string literals have types `&'static str<[u8, ..N]>` which can be autocoerced to `&'static str` by DST coercion.
None.
[1]: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4121.pdf