https://github.com/rust-lang/rust http://git.dreamy.place/mirrors/rust/atom?h=try 2020-07-28T00:51:13+00:00 2020-07-28T00:51:13+00:00 mark markm@cs.wisc.edu 2020-06-12T02:31:49+00:00 urn:sha1:2c31b45ae878b821975c4ebd94cc1e49f6073fd0 2020-07-27T00:05:49+00:00 Alex forehand.alex@gmail.com 2020-07-27T00:05:49+00:00 urn:sha1:06cc66619797161eab89d321bcc6420d9770b0eb 2020-07-23T12:52:48+00:00 Yuki Okushi huyuumi.dev@gmail.com 2020-07-23T12:52:48+00:00 urn:sha1:3f4f3134d955c6be8a1bb0b1f875990ae642f5c1 2020-07-20T19:30:14+00:00 Manish Goregaokar manishsmail@gmail.com 2020-07-20T19:30:14+00:00 urn:sha1:241374a93b4fe45daf2783b78415ba9a7928c790 Impl Default for ranges Couldn't find an issue about it. `Range` and friends probably can implement `Default` if `Idx: Default`. For example, the following would be possible: ```rust #[derive(Default)] struct Foo(core::ops::RangeToInclusive<u64>); let _ = [1, 2, 3].get(core::ops::Range::default()); core::ops::RangeFrom::<u8>::default().take(20).for_each(|x| { dbg!(x); }); fn stuff<T: Default>() { let instance = T::default(); ... more stuff } stuff::<core::ops::RangeTo<f32>>(); ``` Maybe there are some concerns about safety or misunderstandings? 2020-07-16T23:36:49+00:00 Mark Rousskov mark.simulacrum@gmail.com 2020-07-16T13:12:59+00:00 urn:sha1:647d9b525fcda07695809b851b4d6bce05b34e61 2020-07-10T10:53:53+00:00 Caio c410.f3r@gmail.com 2020-07-10T10:44:27+00:00 urn:sha1:c3756927478afe8d3a880edc469afd766c2f9e82 2020-06-24T23:08:11+00:00 Aaron Hill aa1ronham@gmail.com 2020-05-25T03:07:55+00:00 urn:sha1:a13d4678feadf03e247ab6aae8279bfab9cdaa6d Fixes #70718 This commit allows making associated items (e.g. associated functions and types) into lang items via the `#[lang]` attribute. This allows such items to be accessed directly, rather than by iterating over the parent item's associated items. I've added `FnOnce::Output` as a lang item, and updated one old usage to use the new lang item. The remaining uses can be updated separately. 2020-06-10T02:10:55+00:00 Caio c410.f3r@gmail.com 2020-06-10T02:10:55+00:00 urn:sha1:187aea7c34adf06b0db39f688d60d3fdac8e7e3e 2020-06-03T19:27:51+00:00 Mark Rousskov mark.simulacrum@gmail.com 2020-06-03T19:15:53+00:00 urn:sha1:71393422495b8d3c7a6e4ded3e64adaec45dca6d 2020-05-31T19:58:06+00:00 JOE1994 joseph942010@gmail.com 2020-05-31T19:58:06+00:00 urn:sha1:3048a41a5a042c2633a4d87ea38e04a1407f5bd3 If the reader assumes that 'pointer type's include 'smart pointer's, the term 'non-pointer type' could mislead the reader to assume that x should not be a smart pointer type. I tried to rephrase the term 'non-pointer type' to remove ambiguity in the doc comments. closes #72335 Thank you for reviewing this PR! :)