Focus of Rust evolution

[Centril]

Let's not forget that Rust is a very young language, and given time, I'm confident it will rise to the task in the number crunching department. So although the road may me long, there's light at the end of the tunnel.

@HadrienG

Const generics and functions in particular will address many of these issues, at the expense of potentially causing a big language community split between compile-time and run-time Rust.

With an RFC similar to "const bounds and methods" (which needs to be significantly rewritten) we can also almost entirely get rid of the ecosystem split between const and non-const.

@HadrienG

Rust’s slice/iterator ecosystem is heavily biased towards dynamically sized containers, and interoperates poorly with statically sized arrays. For example, collecting an iterator into an array is a pain.

I think we can have fixed size iterators using const generics, see: Fixed-size lazy iterators? - #4 by Centril Also, I'd like to see some form of ArrayVec in the standard library.

@leonardo

Better ways to initialize arrays and avoid double initializations

There's also "const repeat expressions" which recently got accepted.

@newpavlov

I think this should be solved not by making unsafe unchecked indexing more ergonomic (buffer overflows in Rust? No, thank you…), but by making Rust smarter around proving bounds checks redundancy (e.g. sometimes you have to use explicit slices instead of assert_eq!)

I think the solution here should be more of dependent types (we'll get dependent types for const values, let's also get them for runtime values) and refinement types atop of that. Dependent types also gives the user an extreme amount of power to program the type system for comparatively little complexity, that is: the power / complexity ratio is small.

@newpavlov

and by developing an ergonomic tool which will be able to highlight indexing operations for which LLVM can’t remove bounds checks.

This BsC thesis discussing a compiler explorer for CakeML might be of interest, http://publications.lib.chalmers.se/records/fulltext/251308/251308.pdf

@gbutler

EDIT: Might a possible syntax for this be?

let i = computeNextIndexToUseBasedOnMyAlgorithm( ... );
unsafe { let el = a[!:i]; }

where the “[!:]” is the "unchecked/unsafe index operator (bike-shedding on syntax welcome).

Instead of special syntax, we can instead introduce forms of effect polymorphism where you can say: x: Arr , Arr: unsafe Index<usize> and now you can use unsafe fn index(&self, index: Idx) -> &Self::Output; without changing the trait like so: arr[0] (see the const bounds and methods RFC for a discussion).