That came as a surprise; thank you. : )
nmatsakis: Calling it would have to be unsafe. I like it how it is. As long as the Option optimization works fine, that is.
I know this has been discussed to tedium already, but it's still the case that if the Option optimization in the FFI is acceptable for fns, then there's no reason it shouldn't also be acceptable for *. The two being inconsistent is the weird part. (If * were non-nullable this might also make it easier to get the null-pointer optimization in enums for types which use it in a non-nullable way (Vec, Rc, etc.) without jumping through so many extra hoops, but I know other people have strenuously objected to it in the past.)
I missed the memo about spawn! being used less commonly in modern Rust. Is this just the removal of libgreen and the de-emphasis of tasks-and-channels for lightweight concurrency, or is there a preferred way to spin up threads that I missed?
@jfager It’s just that not every Rust program in existence will use threads, and some of the ones that do may use an alternate io library than the built-in one.
The standard is pretty much every Rust program ever. The vast, vast majority.
IIRC the array syntaxe used to be [type * size]. It seem to me the better syntax.
Why was it dropped?
That would be ambiguous syntax today.
let foo = [5u * 5]; // is this [5u, 5u, 5u, 5u, 5u] or [25u]?While it feels good to have had my contributions recognized, I want to express some sadness at the fact that the two RFCs which were noted, and which look like they will be accepted, are two of the less consequential ideas I had for Rust. The others, which I think would have been much more significant, I never in the end managed to write up into proper RFCs. As a kind of last-ditch effort, I had decided to post all of my notes and partially-written drafts, thinking that the ideas themselves should be more important than having them in eloquently-rendered paragraphs, but this doesn’t appear to have made much of an impact. Anyways, it’s too late now; but I would still very much appreciate it if some members of the core team could take an hour or two out of their lives to at least read through them.
(I know that people have not really read them, because one of them describes a still-extant soundness violation.)
Can you make them be Markdown (or whatever else Github supports), for convenience.
This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.