Older RFCs up for discussion this week


#1

Proposed for discussion at Rust meeting

https://github.com/rust-lang/rfcs/pull/136 - Ban private items in public APIs - glaebhoerl     Not much to add to the title. For example using a private struct as a type in a public function.     We have a lint for part of this already.     Apparently this is used as a hack for some kind of fine-grained privacy for traits. Seems like we should address that properly.     Mostly negative feedback, but (I think) only because of the hacks it would break.     Discuss again (previously discussed last week)

https://github.com/rust-lang/rfcs/pull/114 - Unboxed closures - nmatsakis     A lot of discussion, pretty much all about the details. General sentiment that we want this.     Recommend we accept - is this the right RFC to accept, I’ve not  really been keeping track - pnkfelix, pcwalton - is there something  which supersedes this? I think this needs a small update to reflect some  of the later comments.

https://github.com/rust-lang/rfcs/pull/127 - Opt-in builtin traits, take 2: default and negative impls - nmatsakis     Unsafe (trusted) traits (see also 117, now closed) which express an invariant to the compiler and default impls - which must be opted out of, rather than in.

https://github.com/rust-lang/rfcs/pull/132 - UFCS - nmatsakis     Universal function call syntax. Use ::Foo syntax for specifying the trait as well as the concrete type for a function call.     Previously discussed as an older RFC.

https://github.com/rust-lang/rfcs/pull/135 - where clauses - nmatsakis     Allow specifying bounds on type parameters in a where clause as well as inline. This is more expressive and neater in the presence of many type parameters or bounds.     Mostly positive feedback. Some worries around having inline bounds and where clauses. Some worries about the ‘multiple dispatch’ part of the proposal.

Proposed for discussion at triage

https://github.com/rust-lang/rfcs/issues/121 - some questions about the RFC process - pnkfelix     These need answers for clarification on the process.

https://github.com/rust-lang/rfcs/issues/158 - Should we track incomplete ideas here instead of in the rust issue tracker? - erikt     I think the answer is ‘use discourse’. We should make sure that is the answer, make it official in the thread and perhaps add some text to the RFC repo readme, then close.

https://github.com/rust-lang/rfcs/pull/172 - Exponentiation syntax sugar - SiegeLord     Sugar for the pow function.     Backwards compatible.     Recommend close and/or postpone.

https://github.com/rust-lang/rfcs/pull/174 - value type parameters - zoxc     Parameterise by values as well as types.     Recommend postpone.

https://github.com/rust-lang/rfcs/pull/175 - Field offsets - zoxc     I don’t understand very well what is proposed, sorry.     Recommend postpone or close - not great motivation, doesn’t seem to merit prioritisation before 1.0.

Discussed and postponed for more feedback

https://github.com/rust-lang/rfcs/pull/101 - Allow multiple (fixed-size) subslices borrows in one pattern - krdln     Allows matching several parts of a vec in one pattern. Adds xs..n syntax to match a fixed size slice (and changes variable sized slice pattern syntax to xs.. from ..xs).     Not much feedback - all positive or corrected later to be positive. Seems like a small generalisation with no downsides.     If we change the syntax as recommended for existing patterns (i.e., ..xs to xs..) then the rest should be backwards compatible, I think.

https://github.com/rust-lang/rfcs/pull/116 - Feature gate import shadowing - Kimundi     Forbid or deprecate name collision of imported names.     Positive feedback.     Recommend: lets do this! Might need to tidy up the RFC, but nothing major (hopefully). Need to decide whether to depricate via a feature gate or just get rid. Would be good to assess how much damage this will cause.

https://github.com/rust-lang/rfcs/pull/129 - refine the asm! extension - pczarn     A string/format! based method of doing inline asm.     Not much feedback.     Seems like we could do better with our inline asm, not sure if this is the right approach.     Recommend: probably close, but worth discussing first.

Proposed for discussion at some point

https://github.com/rust-lang/rfcs/pull/22 - Deserializing to a stream of tagged values - erikt     Changes to the deserialisation framework. Allows for decoding into an enum. No commentary for or against.     erikt to update?

Actions agreed

https://github.com/rust-lang/rfcs/pull/17 - Iterable trait family - erikt     aturon to comment     acrichto to close

https://github.com/rust-lang/rfcs/pull/88 - Macro syntax to count sequence repetitions - Eridius     pnkfelix + jclements to keep pushing on getting more explanation

https://github.com/rust-lang/rfcs/pull/16 - attributes on statements and blocks     huon has updated     need more discussion on edge cases - see RFC - pnkfelix (and others)

https://github.com/rust-lang/rfcs/pull/113 - Provide a common API across Option and the Ok and Err variants of Result - bjz     Make Option and Result more consistent.     Positive feedback for the idea, some discussion on the specifics.     I believe this was discussed before and we were going to flesh it out a bit more. Could bjz and aturon update us on progress?     To be closed, more RFCs coming from aturon.

https://github.com/rust-lang/rfcs/pull/123 - Rename Share to Threadsafe - acrichto     Rename share.     Bit of a bikeshed here, some support also for sync, concurrent, etc.     nmatsakis to merge

https://github.com/rust-lang/rfcs/pull/130 - RFC to remove some special treatment of Box by borrow checker - nmatsakis     Make Box a little bit more like a normal struct, but also make it less expressive. Removes the special ability for the borrow checker to distinguish parts of a boxed value.     Pretty much no feedback.     czwarich to implement and report back


#2

This one is very much needed for code that tries to avoid allocations, because you need to deal with constant-sized arrays all the time.


#3

Integral value type parameters is necessary to define methods (and implement traits) on fixed-sized arrays. Code that wants to operate on them can usually get away with &mut [T] instead. Code that wants to create them can be rewritten into taking a &mut [T] out-param instead of trying to return an array. Granted, it would be easier if code could return the array directly, but it’s not necessary.

That said, the RFC tries to allow for other values too, not just integral values, and it’s very much not at all obvious that this is a desirable thing to have.


#4

It indeed gets away with taking a &mut [T] – but this isn’t a very good solution, projected onto other types this is like you couldn’t return things at all, always needing to pass an out-pointer.

This is bad in the way that you have to initialize the array you borrow to the function before calling it – which can be quite large, like 4KB if you pass it to File::read.