# ideas (deprecated) **URL:** https://internals.rust-lang.org/c/internals/ideas-deprecated/11.md?page=1 [Latest](https://internals.rust-lang.org/latest.md) · [Categories](https://internals.rust-lang.org/categories.md) **Page:** 2 --- ## [Language features needed to add "map" for heterogeneous tuples?](https://internals.rust-lang.org/t/language-features-needed-to-add-map-for-heterogeneous-tuples/1898)
**Author:** [@tomjakubowski](https://internals.rust-lang.org/u/tomjakubowski)\ **Replies:** 2\ **Last updated:** [April 18, 2015, 3:14am UTC](https://internals.rust-lang.org/t/language-features-needed-to-add-map-for-heterogeneous-tuples/1898 "2015-04-18T03:14:29Z")
I got this crazy idea that it would be nice to be able to write something like this: fn foo(inp: (Option\, Option\)) -\> (String, i32) { inp.map\_into(|x| x.unwrap()) } My understanding is that to write m… --- ## [Safe async/reentrant closure (e.g. signal handler)](https://internals.rust-lang.org/t/safe-async-reentrant-closure-e-g-signal-handler/1742)
**Author:** [@l0kod](https://internals.rust-lang.org/u/l0kod)\ **Replies:** 10\ **Last updated:** [April 16, 2015, 7:11pm UTC](https://internals.rust-lang.org/t/safe-async-reentrant-closure-e-g-signal-handler/1742 "2015-04-16T19:11:35Z")
An interruption handler is difficult to code properly to ensure that the interrupted thread stay in a consistent and safe state. If Rust want to be able to safely handle signals (as it safely handle threads) we probabl… --- ## [Extending existing functionality](https://internals.rust-lang.org/t/extending-existing-functionality/1289)
**Author:** [@jethrogb](https://internals.rust-lang.org/u/jethrogb)\ **Replies:** 12\ **Last updated:** [April 16, 2015, 12:25am UTC](https://internals.rust-lang.org/t/extending-existing-functionality/1289 "2015-04-16T00:25:22Z")
I think Rust might currently be missing a convenient way to allow the addition of functionality to existing code, especially library code. As a library writer you currently have two options: make something (attribute/fun… --- ## [Shall there be a trait for creating smart pointers in std?](https://internals.rust-lang.org/t/shall-there-be-a-trait-for-creating-smart-pointers-in-std/1880)
**Author:** [@vi0](https://internals.rust-lang.org/u/vi0)\ **Replies:** 4\ **Last updated:** [April 15, 2015, 9:34pm UTC](https://internals.rust-lang.org/t/shall-there-be-a-trait-for-creating-smart-pointers-in-std/1880 "2015-04-15T21:34:27Z")
Rc and Arc both have "new" method outside any trait. Many other smart pointers can probably also have this trait. trait SmartPointer\ { fn new(t : T) -\> Self; } Is it a good idea? How this trait should be named? --- ## [The borrowing made by local reference variables should be considered relinquished after their last use of the lender](https://internals.rust-lang.org/t/the-borrowing-made-by-local-reference-variables-should-be-considered-relinquished-after-their-last-use-of-the-lender/1863)
**Author:** [@tommit](https://internals.rust-lang.org/u/tommit)\ **Replies:** 8\ **Last updated:** [April 15, 2015, 8:09pm UTC](https://internals.rust-lang.org/t/the-borrowing-made-by-local-reference-variables-should-be-considered-relinquished-after-their-last-use-of-the-lender/1863 "2015-04-15T20:09:52Z")
In other words, you should return the book if you're not reading it anymore: struct S { a: i32, b: i32 } fn ref\_a(s: &mut S) -\> &mut i32 { &mut s.a } fn ref\_b(s: &mut S) -\> &mut i32 { &mut s.b } fn foo(s: &mut S) {… --- ## [Extending the ability to elide commas from match arms](https://internals.rust-lang.org/t/extending-the-ability-to-elide-commas-from-match-arms/1865)
**Author:** [@P1start](https://internals.rust-lang.org/u/P1start)\ **Replies:** 2\ **Last updated:** [April 14, 2015, 9:25am UTC](https://internals.rust-lang.org/t/extending-the-ability-to-elide-commas-from-match-arms/1865 "2015-04-14T09:25:40Z")
Currently, one can omit the comma at the end of a match arm if the RHS of the =\> is a bare block expression: match foo { Foo =\> { ... } // no comma! Bar =\> { ... } } I’ve often wanted to modify this rule to m… --- ## [Refining variance and traits](https://internals.rust-lang.org/t/refining-variance-and-traits/1787)
**Author:** [@nikomatsakis](https://internals.rust-lang.org/u/nikomatsakis)\ **Replies:** 5\ **Last updated:** [April 13, 2015, 7:51pm UTC](https://internals.rust-lang.org/t/refining-variance-and-traits/1787 "2015-04-13T19:51:31Z")
Now that we've had time to gain some experience with variance, I've come to think that we should subset the Variance RFC design and make all traits invariant with respect to their input types (and lifetimes). The primary… --- ## [Revisiting the unsigned](https://internals.rust-lang.org/t/revisiting-the-unsigned/1819)
**Author:** [@barosl](https://internals.rust-lang.org/u/barosl)\ **Replies:** 4\ **Last updated:** [April 13, 2015, 1:56am UTC](https://internals.rust-lang.org/t/revisiting-the-unsigned/1819 "2015-04-13T01:56:57Z")
Yesterday, I've come to a reddit comment that complains the usage of unsigned integer types in std. I found this interesting, especially: just find Going Native 2013 conference video called "ask us anything" where all … --- ## [Pre-RFC: allow by-value drop](https://internals.rust-lang.org/t/pre-rfc-allow-by-value-drop/1845)
**Author:** [@arielb1](https://internals.rust-lang.org/u/arielb1)\ **Replies:** 11\ **Last updated:** [April 10, 2015, 5:10pm UTC](https://internals.rust-lang.org/t/pre-rfc-allow-by-value-drop/1845 "2015-04-10T17:10:39Z")
Proposal Currently, Drop in rust is always by-reference - the object still needs to be valid for drop-glue after the call to Drop::drop. An elegant way to fix this is to add a trait (e.g. Destruct): #\[lang="destruct"… --- ## [Can non-capturing closures (anonymous functions) be coerced into function pointers?](https://internals.rust-lang.org/t/can-non-capturing-closures-anonymous-functions-be-coerced-into-function-pointers/1813)
**Author:** [@abonander](https://internals.rust-lang.org/u/abonander)\ **Replies:** 2\ **Last updated:** [April 6, 2015, 7:46am UTC](https://internals.rust-lang.org/t/can-non-capturing-closures-anonymous-functions-be-coerced-into-function-pointers/1813 "2015-04-06T07:46:38Z")
As far as I understand it, closures are implemented as anonymous structs that wrap captured variables and then implement one of the Fn traits based on inference. For example, this: fn main() { let my\_val = 1i32… --- ## [Should ! be a type?](https://internals.rust-lang.org/t/should-be-a-type/1723)
**Author:** [@theemathas](https://internals.rust-lang.org/u/theemathas)\ **Replies:** 18\ **Last updated:** [April 3, 2015, 4:05am UTC](https://internals.rust-lang.org/t/should-be-a-type/1723 "2015-04-03T04:05:44Z")
The issue that ! is not a type comes up in the new closure traits: Fn() -\> ! is not valid. I believe that ! should be treated like an enum Void {} (which cannot be constructed). We should also add coercions Void -\> T t… --- ## [Forbid -(unsigned integer)](https://internals.rust-lang.org/t/forbid-unsigned-integer/752)
**Author:** [@nodakai](https://internals.rust-lang.org/u/nodakai)\ **Replies:** 22\ **Last updated:** [April 1, 2015, 9:26am UTC](https://internals.rust-lang.org/t/forbid-unsigned-integer/752 "2015-04-01T09:26:57Z")
We already have a lint item to find an application of the unary minus on an unsigned machine integer. Shouldn't we simply forbid it? Rust programmers can always use 0 - x instead when they know what they are doing (rus… --- ## [Rebalancing coherence: potential late-breaking change](https://internals.rust-lang.org/t/rebalancing-coherence-potential-late-breaking-change/1763)
**Author:** [@nikomatsakis](https://internals.rust-lang.org/u/nikomatsakis)\ **Replies:** 6\ **Last updated:** [March 29, 2015, 11:20am UTC](https://internals.rust-lang.org/t/rebalancing-coherence-potential-late-breaking-change/1763 "2015-03-29T11:20:55Z")
I recently realized that our current trait system contains a forward compatibility hazard concerned with negative reasoning. The TL;DR is that negative reasoning (that is, the compiler saying that "doing X is legal if th… --- ## [Rust with indents (Python, CoffeeScript, Haskell, F# style)](https://internals.rust-lang.org/t/rust-with-indents-python-coffeescript-haskell-f-style/674)
**Author:** [@skyfold](https://internals.rust-lang.org/u/skyfold)\ **Replies:** 45\ **Last updated:** [March 25, 2015, 2:40pm UTC](https://internals.rust-lang.org/t/rust-with-indents-python-coffeescript-haskell-f-style/674 "2015-03-25T14:40:14Z")
It's a sensitive topic, where all have their own prefs and I don't mean to start a holy war, just wonder how many of us here would like to have an option to write with indents instead of curly braces. We've seen many … --- ## [Vec! like initaliser for other collections](https://internals.rust-lang.org/t/vec-like-initaliser-for-other-collections/1730)
**Author:** [@mm865](https://internals.rust-lang.org/u/mm865)\ **Replies:** 12\ **Last updated:** [March 23, 2015, 6:53am UTC](https://internals.rust-lang.org/t/vec-like-initaliser-for-other-collections/1730 "2015-03-23T06:53:00Z")
Vec has a macro to assist in initialising a Vec with given contents, however none of the other collections in libstd have one. Many other languages have syntax for declaring e.g. a hash map in one go, including Python, R… --- ## [Pre-RFC: A cleaner way to create an \[u8 ; N\]](https://internals.rust-lang.org/t/pre-rfc-a-cleaner-way-to-create-an-u8-n/1692)
**Author:** [@Idolf](https://internals.rust-lang.org/u/Idolf)\ **Replies:** 5\ **Last updated:** [March 18, 2015, 11:47am UTC](https://internals.rust-lang.org/t/pre-rfc-a-cleaner-way-to-create-an-u8-n/1692 "2015-03-18T11:47:21Z")
Hello, I would like to propose we have a better way of creating \[u8 ; N\] types, as these are very useful when dealing with FFI. Context I am trying to create a high-level wrapper around the python27-sys crate. This… --- ## [\[Pre-RFC\] Boolean operators that don't return bool](https://internals.rust-lang.org/t/pre-rfc-boolean-operators-that-dont-return-bool/1684)
**Author:** [@ryanhiebert](https://internals.rust-lang.org/u/ryanhiebert)\ **Replies:** 12\ **Last updated:** [March 16, 2015, 12:54am UTC](https://internals.rust-lang.org/t/pre-rfc-boolean-operators-that-dont-return-bool/1684 "2015-03-16T00:54:22Z")
Relevant discussion on the Rust subreddit: http://www.reddit.com/r/rust/comments/2xu8rn/boolean\_operators\_to\_not\_return\_bools/ TL;DR: I'd like to see the boolean operators currently defined by Eq and Ord be made availa… --- ## [Lifetime parameter default value](https://internals.rust-lang.org/t/lifetime-parameter-default-value/1722)
**Author:** [@stepancheg](https://internals.rust-lang.org/u/stepancheg)\ **Replies:** 0\ **Last updated:** [March 15, 2015, 3:46am UTC](https://internals.rust-lang.org/t/lifetime-parameter-default-value/1722 "2015-03-15T03:46:33Z")
Rust does not have default value for lifetime parameters: struct MyMessage\<'a = 'static\> { ... } // parse error Any reason why rust has no such thing? (I guess it could interfere with lifetime elision, but I don't kn… --- ## [Lifetime notation](https://internals.rust-lang.org/t/lifetime-notation/751)
**Author:** [@arcto](https://internals.rust-lang.org/u/arcto)\ **Replies:** 30\ **Last updated:** [March 12, 2015, 10:39am UTC](https://internals.rust-lang.org/t/lifetime-notation/751 "2015-03-12T10:39:58Z")
It has long been argued that the lifetime notation is unnecessarily noisy. I'm just going to leave you with a simple change that, I think, do not introduce any ambiguities: Current: fn foo\<'a, 'b, T\>(&'a mut self, ba… --- ## [Alternate main() signatures](https://internals.rust-lang.org/t/alternate-main-signatures/1687)
**Author:** [@vadimcn](https://internals.rust-lang.org/u/vadimcn)\ **Replies:** 8\ **Last updated:** [March 8, 2015, 12:37am UTC](https://internals.rust-lang.org/t/alternate-main-signatures/1687 "2015-03-08T00:37:41Z")
As a follow-up to this Reddit thread (but I've seen similar complaints several times in other places), how do people feel about supporting alternate signatures for main()? I realize, this is only useful for short example… --- ## [Bounds checking at initialization](https://internals.rust-lang.org/t/bounds-checking-at-initialization/1681)
**Author:** [@fsavje](https://internals.rust-lang.org/u/fsavje)\ **Replies:** 9\ **Last updated:** [March 6, 2015, 1:27pm UTC](https://internals.rust-lang.org/t/bounds-checking-at-initialization/1681 "2015-03-06T13:27:27Z")
I really like the philosophy behind Rust and feel excited to use it in future projects. However, bounds checking when random accessing arrays/slices could be a real performance hog. As been pointed out before, this is no… --- ## [\[Pre-RFC\] Replace IteratorExt::zip with tuple iteration](https://internals.rust-lang.org/t/pre-rfc-replace-iteratorext-zip-with-tuple-iteration/1518)
**Author:** [@oli-obk](https://internals.rust-lang.org/u/oli-obk)\ **Replies:** 24\ **Last updated:** [March 6, 2015, 8:15am UTC](https://internals.rust-lang.org/t/pre-rfc-replace-iteratorext-zip-with-tuple-iteration/1518 "2015-03-06T08:15:24Z")
Start Date: 2015-01-30 RFC PR #: (leave this empty) Rust Issue #: (leave this empty) Summary Implement IntoIterator (since RFC 235 has landed) for the common tuple types and remove the zip function from Iterator. M… --- ## [Inline LLVM IR](https://internals.rust-lang.org/t/inline-llvm-ir/738)
**Author:** [@cessen](https://internals.rust-lang.org/u/cessen)\ **Replies:** 4\ **Last updated:** [March 6, 2015, 6:53am UTC](https://internals.rust-lang.org/t/inline-llvm-ir/738 "2015-03-06T06:53:09Z")
Currently Rust supports inline assembly, which is great for micro-optimization for specific architectures. Thanks to #\[cfg\] you can write both a pure rust version of a function, and then for important architectures you … --- ## [\[discarded\] Add an eternal lifetime](https://internals.rust-lang.org/t/discarded-add-an-eternal-lifetime/1672)
**Author:** [@stebalien](https://internals.rust-lang.org/u/stebalien)\ **Replies:** 2\ **Last updated:** [March 4, 2015, 11:19pm UTC](https://internals.rust-lang.org/t/discarded-add-an-eternal-lifetime/1672 "2015-03-04T23:19:22Z")
Edit: -- A better solution would be a more restrictive version of the Copy trait and a new derive attribute. so this can safely be postponed until someone actually needs it. Summary Add a lifetime 'eternal such that '… --- ## [Syntax for "impure" macros -- return/break/continue/etc](https://internals.rust-lang.org/t/syntax-for-impure-macros-return-break-continue-etc/1678)
**Author:** [@djmally](https://internals.rust-lang.org/u/djmally)\ **Replies:** 0\ **Last updated:** [March 4, 2015, 12:47am UTC](https://internals.rust-lang.org/t/syntax-for-impure-macros-return-break-continue-etc/1678 "2015-03-04T00:47:01Z")
Expanded on a thought by @kainino. "Impure" Macros I'll start by defining what I mean by an "impure" macro: take for example try!, which, in a nutshell, takes a Result type and either unwraps the Ok(v) and evaluates … --- ## [Add support for the wrapping of heap allocation and deallocation functions](https://internals.rust-lang.org/t/add-support-for-the-wrapping-of-heap-allocation-and-deallocation-functions/1618)
**Author:** [@nnethercote](https://internals.rust-lang.org/u/nnethercote)\ **Replies:** 9\ **Last updated:** [March 2, 2015, 6:54am UTC](https://internals.rust-lang.org/t/add-support-for-the-wrapping-of-heap-allocation-and-deallocation-functions/1618 "2015-03-02T06:54:58Z")
It can be very useful for user programs to be able to take arbitrary actions when when heap allocation and deallocation occurs. My motivation is that I want to build a heap profiler for Servo, one that's similar to Fir… --- ## [\`self\` destruction assignment](https://internals.rust-lang.org/t/self-destruction-assignment/1668)
**Author:** [@hauleth](https://internals.rust-lang.org/u/hauleth)\ **Replies:** 2\ **Last updated:** [March 1, 2015, 8:51pm UTC](https://internals.rust-lang.org/t/self-destruction-assignment/1668 "2015-03-01T20:51:56Z")
Currently we can destruct-while-calling any argument except self. I.e. struct Foo(i32, i32); fn foo(Foo(a, b): Foo) {} foo(Foo(1, 2)) impl Foo { // fn foo(Foo(a, b)) {} won't work (at least if it is trait impleme… --- ## [Pre-RFC: Separate reading/writing String from std::io::Read/std::io::Write](https://internals.rust-lang.org/t/pre-rfc-separate-reading-writing-string-from-std-io-read-std-io-write/1642)
**Author:** [@jan\_hudec](https://internals.rust-lang.org/u/jan_hudec)\ **Replies:** 15\ **Last updated:** [February 26, 2015, 7:55am UTC](https://internals.rust-lang.org/t/pre-rfc-separate-reading-writing-string-from-std-io-read-std-io-write/1642 "2015-02-26T07:55:37Z")
I've read through the IO Reform RFC 517 and I would like to discuss how the read\_to\_string/write\_fmt methods should work. The PR #575 does not address this. The problem is that while on Unix these days UTF-8 is almost … --- ## [Turn off the spelling suggestions](https://internals.rust-lang.org/t/turn-off-the-spelling-suggestions/1645)
**Author:** [@nrc](https://internals.rust-lang.org/u/nrc)\ **Replies:** 10\ **Last updated:** [February 25, 2015, 7:02pm UTC](https://internals.rust-lang.org/t/turn-off-the-spelling-suggestions/1645 "2015-02-25T19:02:55Z")
I don't think I've ever had a useful suggestion from this error message. Do others find it useful? Or annoying? I'm talking about stuff like "error: unresolved name OK. Did you mean tys?" Where, the name I was looking … --- ## [\[Pre-RFC\] Resolve support for hyphens in crate names](https://internals.rust-lang.org/t/pre-rfc-resolve-support-for-hyphens-in-crate-names/1459)
**Author:** [@DanielKeep](https://internals.rust-lang.org/u/DanielKeep)\ **Replies:** 35\ **Last updated:** [February 25, 2015, 7:40am UTC](https://internals.rust-lang.org/t/pre-rfc-resolve-support-for-hyphens-in-crate-names/1459 "2015-02-25T07:40:41Z")
Start Date: 2015-01-17 RFC PR: (leave this empty) Rust Issue: (leave this empty) Summary Resolve support for hyphens in crate names. Motivation Currently, crate names are required by rustc to be valid Rust identifiers… [Previous page](https://internals.rust-lang.org/c/internals/ideas-deprecated/11.md) [Next page](https://internals.rust-lang.org/c/internals/ideas-deprecated/11.md?page=2)