"new" vectors

[graydon]

This is a first cut of #2112 which means we should have consensus in there that we want the feature before landing. At the same time, I'd like some feedback on the direction I'm taking for implementation, and at some point I'd like to stop playing rebase-around-the-typechecker.

The current code is able to translate a fixed-size string allocation down to a single instruction (sp adjustment) and an init / copy to a simple block data-movement. So it's headed in, I think, the right direction. Working on slices next. It does not do the whole slew of things described in #2112 yet. It parses all of those types but only knows how to translate fixed-size strings (and doesn't yet put them in constant-space).

Anyway, take a look and let me know if you see any glaring mistakes. I'm happy to update this as I get feedback.

[nikomatsakis]

In general this looks good to me. I am still not crazy about the trailing / but I haven't come up with a convincing alternative yet. :) One thought I had is that we may want to think about whether we can combine the notion of 'placement new' with this. Anyway, we can discuss tomorrow.

[brson]

Exciting.

[graydon]

Yeah, notation is still something I've only minor preference for ("non-awful would be better")

[bstrie]

Since bikeshedding's basically all I'm good for, I'd like to reassure you that the / notation is hardly ugly enough to lose sleep over (with the exception of /_ for size inference). I don't think that "vector divison" is even defined for any domain, so it's simple and unambiguous to visually parse. It won't win any beauty pageants, but if fixed-width vectors are mostly used for C interop then I don't think that those who are using it heavily will even bat an eyelid at it.

[nikomatsakis]

What bothers me is not [1, 2, 3]/3, but rather [int]/~ and [int]/@, which will get written often. I think there is a plausible interpretation of [T] as "a length field and some number of T instances laid out back-to-back," which means ~[int] is a unique vector, but then it's not clear how to write a slice. vec<T> and slice<T> would be one possibility, but then it's not clear how to write the fixed length vectors.

[graydon]

Present notation also supports [T]/& for slice (with inferred region), with [T]/&foo, meaning "a slice of a vector with storage in region foo". My thinking is that [T] will (when I throw the switch) become an abbreviation for [T]/& and [a,b,c] (in expression context) an abbreviation for [a,b,c]/&. But we could also have [a,b,c] try to infer when it means boxed or uniquely boxed as well (in some symmetry with our struggles over the {||...} notation.)

[nikomatsakis]

Hmm. Maybe I didn't fully understand the proposal, or just hadn't thought about it quite enough. I kind of thought [T]/X meant "an array laid out with an optional length followed by data items" and [T]&r meant "a slice". The slice would be scoped to the region R (which may not be written explicitly), just like fn&r() is a function pointer scoped to the region r. In other words, the / signalled "this is the original array" vs "a view into some array".

[graydon]

The proposal (in the bug and sent to the list) had [T] meaning slice. I didn't mention named regions in there at all.

In the code I'm writing here, I've deviated a bit such that [T]/& means slice (and I permit named regions, mostly for debugging and implementing the const region explicitly rather than by analysis-of-constness, in this pass; I think probably they'll all be inferred by context in practice).

The deviation is so that [T] as used in the current compiler and libraries doesn't suddenly change semantics on us. My intent is to gradually rewrite them all to use [T]/& and then, once there are no more uses of old-style vectors, deprecate it and switch the syntax over. Fun times.

I've no opinion yet whether [T]/& will need to continue to exist after that rewrite, as a more-explicit form (unless maybe we find we need the ability to name regions-holding-vectors), nor whether, if so, it's written [T]/& or [T]&.

[graydon]

Updated to handle slices too.

[graydon]

I landed this as nobody seemed to object. Let me know if you see further breakage or dislike it.