Question:
Tracking issue for the feature, which is  and the associated enum.
Yes, please. Why? Makes little sense.
I disagree that it makes little sense to expose getters, it's possible to envision a situation where one formatting is composed of many others and you perhaps want some to be formatted to various widths or perhaps enable various flags (e.g. the "alternate" mode). It's certainly niche but it's somewhat necessary for completeness.
, , and all seem straightforward and can be stabilized as-is. I would also very much like to add and stabilize boolean accessors for the various parts of : , , , and (we could call the last one but that seems like a genuinely excessive name). It's pretty unfortunate we stabilized the accessor in the first place IMO, but oh well. I'm a little less sure about , though. What is returned if no fill character was specified? Why doesn't it return an like the others? Is sufficient? Should it be a full grapheme instead?
I'd be fine just deprecating the method (it's basically useless without constants anyway) and adding boolean accessors, I agree that it better matches design in today's Rust. I'd also be fine making return an and just specifying that it's always one unicode character (it's how the format string is parsed). Perhaps in theory a grapheme could be specified but that seems like something for an even fancier formatting system!
This issue is now entering its cycle-long FCP for stabilization in 1.5 The accessors being in will also be considered for stabilization.
Ah, and may be good to get your opinion on the grapheme-vs- situation here. Currently whenever something is formatted you have the ability to specify a "fill" character which for when padding is applied (normally this is just an ascii space). As points out this fill is currently just a , but it could in theory be a grapheme in terms of "one thing on the screen". Do you have an opinion either way in that regard? Curious to hear thoughts!
Uh. It’s not just graphemes. The whole // thing in as currently written is based on some assumptions: ’re printing to something that (like most terminal emulators) align text on a grid . Unfortunately, as often with Unicode, it’s complicated. Not only grapheme clusters can have more than one code point and still only use one slot (with combining code points), but most characters of some Asian languages and most emoji are “full width”: they’re twice the usual width in most monospace fonts. Control characters be displayed. Or they might be interpreted by the terminal to move the cursor around. has some more background. Here is an extract, about emoji flags: Our best bet for ”what is the width of this string?” is probably That leaves dealing with if it’s double width or a control character. If we want to do it, could be an arbitrary string rather than a single ? Or should be rejected?
Hm, those are very good points! I would be mostly tempted to just pare down everything and say it largely deals with ascii only (and maybe simple unicode?). I don't think it'd be too beneficial to start getting full-blown unicode-width support in libcore just to support a use case like this. Having some verification in the compiler, however, to make sure you're not doing crazy things seems reasonable? In theory, yes. I'd also be fine with this!
The libs team discussed this during triage today and the decision was to stabilize.
Triage: looks like this was stabilized, closing!
is still unstable, linking to this issue:
I am a bit confused about the reason is still unstable. Is it because is only available from ? Is there anything I can help with to move this along?
Nominating for stabilization. I suspect that needs to be re-exported in std, but that seems like something trivial to solve while stabilizing. The only concern that I see left is that there appear to be 3 separate, but equivalent, definition of the enum in the various libraries. These should probably be de-duplicated, but again, since only one appears to be public, we can probably do this trivially as well during stabilization.
I think we should remove and return an instead, but it seems reasonable to stabilize. fcp merge
Team member has proposed to merge this. The next step is review by the rest of the tagged teams: [x] [x] [x] [x] [x] [x] [x] [x] No concerns currently listed. Once these reviewers reach consensus, this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up! See for info about what commands tagged team members can give me.
:bell: This is now entering its final comment period, as per the . :bell:
:bell: This is now entering its final comment period, as per the . :bell:
The final comment period is now complete.
Shouldn't this get merged then?
Yes, with FCP to stabilize completed, the next step is a stabilization PR.

let mut sign = None; if !is_positive { sign = Some('-'); width += 1; <del> } else if self.flags & (1 << (FlagV1::SignPlus as u32)) != 0 { </del> <ins> } else if self.sign_plus() { </ins> sign = Some('+'); width += 1; } let mut prefixed = false; <del> if self.flags & (1 << (FlagV1::Alternate as u32)) != 0 { </del> <ins> if self.alternate() { </ins> prefixed = true; width += prefix.char_len(); }


Question:
Tracking issue for the feature, which is  and the associated enum.
Yes, please. Why? Makes little sense.
I disagree that it makes little sense to expose getters, it's possible to envision a situation where one formatting is composed of many others and you perhaps want some to be formatted to various widths or perhaps enable various flags (e.g. the "alternate" mode). It's certainly niche but it's somewhat necessary for completeness.
, , and all seem straightforward and can be stabilized as-is. I would also very much like to add and stabilize boolean accessors for the various parts of : , , , and (we could call the last one but that seems like a genuinely excessive name). It's pretty unfortunate we stabilized the accessor in the first place IMO, but oh well. I'm a little less sure about , though. What is returned if no fill character was specified? Why doesn't it return an like the others? Is sufficient? Should it be a full grapheme instead?
I'd be fine just deprecating the method (it's basically useless without constants anyway) and adding boolean accessors, I agree that it better matches design in today's Rust. I'd also be fine making return an and just specifying that it's always one unicode character (it's how the format string is parsed). Perhaps in theory a grapheme could be specified but that seems like something for an even fancier formatting system!
This issue is now entering its cycle-long FCP for stabilization in 1.5 The accessors being in will also be considered for stabilization.
Ah, and may be good to get your opinion on the grapheme-vs- situation here. Currently whenever something is formatted you have the ability to specify a "fill" character which for when padding is applied (normally this is just an ascii space). As points out this fill is currently just a , but it could in theory be a grapheme in terms of "one thing on the screen". Do you have an opinion either way in that regard? Curious to hear thoughts!
Uh. It’s not just graphemes. The whole // thing in as currently written is based on some assumptions: ’re printing to something that (like most terminal emulators) align text on a grid . Unfortunately, as often with Unicode, it’s complicated. Not only grapheme clusters can have more than one code point and still only use one slot (with combining code points), but most characters of some Asian languages and most emoji are “full width”: they’re twice the usual width in most monospace fonts. Control characters be displayed. Or they might be interpreted by the terminal to move the cursor around. has some more background. Here is an extract, about emoji flags: Our best bet for ”what is the width of this string?” is probably That leaves dealing with if it’s double width or a control character. If we want to do it, could be an arbitrary string rather than a single ? Or should be rejected?
Hm, those are very good points! I would be mostly tempted to just pare down everything and say it largely deals with ascii only (and maybe simple unicode?). I don't think it'd be too beneficial to start getting full-blown unicode-width support in libcore just to support a use case like this. Having some verification in the compiler, however, to make sure you're not doing crazy things seems reasonable? In theory, yes. I'd also be fine with this!
The libs team discussed this during triage today and the decision was to stabilize.
Triage: looks like this was stabilized, closing!
is still unstable, linking to this issue:
I am a bit confused about the reason is still unstable. Is it because is only available from ? Is there anything I can help with to move this along?
Nominating for stabilization. I suspect that needs to be re-exported in std, but that seems like something trivial to solve while stabilizing. The only concern that I see left is that there appear to be 3 separate, but equivalent, definition of the enum in the various libraries. These should probably be de-duplicated, but again, since only one appears to be public, we can probably do this trivially as well during stabilization.
I think we should remove and return an instead, but it seems reasonable to stabilize. fcp merge
Team member has proposed to merge this. The next step is review by the rest of the tagged teams: [x] [x] [x] [x] [x] [x] [x] [x] No concerns currently listed. Once these reviewers reach consensus, this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up! See for info about what commands tagged team members can give me.
:bell: This is now entering its final comment period, as per the . :bell:
:bell: This is now entering its final comment period, as per the . :bell:
The final comment period is now complete.
Shouldn't this get merged then?
Yes, with FCP to stabilize completed, the next step is a stabilization PR.

} // The sign and prefix goes before the padding if the fill character // is zero <del> Some(min) if self.flags & (1 << (FlagV1::SignAwareZeroPad as u32)) != 0 => { </del> <ins> Some(min) if self.sign_aware_zero_pad() => { </ins> self.fill = '0'; try!(write_prefix(self)); self.with_padding(min - width, Alignment::Right, |f| {


Question:
Tracking issue for the feature, which is  and the associated enum.
Yes, please. Why? Makes little sense.
I disagree that it makes little sense to expose getters, it's possible to envision a situation where one formatting is composed of many others and you perhaps want some to be formatted to various widths or perhaps enable various flags (e.g. the "alternate" mode). It's certainly niche but it's somewhat necessary for completeness.
, , and all seem straightforward and can be stabilized as-is. I would also very much like to add and stabilize boolean accessors for the various parts of : , , , and (we could call the last one but that seems like a genuinely excessive name). It's pretty unfortunate we stabilized the accessor in the first place IMO, but oh well. I'm a little less sure about , though. What is returned if no fill character was specified? Why doesn't it return an like the others? Is sufficient? Should it be a full grapheme instead?
I'd be fine just deprecating the method (it's basically useless without constants anyway) and adding boolean accessors, I agree that it better matches design in today's Rust. I'd also be fine making return an and just specifying that it's always one unicode character (it's how the format string is parsed). Perhaps in theory a grapheme could be specified but that seems like something for an even fancier formatting system!
This issue is now entering its cycle-long FCP for stabilization in 1.5 The accessors being in will also be considered for stabilization.
Ah, and may be good to get your opinion on the grapheme-vs- situation here. Currently whenever something is formatted you have the ability to specify a "fill" character which for when padding is applied (normally this is just an ascii space). As points out this fill is currently just a , but it could in theory be a grapheme in terms of "one thing on the screen". Do you have an opinion either way in that regard? Curious to hear thoughts!
Uh. It’s not just graphemes. The whole // thing in as currently written is based on some assumptions: ’re printing to something that (like most terminal emulators) align text on a grid . Unfortunately, as often with Unicode, it’s complicated. Not only grapheme clusters can have more than one code point and still only use one slot (with combining code points), but most characters of some Asian languages and most emoji are “full width”: they’re twice the usual width in most monospace fonts. Control characters be displayed. Or they might be interpreted by the terminal to move the cursor around. has some more background. Here is an extract, about emoji flags: Our best bet for ”what is the width of this string?” is probably That leaves dealing with if it’s double width or a control character. If we want to do it, could be an arbitrary string rather than a single ? Or should be rejected?
Hm, those are very good points! I would be mostly tempted to just pare down everything and say it largely deals with ascii only (and maybe simple unicode?). I don't think it'd be too beneficial to start getting full-blown unicode-width support in libcore just to support a use case like this. Having some verification in the compiler, however, to make sure you're not doing crazy things seems reasonable? In theory, yes. I'd also be fine with this!
The libs team discussed this during triage today and the decision was to stabilize.
Triage: looks like this was stabilized, closing!
is still unstable, linking to this issue:
I am a bit confused about the reason is still unstable. Is it because is only available from ? Is there anything I can help with to move this along?
Nominating for stabilization. I suspect that needs to be re-exported in std, but that seems like something trivial to solve while stabilizing. The only concern that I see left is that there appear to be 3 separate, but equivalent, definition of the enum in the various libraries. These should probably be de-duplicated, but again, since only one appears to be public, we can probably do this trivially as well during stabilization.
I think we should remove and return an instead, but it seems reasonable to stabilize. fcp merge
Team member has proposed to merge this. The next step is review by the rest of the tagged teams: [x] [x] [x] [x] [x] [x] [x] [x] No concerns currently listed. Once these reviewers reach consensus, this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up! See for info about what commands tagged team members can give me.
:bell: This is now entering its final comment period, as per the . :bell:
:bell: This is now entering its final comment period, as per the . :bell:
The final comment period is now complete.
Shouldn't this get merged then?
Yes, with FCP to stabilize completed, the next step is a stabilization PR.

let mut formatted = formatted.clone(); let mut align = self.align; let old_fill = self.fill; <del> if self.flags & (1 << (FlagV1::SignAwareZeroPad as u32)) != 0 { </del> <ins> if self.sign_aware_zero_pad() { </ins> // a sign always goes first let sign = unsafe { str::from_utf8_unchecked(formatted.sign) }; try!(self.buf.write_str(sign));


Question:
Tracking issue for the feature, which is  and the associated enum.
Yes, please. Why? Makes little sense.
I disagree that it makes little sense to expose getters, it's possible to envision a situation where one formatting is composed of many others and you perhaps want some to be formatted to various widths or perhaps enable various flags (e.g. the "alternate" mode). It's certainly niche but it's somewhat necessary for completeness.
, , and all seem straightforward and can be stabilized as-is. I would also very much like to add and stabilize boolean accessors for the various parts of : , , , and (we could call the last one but that seems like a genuinely excessive name). It's pretty unfortunate we stabilized the accessor in the first place IMO, but oh well. I'm a little less sure about , though. What is returned if no fill character was specified? Why doesn't it return an like the others? Is sufficient? Should it be a full grapheme instead?
I'd be fine just deprecating the method (it's basically useless without constants anyway) and adding boolean accessors, I agree that it better matches design in today's Rust. I'd also be fine making return an and just specifying that it's always one unicode character (it's how the format string is parsed). Perhaps in theory a grapheme could be specified but that seems like something for an even fancier formatting system!
This issue is now entering its cycle-long FCP for stabilization in 1.5 The accessors being in will also be considered for stabilization.
Ah, and may be good to get your opinion on the grapheme-vs- situation here. Currently whenever something is formatted you have the ability to specify a "fill" character which for when padding is applied (normally this is just an ascii space). As points out this fill is currently just a , but it could in theory be a grapheme in terms of "one thing on the screen". Do you have an opinion either way in that regard? Curious to hear thoughts!
Uh. It’s not just graphemes. The whole // thing in as currently written is based on some assumptions: ’re printing to something that (like most terminal emulators) align text on a grid . Unfortunately, as often with Unicode, it’s complicated. Not only grapheme clusters can have more than one code point and still only use one slot (with combining code points), but most characters of some Asian languages and most emoji are “full width”: they’re twice the usual width in most monospace fonts. Control characters be displayed. Or they might be interpreted by the terminal to move the cursor around. has some more background. Here is an extract, about emoji flags: Our best bet for ”what is the width of this string?” is probably That leaves dealing with if it’s double width or a control character. If we want to do it, could be an arbitrary string rather than a single ? Or should be rejected?
Hm, those are very good points! I would be mostly tempted to just pare down everything and say it largely deals with ascii only (and maybe simple unicode?). I don't think it'd be too beneficial to start getting full-blown unicode-width support in libcore just to support a use case like this. Having some verification in the compiler, however, to make sure you're not doing crazy things seems reasonable? In theory, yes. I'd also be fine with this!
The libs team discussed this during triage today and the decision was to stabilize.
Triage: looks like this was stabilized, closing!
is still unstable, linking to this issue:
I am a bit confused about the reason is still unstable. Is it because is only available from ? Is there anything I can help with to move this along?
Nominating for stabilization. I suspect that needs to be re-exported in std, but that seems like something trivial to solve while stabilizing. The only concern that I see left is that there appear to be 3 separate, but equivalent, definition of the enum in the various libraries. These should probably be de-duplicated, but again, since only one appears to be public, we can probably do this trivially as well during stabilization.
I think we should remove and return an instead, but it seems reasonable to stabilize. fcp merge
Team member has proposed to merge this. The next step is review by the rest of the tagged teams: [x] [x] [x] [x] [x] [x] [x] [x] No concerns currently listed. Once these reviewers reach consensus, this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up! See for info about what commands tagged team members can give me.
:bell: This is now entering its final comment period, as per the . :bell:
:bell: This is now entering its final comment period, as per the . :bell:
The final comment period is now complete.
Shouldn't this get merged then?
Yes, with FCP to stabilize completed, the next step is a stabilization PR.

issue = "27726")] pub fn precision(&self) -> Option<usize> { self.precision } <ins> /// Determines if the `+` flag was specified. #[unstable(feature = "fmt_flags", reason = "method was just created", issue = "27726")] pub fn sign_plus(&self) -> bool { self.flags & (1 << FlagV1::SignPlus as u32) != 0 } /// Determines if the `-` flag was specified. #[unstable(feature = "fmt_flags", reason = "method was just created", issue = "27726")] pub fn sign_minus(&self) -> bool { self.flags & (1 << FlagV1::SignMinus as u32) != 0 } /// Determines if the `#` flag was specified. #[unstable(feature = "fmt_flags", reason = "method was just created", issue = "27726")] pub fn alternate(&self) -> bool { self.flags & (1 << FlagV1::Alternate as u32) != 0 } /// Determines if the `0` flag was specified. #[unstable(feature = "fmt_flags", reason = "method was just created", issue = "27726")] pub fn sign_aware_zero_pad(&self) -> bool { self.flags & (1 << FlagV1::SignAwareZeroPad as u32) != 0 } </ins> /// Creates a `DebugStruct` builder designed to assist with creation of /// `fmt::Debug` implementations for structs. ///


Question:
Tracking issue for the feature, which is  and the associated enum.
Yes, please. Why? Makes little sense.
I disagree that it makes little sense to expose getters, it's possible to envision a situation where one formatting is composed of many others and you perhaps want some to be formatted to various widths or perhaps enable various flags (e.g. the "alternate" mode). It's certainly niche but it's somewhat necessary for completeness.
, , and all seem straightforward and can be stabilized as-is. I would also very much like to add and stabilize boolean accessors for the various parts of : , , , and (we could call the last one but that seems like a genuinely excessive name). It's pretty unfortunate we stabilized the accessor in the first place IMO, but oh well. I'm a little less sure about , though. What is returned if no fill character was specified? Why doesn't it return an like the others? Is sufficient? Should it be a full grapheme instead?
I'd be fine just deprecating the method (it's basically useless without constants anyway) and adding boolean accessors, I agree that it better matches design in today's Rust. I'd also be fine making return an and just specifying that it's always one unicode character (it's how the format string is parsed). Perhaps in theory a grapheme could be specified but that seems like something for an even fancier formatting system!
This issue is now entering its cycle-long FCP for stabilization in 1.5 The accessors being in will also be considered for stabilization.
Ah, and may be good to get your opinion on the grapheme-vs- situation here. Currently whenever something is formatted you have the ability to specify a "fill" character which for when padding is applied (normally this is just an ascii space). As points out this fill is currently just a , but it could in theory be a grapheme in terms of "one thing on the screen". Do you have an opinion either way in that regard? Curious to hear thoughts!
Uh. It’s not just graphemes. The whole // thing in as currently written is based on some assumptions: ’re printing to something that (like most terminal emulators) align text on a grid . Unfortunately, as often with Unicode, it’s complicated. Not only grapheme clusters can have more than one code point and still only use one slot (with combining code points), but most characters of some Asian languages and most emoji are “full width”: they’re twice the usual width in most monospace fonts. Control characters be displayed. Or they might be interpreted by the terminal to move the cursor around. has some more background. Here is an extract, about emoji flags: Our best bet for ”what is the width of this string?” is probably That leaves dealing with if it’s double width or a control character. If we want to do it, could be an arbitrary string rather than a single ? Or should be rejected?
Hm, those are very good points! I would be mostly tempted to just pare down everything and say it largely deals with ascii only (and maybe simple unicode?). I don't think it'd be too beneficial to start getting full-blown unicode-width support in libcore just to support a use case like this. Having some verification in the compiler, however, to make sure you're not doing crazy things seems reasonable? In theory, yes. I'd also be fine with this!
The libs team discussed this during triage today and the decision was to stabilize.
Triage: looks like this was stabilized, closing!
is still unstable, linking to this issue:
I am a bit confused about the reason is still unstable. Is it because is only available from ? Is there anything I can help with to move this along?
Nominating for stabilization. I suspect that needs to be re-exported in std, but that seems like something trivial to solve while stabilizing. The only concern that I see left is that there appear to be 3 separate, but equivalent, definition of the enum in the various libraries. These should probably be de-duplicated, but again, since only one appears to be public, we can probably do this trivially as well during stabilization.
I think we should remove and return an instead, but it seems reasonable to stabilize. fcp merge
Team member has proposed to merge this. The next step is review by the rest of the tagged teams: [x] [x] [x] [x] [x] [x] [x] [x] No concerns currently listed. Once these reviewers reach consensus, this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up! See for info about what commands tagged team members can give me.
:bell: This is now entering its final comment period, as per the . :bell:
:bell: This is now entering its final comment period, as per the . :bell:
The final comment period is now complete.
Shouldn't this get merged then?
Yes, with FCP to stabilize completed, the next step is a stabilization PR.

// it denotes whether to prefix with 0x. We use it to work out whether // or not to zero extend, and then unconditionally set it to get the // prefix. <del> if f.flags & 1 << (FlagV1::Alternate as u32) > 0 { </del> <ins> if f.alternate() { </ins> f.flags |= 1 << (FlagV1::SignAwareZeroPad as u32); if let None = f.width {


Question:
Tracking issue for the feature, which is  and the associated enum.
Yes, please. Why? Makes little sense.
I disagree that it makes little sense to expose getters, it's possible to envision a situation where one formatting is composed of many others and you perhaps want some to be formatted to various widths or perhaps enable various flags (e.g. the "alternate" mode). It's certainly niche but it's somewhat necessary for completeness.
, , and all seem straightforward and can be stabilized as-is. I would also very much like to add and stabilize boolean accessors for the various parts of : , , , and (we could call the last one but that seems like a genuinely excessive name). It's pretty unfortunate we stabilized the accessor in the first place IMO, but oh well. I'm a little less sure about , though. What is returned if no fill character was specified? Why doesn't it return an like the others? Is sufficient? Should it be a full grapheme instead?
I'd be fine just deprecating the method (it's basically useless without constants anyway) and adding boolean accessors, I agree that it better matches design in today's Rust. I'd also be fine making return an and just specifying that it's always one unicode character (it's how the format string is parsed). Perhaps in theory a grapheme could be specified but that seems like something for an even fancier formatting system!
This issue is now entering its cycle-long FCP for stabilization in 1.5 The accessors being in will also be considered for stabilization.
Ah, and may be good to get your opinion on the grapheme-vs- situation here. Currently whenever something is formatted you have the ability to specify a "fill" character which for when padding is applied (normally this is just an ascii space). As points out this fill is currently just a , but it could in theory be a grapheme in terms of "one thing on the screen". Do you have an opinion either way in that regard? Curious to hear thoughts!
Uh. It’s not just graphemes. The whole // thing in as currently written is based on some assumptions: ’re printing to something that (like most terminal emulators) align text on a grid . Unfortunately, as often with Unicode, it’s complicated. Not only grapheme clusters can have more than one code point and still only use one slot (with combining code points), but most characters of some Asian languages and most emoji are “full width”: they’re twice the usual width in most monospace fonts. Control characters be displayed. Or they might be interpreted by the terminal to move the cursor around. has some more background. Here is an extract, about emoji flags: Our best bet for ”what is the width of this string?” is probably That leaves dealing with if it’s double width or a control character. If we want to do it, could be an arbitrary string rather than a single ? Or should be rejected?
Hm, those are very good points! I would be mostly tempted to just pare down everything and say it largely deals with ascii only (and maybe simple unicode?). I don't think it'd be too beneficial to start getting full-blown unicode-width support in libcore just to support a use case like this. Having some verification in the compiler, however, to make sure you're not doing crazy things seems reasonable? In theory, yes. I'd also be fine with this!
The libs team discussed this during triage today and the decision was to stabilize.
Triage: looks like this was stabilized, closing!
is still unstable, linking to this issue:
I am a bit confused about the reason is still unstable. Is it because is only available from ? Is there anything I can help with to move this along?
Nominating for stabilization. I suspect that needs to be re-exported in std, but that seems like something trivial to solve while stabilizing. The only concern that I see left is that there appear to be 3 separate, but equivalent, definition of the enum in the various libraries. These should probably be de-duplicated, but again, since only one appears to be public, we can probably do this trivially as well during stabilization.
I think we should remove and return an instead, but it seems reasonable to stabilize. fcp merge
Team member has proposed to merge this. The next step is review by the rest of the tagged teams: [x] [x] [x] [x] [x] [x] [x] [x] No concerns currently listed. Once these reviewers reach consensus, this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up! See for info about what commands tagged team members can give me.
:bell: This is now entering its final comment period, as per the . :bell:
:bell: This is now entering its final comment period, as per the . :bell:
The final comment period is now complete.
Shouldn't this get merged then?
Yes, with FCP to stabilize completed, the next step is a stabilization PR.

fn float_to_decimal_common<T>(fmt: &mut Formatter, num: &T, negative_zero: bool) -> Result where T: flt2dec::DecodableFloat { <del> let force_sign = fmt.flags & (1 << (FlagV1::SignPlus as u32)) != 0; </del> <ins> let force_sign = fmt.sign_plus(); </ins> let sign = match (force_sign, negative_zero) { (false, false) => flt2dec::Sign::Minus, (false, true)  => flt2dec::Sign::MinusRaw,


Question:
Tracking issue for the feature, which is  and the associated enum.
Yes, please. Why? Makes little sense.
I disagree that it makes little sense to expose getters, it's possible to envision a situation where one formatting is composed of many others and you perhaps want some to be formatted to various widths or perhaps enable various flags (e.g. the "alternate" mode). It's certainly niche but it's somewhat necessary for completeness.
, , and all seem straightforward and can be stabilized as-is. I would also very much like to add and stabilize boolean accessors for the various parts of : , , , and (we could call the last one but that seems like a genuinely excessive name). It's pretty unfortunate we stabilized the accessor in the first place IMO, but oh well. I'm a little less sure about , though. What is returned if no fill character was specified? Why doesn't it return an like the others? Is sufficient? Should it be a full grapheme instead?
I'd be fine just deprecating the method (it's basically useless without constants anyway) and adding boolean accessors, I agree that it better matches design in today's Rust. I'd also be fine making return an and just specifying that it's always one unicode character (it's how the format string is parsed). Perhaps in theory a grapheme could be specified but that seems like something for an even fancier formatting system!
This issue is now entering its cycle-long FCP for stabilization in 1.5 The accessors being in will also be considered for stabilization.
Ah, and may be good to get your opinion on the grapheme-vs- situation here. Currently whenever something is formatted you have the ability to specify a "fill" character which for when padding is applied (normally this is just an ascii space). As points out this fill is currently just a , but it could in theory be a grapheme in terms of "one thing on the screen". Do you have an opinion either way in that regard? Curious to hear thoughts!
Uh. It’s not just graphemes. The whole // thing in as currently written is based on some assumptions: ’re printing to something that (like most terminal emulators) align text on a grid . Unfortunately, as often with Unicode, it’s complicated. Not only grapheme clusters can have more than one code point and still only use one slot (with combining code points), but most characters of some Asian languages and most emoji are “full width”: they’re twice the usual width in most monospace fonts. Control characters be displayed. Or they might be interpreted by the terminal to move the cursor around. has some more background. Here is an extract, about emoji flags: Our best bet for ”what is the width of this string?” is probably That leaves dealing with if it’s double width or a control character. If we want to do it, could be an arbitrary string rather than a single ? Or should be rejected?
Hm, those are very good points! I would be mostly tempted to just pare down everything and say it largely deals with ascii only (and maybe simple unicode?). I don't think it'd be too beneficial to start getting full-blown unicode-width support in libcore just to support a use case like this. Having some verification in the compiler, however, to make sure you're not doing crazy things seems reasonable? In theory, yes. I'd also be fine with this!
The libs team discussed this during triage today and the decision was to stabilize.
Triage: looks like this was stabilized, closing!
is still unstable, linking to this issue:
I am a bit confused about the reason is still unstable. Is it because is only available from ? Is there anything I can help with to move this along?
Nominating for stabilization. I suspect that needs to be re-exported in std, but that seems like something trivial to solve while stabilizing. The only concern that I see left is that there appear to be 3 separate, but equivalent, definition of the enum in the various libraries. These should probably be de-duplicated, but again, since only one appears to be public, we can probably do this trivially as well during stabilization.
I think we should remove and return an instead, but it seems reasonable to stabilize. fcp merge
Team member has proposed to merge this. The next step is review by the rest of the tagged teams: [x] [x] [x] [x] [x] [x] [x] [x] No concerns currently listed. Once these reviewers reach consensus, this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up! See for info about what commands tagged team members can give me.
:bell: This is now entering its final comment period, as per the . :bell:
:bell: This is now entering its final comment period, as per the . :bell:
The final comment period is now complete.
Shouldn't this get merged then?
Yes, with FCP to stabilize completed, the next step is a stabilization PR.

fn float_to_exponential_common<T>(fmt: &mut Formatter, num: &T, upper: bool) -> Result where T: flt2dec::DecodableFloat { <del> let force_sign = fmt.flags & (1 << (FlagV1::SignPlus as u32)) != 0; </del> <ins> let force_sign = fmt.sign_plus(); </ins> let sign = match force_sign { false => flt2dec::Sign::Minus, true  => flt2dec::Sign::MinusPlus,


Question:
This compiles and runs without warnings: I at least expected the unused attribute lint to catch this
They are not ignored, it's just that attributes on item macros apply to the macro expansion rather than the resultant item, e.g this errors as expected as the macro isn't expanded.
Ah, and they're removed when the macro is expanded, which is why the lint doesn't pick them up.
Yeah as noted this is actually working as intended, so closing.
I still feel uneasy about the lint missing these attributes, but I guess that cannot be fixed unless the attribute system is rewritten

// // Local Variables: <del> // mode: C++ </del> <ins> // mode: rust </ins> // fill-column: 78; // indent-tabs-mode: nil // c-basic-offset: 4


Question:
When you search for something on the online docs (which I assume are generated using cargo doc) a list of results comes up. When you clear the search bar/press the X button it probably should clear the results to allow you to view the original page. Anyone know how to fix this?
I don't believe that we have anything set up for that. Is there an "X" button? I don't see it anywhere. Regardless, clearing the box or pressing escape or something should probably clear it, for sure.
! And then after clicking the "X": !
Search field is and therefore it might have various user agent specific functionality. Simpler way to reproduce in a cross-UA way would be to follow these steps: a search query; the whole query at once by highlighting it and clicking backspace, delete or any other relevant button; Result list not changing. We could go back to the page that was open before the search field was used to fix this. Note that we do know what page it was, because we simply append to the URI of the page we start the search at.
I took a shot at it and in the half an hour I dedicated to it, all I found that search code is a complete mess and this might be harder to fix correctly than it might appear at a first glance.

} function startSearch() { <ins> $(".search-input").on("keyup",function() { if ($(this).val().length === 0) { window.history.replaceState("", "std - Rust", "?search="); $('#main.content').removeClass('hidden'); $('#search.content').addClass('hidden'); } }); </ins> var keyUpTimeout; $('.do-search').on('click', search); $('.search-input').on('keyup', function() {


Question:
When trying to update uutils/coreutils to HEAD, I got this ICE: Version: code:
apparently, this happens as a side effect of the build process. i had built with stable, then tried to build with nightly, giving incorrect metadata

E0495, // cannot infer an appropriate lifetime due to conflicting requirements E0496, // .. name `..` shadows a .. name that is already in scope E0498, // malformed plugin attribute <ins> E0514, // metadata version mismatch </ins> }


Question:
When trying to update uutils/coreutils to HEAD, I got this ICE: Version: code:
apparently, this happens as a side effect of the build process. i had built with stable, then tried to build with nightly, giving incorrect metadata

pub const tag_impl_coerce_unsized_kind: usize = 0xa5; pub const tag_items_data_item_constness: usize = 0xa6; <ins> pub const tag_rustc_version: usize = 0x10f; pub fn rustc_version() -> String { format!( "rustc {}", option_env!("CFG_VERSION").unwrap_or("unknown version") ) } </ins>


Question:
When trying to update uutils/coreutils to HEAD, I got this ICE: Version: code:
apparently, this happens as a side effect of the build process. i had built with stable, then tried to build with nightly, giving incorrect metadata

use back::svh::Svh; use session::{config, Session}; use session::search_paths::PathKind; <ins> use metadata::common::rustc_version; </ins> use metadata::cstore; use metadata::cstore::{CStore, CrateSource, MetadataBlob}; use metadata::decoder;


Question:
When trying to update uutils/coreutils to HEAD, I got this ICE: Version: code:
apparently, this happens as a side effect of the build process. i had built with stable, then tried to build with nightly, giving incorrect metadata

return ret; } <ins> fn verify_rustc_version(&self, name: &str, span: Span, metadata: &MetadataBlob) { let crate_rustc_version = decoder::crate_rustc_version(metadata.as_slice()); if crate_rustc_version != Some(rustc_version()) { span_err!(self.sess, span, E0514, "the crate `{}` has been compiled with {}, which is  incompatible with this version of rustc", name, crate_rustc_version .as_ref().map(|s|&**s) .unwrap_or("an old version of rustc") ); self.sess.abort_if_errors(); } } </ins> fn register_crate(&mut self, root: &Option<CratePaths>, ident: &str,


Question:
When trying to update uutils/coreutils to HEAD, I got this ICE: Version: code:
apparently, this happens as a side effect of the build process. i had built with stable, then tried to build with nightly, giving incorrect metadata

explicitly_linked: bool) -> (ast::CrateNum, Rc<cstore::crate_metadata>, cstore::CrateSource) { <ins> self.verify_rustc_version(name, span, &lib.metadata); </ins> // Claim this crate number and cache it let cnum = self.next_crate_num; self.next_crate_num += 1;


Question:
When trying to update uutils/coreutils to HEAD, I got this ICE: Version: code:
apparently, this happens as a side effect of the build process. i had built with stable, then tried to build with nightly, giving incorrect metadata

index::Index::from_buf(index.data, index.start, index.end) } <ins> pub fn crate_rustc_version(data: &[u8]) -> Option<String> { let doc = rbml::Doc::new(data); reader::maybe_get_doc(doc, tag_rustc_version).map(|s| s.as_str()) } </ins> #[derive(Debug, PartialEq)] enum Family { ImmStatic,             // c


Question:
When trying to update uutils/coreutils to HEAD, I got this ICE: Version: code:
apparently, this happens as a side effect of the build process. i had built with stable, then tried to build with nightly, giving incorrect metadata

rbml_w.wr_tagged_str(tag_crate_hash, hash.as_str()); } <ins> fn encode_rustc_version(rbml_w: &mut Encoder) { rbml_w.wr_tagged_str(tag_rustc_version, &rustc_version()); } </ins> fn encode_crate_name(rbml_w: &mut Encoder, crate_name: &str) { rbml_w.wr_tagged_str(tag_crate_crate_name, crate_name); }


Question:
When trying to update uutils/coreutils to HEAD, I got this ICE: Version: code:
apparently, this happens as a side effect of the build process. i had built with stable, then tried to build with nightly, giving incorrect metadata

let mut rbml_w = Encoder::new(wr); <ins> encode_rustc_version(&mut rbml_w); </ins> encode_crate_name(&mut rbml_w, &ecx.link_meta.crate_name); encode_crate_triple(&mut rbml_w, &tcx.sess.opts.target_triple); encode_hash(&mut rbml_w, &ecx.link_meta.crate_hash);


Question:
When trying to update uutils/coreutils to HEAD, I got this ICE: Version: code:
apparently, this happens as a side effect of the build process. i had built with stable, then tried to build with nightly, giving incorrect metadata

// can just use the tcx as the typer. // // FIXME(stage0): the :'t here is probably only important for stage0 <del> pub struct ExprUseVisitor<'d, 't, 'a: 't, 'tcx:'a+'d+'t> { </del> <ins> pub struct ExprUseVisitor<'d, 't, 'a: 't, 'tcx:'a+'d> { </ins> typer: &'t infer::InferCtxt<'a, 'tcx>, mc: mc::MemCategorizationContext<'t, 'a, 'tcx>, delegate: &'d mut Delegate<'tcx>,


Question:
When trying to update uutils/coreutils to HEAD, I got this ICE: Version: code:
apparently, this happens as a side effect of the build process. i had built with stable, then tried to build with nightly, giving incorrect metadata

impl<'d,'t,'a,'tcx> ExprUseVisitor<'d,'t,'a,'tcx> { pub fn new(delegate: &'d mut Delegate<'tcx>, typer: &'t infer::InferCtxt<'a, 'tcx>) <del> -> ExprUseVisitor<'d,'t,'a,'tcx> </del> <ins> -> ExprUseVisitor<'d,'t,'a,'tcx> where 'tcx:'a </ins> { ExprUseVisitor { typer: typer,


Question:
The first section on can be difficult to understand for novice programmers, particularly the line "Anonymous functions that have an associated environment are called ‘closures’, because they close over an environment." It's difficult from this context to understand what "environment" is referring to.
Yeah, this definition is kind of embarassingly self-referential :sweat:
I'm going to try to clarify this.
fixed this

% Closures <del> Rust not only has named functions, but anonymous functions as well. Anonymous functions that have an associated environment are called ‘closures’, because they close over an environment. Rust has a really great implementation of them, as we’ll see. </del> <ins> Sometimes it is useful to wrap up a function and _free variables_ for better clarity and reuse. The free variables that can be used come from the enclosing scope and are ‘closed over’ when used in the function. From this, we get the name ‘closures’ and Rust provides a really great implementation of them, as we’ll see. </ins> # Syntax


Question:
The first section on can be difficult to understand for novice programmers, particularly the line "Anonymous functions that have an associated environment are called ‘closures’, because they close over an environment." It's difficult from this context to understand what "environment" is referring to.
Yeah, this definition is kind of embarassingly self-referential :sweat:
I'm going to try to clarify this.
fixed this

``` You’ll notice a few things about closures that are a bit different from regular <del> functions defined with `fn`. The first is that we did not need to </del> <ins> named functions defined with `fn`. The first is that we did not need to </ins> annotate the types of arguments the closure takes or the values it returns. We can:


Question:
The first section on can be difficult to understand for novice programmers, particularly the line "Anonymous functions that have an associated environment are called ‘closures’, because they close over an environment." It's difficult from this context to understand what "environment" is referring to.
Yeah, this definition is kind of embarassingly self-referential :sweat:
I'm going to try to clarify this.
fixed this

assert_eq!(2, plus_one(1)); ``` <del> But we don’t have to. Why is this? Basically, it was chosen for ergonomic reasons. While specifying the full type for named functions is helpful with things like documentation and type inference, the types of closures are rarely documented since they’re anonymous, and they don’t cause the kinds of error-at-a-distance problems that inferring named function types can. </del> <ins> But we don’t have to. Why is this? Basically, it was chosen for ergonomic reasons. While specifying the full type for named functions is helpful with things like documentation and type inference, the full type signatures of closures are rarely documented since they’re anonymous, and they don’t cause the kinds of error-at-a-distance problems that inferring named function types can. </ins> <del> The second is that the syntax is similar, but a bit different. I’ve added spaces here for easier comparison: </del> <ins> The second is that the syntax is similar, but a bit different. I’ve added spaces here for easier comparison: </ins> ```rust fn  plus_one_v1   (x: i32) -> i32 { x + 1 }


Question:
The first section on can be difficult to understand for novice programmers, particularly the line "Anonymous functions that have an associated environment are called ‘closures’, because they close over an environment." It's difficult from this context to understand what "environment" is referring to.
Yeah, this definition is kind of embarassingly self-referential :sweat:
I'm going to try to clarify this.
fixed this

# Closures and their environment <del> Closures are called such because they ‘close over their environment’. It looks like this: </del> <ins> The environment for a closure can include bindings from its enclosing scope in addition to parameters and local bindings. It looks like this: </ins> ```rust let num = 5;


Question:
The first section on can be difficult to understand for novice programmers, particularly the line "Anonymous functions that have an associated environment are called ‘closures’, because they close over an environment." It's difficult from this context to understand what "environment" is referring to.
Yeah, this definition is kind of embarassingly self-referential :sweat:
I'm going to try to clarify this.
fixed this

it, while a `move` closure is self-contained. This means that you cannot generally return a non-`move` closure from a function, for example. <del> But before we talk about taking and returning closures, we should talk some more about the way that closures are implemented. As a systems language, Rust gives you tons of control over what your code does, and closures are no different. </del> <ins> But before we talk about taking and returning closures, we should talk some more about the way that closures are implemented. As a systems language, Rust gives you tons of control over what your code does, and closures are no different. </ins> # Closure implementation


Question:
The first section on can be difficult to understand for novice programmers, particularly the line "Anonymous functions that have an associated environment are called ‘closures’, because they close over an environment." It's difficult from this context to understand what "environment" is referring to.
Yeah, this definition is kind of embarassingly self-referential :sweat:
I'm going to try to clarify this.
fixed this

#   some_closure(1) } ``` <del> Because `Fn` is a trait, we can bound our generic with it. In this case, our closure takes a `i32` as an argument and returns an `i32`, and so the generic bound we use is `Fn(i32) -> i32`. </del> <ins> Because `Fn` is a trait, we can bound our generic with it. In this case, our closure takes a `i32` as an argument and returns an `i32`, and so the generic bound we use is `Fn(i32) -> i32`. </ins> There’s one other key point here: because we’re bounding a generic with a trait, this will get monomorphized, and therefore, we’ll be doing static


Question:
The first section on can be difficult to understand for novice programmers, particularly the line "Anonymous functions that have an associated environment are called ‘closures’, because they close over an environment." It's difficult from this context to understand what "environment" is referring to.
Yeah, this definition is kind of embarassingly self-referential :sweat:
I'm going to try to clarify this.
fixed this

The error also points out that the return type is expected to be a reference, but what we are trying to return is not. Further, we cannot directly assign a `'static` lifetime to an object. So we'll take a different approach and return <del> a "trait object" by `Box`ing up the `Fn`. This _almost_ works: </del> <ins> a ‘trait object’ by `Box`ing up the `Fn`. This _almost_ works: </ins> ```rust,ignore fn factory() -> Box<Fn(i32) -> i32> {


Question:
After some discussion about the libs subteam decided that iterator adaptors should always preserve the same semantics in terms of the convenience methods and such. This was not audited for when all the initial specializations landed, so we should take a look and make sure that everything adheres to this policy. Additionally, documentation should be to the trait methods indicating what form of guarantees you are given (e.g. calling is equivalent to exhausting the iterator). triage: I-nominated
I've checked . should exhaust before but that's the only bug I found (and it wasn't my bug for once :tada:). Unless, of course, you care about drop order. I haven't tried to reason about that.
The slice iterators () are fine because they are side-effect free.
and are fine because they are also side-effect free.
I'd appreciate it if someone else double checked but I think that's all of them.
This is relevant as well, because implementations of Drop may also (and usually do, in form of memory deallocation) contain side effects. Can we make a [x] list [x] of iterators which were specialised [x] like this?
I strongly disagree. Drop has side effects but programmers should never rely on drop order except stack drop order because drop order is often unspecified (e.g. within structs). core::iter::Chain::last core::iter::Peekable::last core::iter::Peekable::count (fixable) core::iter::Skip::last (fixable?)[x] core::iter::Chain [x] core::iter::Enumerate [x] core::iter::Peekable [x] core::iter::Skip [x] core::iter::Take [x] core::iter::Fuse [x] core::str::Bytes [x] core::slice::Iter [x] core::slice::IterMut [x] core::slice::Windows [x] core::slice::Chunks [x] core::slice::ChunksMut [x] collections::vec::IntoIter
Ah right, this will be decided by anyway.
Awesome, thanks for the work here
Updated list of out-of-order drops (didn't notice ).
triage: P-medium
(Need to make sure this behavior is documented/explicitly promised.)
Is this done? (Everything in the list above is :whitecheckmark:'d)
I believe this is left open as to-be-documented. Also, I don't see any decision as to whether out of order drop is ok.
re-tagging as docs
So I believe that all of these are then documented in Iterator's methods, at least as far as I can tell. Can someone from libs double check me here and help provide any specifics as to what's not documented?
Looks good to me, thanks

#[inline] fn last(self) -> Option<A::Item> { match self.state { <del> ChainState::Both => self.b.last().or(self.a.last()), </del> <ins> ChainState::Both => { // Must exhaust a before b. let a_last = self.a.last(); let b_last = self.b.last(); b_last.or(a_last) }, </ins> ChainState::Front => self.a.last(), ChainState::Back => self.b.last() }


Question:
After having first read about iterators the TRPL book, it called my attention the scarce number of matching results in the API docs for a query like "iterator adapters". Curiously enough, it looks like the term used there is "adaptors" instead of adapters. Appearances @ TRPL(): "iterator adapters" -7 "iterator adaptors" -1 (part of compilation output) Appearances @ API docs(): "iterator adapters" -1 (book) "iterator adaptors" -158  Appearances found using typical 'Search in directory' feature in a text editor.  Appearances found using the site search filter in Google, ie. "iterator adaptors" Assuming that there aren't semantics involved between these two words in English, I'd like to know what's your opinion on the next steps to take (so we can avoid the inconsistency and possible confusion). What about replacing 'adapters' to 'adaptors' everywhere in the book?
I assume this was fixed by ?
Yes, this issue can be safely closed now.

talk about what you do want instead. There are three broad classes of things that are relevant here: iterators, <del> *iterator adapters*, and *consumers*. Here's some definitions: </del> <ins> *iterator adaptors*, and *consumers*. Here's some definitions: </ins> * *iterators* give you a sequence of values. <del> * *iterator adapters* operate on an iterator, producing a new iterator with a </del> <ins> * *iterator adaptors* operate on an iterator, producing a new iterator with a </ins> different output sequence. * *consumers* operate on an iterator, producing some final set of values.


Question:
After having first read about iterators the TRPL book, it called my attention the scarce number of matching results in the API docs for a query like "iterator adapters". Curiously enough, it looks like the term used there is "adaptors" instead of adapters. Appearances @ TRPL(): "iterator adapters" -7 "iterator adaptors" -1 (part of compilation output) Appearances @ API docs(): "iterator adapters" -1 (book) "iterator adaptors" -158  Appearances found using typical 'Search in directory' feature in a text editor.  Appearances found using the site search filter in Google, ie. "iterator adaptors" Assuming that there aren't semantics involved between these two words in English, I'd like to know what's your opinion on the next steps to take (so we can avoid the inconsistency and possible confusion). What about replacing 'adapters' to 'adaptors' everywhere in the book?
I assume this was fixed by ?
Yes, this issue can be safely closed now.

These two basic iterators should serve you well. There are some more advanced iterators, including ones that are infinite. <del> That's enough about iterators. Iterator adapters are the last concept </del> <ins> That's enough about iterators. Iterator adaptors are the last concept </ins> we need to talk about with regards to iterators. Let's get to it! <del> ## Iterator adapters </del> <ins> ## Iterator adaptors </ins> <del> *Iterator adapters* take an iterator and modify it somehow, producing </del> <ins> *Iterator adaptors* take an iterator and modify it somehow, producing </ins> a new iterator. The simplest one is called `map`: ```rust,ignore


Question:
After having first read about iterators the TRPL book, it called my attention the scarce number of matching results in the API docs for a query like "iterator adapters". Curiously enough, it looks like the term used there is "adaptors" instead of adapters. Appearances @ TRPL(): "iterator adapters" -7 "iterator adaptors" -1 (part of compilation output) Appearances @ API docs(): "iterator adapters" -1 (book) "iterator adaptors" -158  Appearances found using typical 'Search in directory' feature in a text editor.  Appearances found using the site search filter in Google, ie. "iterator adaptors" Assuming that there aren't semantics involved between these two words in English, I'd like to know what's your opinion on the next steps to take (so we can avoid the inconsistency and possible confusion). What about replacing 'adapters' to 'adaptors' everywhere in the book?
I assume this was fixed by ?
Yes, this issue can be safely closed now.

If you are trying to execute a closure on an iterator for its side effects, just use `for` instead. <del> There are tons of interesting iterator adapters. `take(n)` will return an </del> <ins> There are tons of interesting iterator adaptors. `take(n)` will return an </ins> iterator over the next `n` elements of the original iterator. Let's try it out with an infinite iterator:


Question:
After having first read about iterators the TRPL book, it called my attention the scarce number of matching results in the API docs for a query like "iterator adapters". Curiously enough, it looks like the term used there is "adaptors" instead of adapters. Appearances @ TRPL(): "iterator adapters" -7 "iterator adaptors" -1 (part of compilation output) Appearances @ API docs(): "iterator adapters" -1 (book) "iterator adaptors" -158  Appearances found using typical 'Search in directory' feature in a text editor.  Appearances found using the site search filter in Google, ie. "iterator adaptors" Assuming that there aren't semantics involved between these two words in English, I'd like to know what's your opinion on the next steps to take (so we can avoid the inconsistency and possible confusion). What about replacing 'adapters' to 'adaptors' everywhere in the book?
I assume this was fixed by ?
Yes, this issue can be safely closed now.

This will give you a vector containing `6`, `12`, `18`, `24`, and `30`. <del> This is just a small taste of what iterators, iterator adapters, and consumers </del> <ins> This is just a small taste of what iterators, iterator adaptors, and consumers </ins> can help you with. There are a number of really useful iterators, and you can write your own as well. Iterators provide a safe, efficient way to manipulate all kinds of lists. They're a little unusual at first, but if you play with


Question:
The following code compiles on stable and beta, but not nightly: For reference, the error produced by the above is: The original test case was reduced down to the above thanks to eddyb and bluss. The original problematic line was (clap → → → boom). Specifically, the issue was with the method, though the error pointed to an earlier temporary as not living long enough. If desired, I can provide a complete, in-context example of this going awry. bluss suggested that this was related to .
cc
Hmm I wonder if the iterators involved need to have the escape hatch for dropck to them.
Here is a variant (that has also regressed) that does not use the macro:
(It looks like may need similar treatment too, but I am having trouble actually making a concrete test illustrating the necessity there -- it seems when I call instead of in the above test case, even stable and beta complain about lifetime issues. Maybe the old dropck is catching something I'm missing in my manual analysis of , so I'm not going to lump that in until I see evidence that it is warranted.) Update: Oh, duh, has a lifetime bound (and a impl), so of course the old dropck was going to reject it.

#[stable(feature = "rust1", since = "1.0.0")] impl<T> Drop for IntoIter<T> { <ins> #[unsafe_destructor_blind_to_params] </ins> fn drop(&mut self) { // destroy the remaining elements for _x in self {}


Question:
The following code compiles on stable and beta, but not nightly: For reference, the error produced by the above is: The original test case was reduced down to the above thanks to eddyb and bluss. The original problematic line was (clap → → → boom). Specifically, the issue was with the method, though the error pointed to an earlier temporary as not living long enough. If desired, I can provide a complete, in-context example of this going awry. bluss suggested that this was related to .
cc
Hmm I wonder if the iterators involved need to have the escape hatch for dropck to them.
Here is a variant (that has also regressed) that does not use the macro:
(It looks like may need similar treatment too, but I am having trouble actually making a concrete test illustrating the necessity there -- it seems when I call instead of in the above test case, even stable and beta complain about lifetime issues. Maybe the old dropck is catching something I'm missing in my manual analysis of , so I'm not going to lump that in until I see evidence that it is warranted.) Update: Oh, duh, has a lifetime bound (and a impl), so of course the old dropck was going to reject it.

<ins> // Copyright 2015 The Rust Project Developers. See the COPYRIGHT // file at the top-level directory of this distribution and at // http://rust-lang.org/COPYRIGHT. // // Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or // http://www.apache.org/licenses/LICENSE-2.0> or the MIT license // <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your // option. This file may not be copied, modified, or distributed // except according to those terms. // This test ensures that vec.into_iter does not overconstrain element lifetime. pub fn main() { original_report(); revision_1(); revision_2(); } fn original_report() { drop(vec![&()].into_iter()) } fn revision_1() { // below is what above `vec!` expands into at time of this writing. drop(<[_]>::into_vec(::std::boxed::Box::new([&()])).into_iter()) } fn revision_2() { drop((match (Vec::new(), &()) { (mut v, b) => { v.push(b); v } }).into_iter()) } </ins>


Question:
One minor doc bug: first example should call writetenbytesatend in test case instead of writetenbytes. PS: Is this a good place for website/doc issues?
Yep, this is the right place!

///     use std::io::Cursor; ///     let mut buff = Cursor::new(vec![0; 15]); /// <del> ///     write_ten_bytes(&mut buff).unwrap(); </del> <ins> ///     write_ten_bytes_at_end(&mut buff).unwrap(); </ins> /// ///     assert_eq!(&buff.get_ref()[5..15], &[0, 1, 2, 3, 4, 5, 6, 7, 8, 9]); /// }


Question:
Part of These have gotten some love lately, but should still be checked out.
I am happy with this now.

// option. This file may not be copied, modified, or distributed // except according to those terms. <del> //! A Unicode scalar value </del> <ins> //! Unicode scalar values </ins> //! //! This module provides the `CharExt` trait, as well as its //! implementation for the primitive `char` type, in order to allow


Question:
Part of These have gotten some love lately, but should still be checked out.
I am happy with this now.

/// character, as `char`s. /// /// All characters are escaped with Rust syntax of the form `u{NNNN}` <del> /// where `NNNN` is the shortest hexadecimal representation of the code /// point. </del> <ins> /// where `NNNN` is the shortest hexadecimal representation. </ins> /// /// # Examples /// <ins> /// Basic usage: /// </ins> /// ``` /// for c in '❤'.escape_unicode() { ///     print!("{}", c);


Question:
Part of These have gotten some love lately, but should still be checked out.
I am happy with this now.

/// /// # Examples /// <ins> /// Basic usage: /// </ins> /// ``` /// let n = 'ß'.len_utf16(); /// assert_eq!(n, 1);


Question:
Part of These have gotten some love lately, but should still be checked out.
I am happy with this now.

/// /// # Examples /// <ins> /// Basic usage: /// </ins> /// ``` /// #![feature(decode_utf16)] ///


Question:
Part of These have gotten some love lately, but should still be checked out.
I am happy with this now.

#[doc(primitive = "char")] // <del> /// A Unicode scalar value. </del> <ins> /// A character type. </ins> /// <del> /// A `char` represents a /// *[Unicode scalar /// value](http://www.unicode.org/glossary/#unicode_scalar_value)*, as it can /// contain any Unicode code point except high-surrogate and low-surrogate code /// points. </del> <ins> /// The `char` type represents a single character. More specifically, since /// 'character' isn't a well-defined concept in Unicode, `char` is a '[Unicode /// scalar value]', which is similar to, but not the same as, a '[Unicode code /// point]'. </ins> /// <del> /// As such, only values in the ranges [0x0,0xD7FF] and [0xE000,0x10FFFF] /// (inclusive) are allowed. A `char` can always be safely cast to a `u32`; /// however the converse is not always true due to the above range limits /// and, as such, should be performed via the `from_u32` function. </del> <ins> /// [Unicode scalar value]: http://www.unicode.org/glossary/#unicode_scalar_value /// [Unicode code point]: http://www.unicode.org/glossary/#code_point </ins> /// <del> /// *[See also the `std::char` module](char/index.html).* </del> <ins> /// This documentation describes a number of methods and trait implementations on the /// `char` type. For technical reasons, there is additional, separate /// documentation in [the `std::char` module](char/index.html) as well. </ins> /// <ins> /// # Representation /// /// `char` is always four bytes in size. This is a different representation than /// a given character would have as part of a [`String`], for example: /// /// ``` /// let v = vec!['h', 'e', 'l', 'l', 'o']; /// /// // five elements times four bytes for each element /// assert_eq!(20, v.len() * std::mem::size_of::<char>()); /// /// let s = String::from("hello"); /// /// // five elements times one byte per element /// assert_eq!(5, s.len() * std::mem::size_of::<u8>()); /// ``` /// /// [`String`]: string/struct.String.html /// /// As always, remember that a human intuition for 'character' may not map to /// Unicode's definitions. For example, emoji symbols such as '❤' are more than /// one byte; ❤ in particular is six: /// /// ``` /// let s = String::from("❤"); /// /// // six bytes times one byte for each element /// assert_eq!(6, s.len() * std::mem::size_of::<u8>()); /// ``` /// /// This also means it won't fit into a `char`, and so trying to create a /// literal with `let heart = '❤';` gives an error: /// /// ```text /// error: character literal may only contain one codepoint: '❤ /// let heart = '❤'; ///             ^~ /// ``` /// /// Another implication of this is that if you want to do per-`char`acter /// processing, it can end up using a lot more memory: /// /// ``` /// let s = String::from("love: ❤"); /// let v: Vec<char> = s.chars().collect(); /// /// assert_eq!(12, s.len() * std::mem::size_of::<u8>()); /// assert_eq!(32, v.len() * std::mem::size_of::<char>()); /// ``` /// /// Or may give you results you may not expect: /// /// ``` /// let s = String::from("❤"); /// /// let mut iter = s.chars(); /// /// // we get two chars out of a single ❤ /// assert_eq!(Some('u{2764}'), iter.next()); /// assert_eq!(Some('u{fe0f}'), iter.next()); /// assert_eq!(None, iter.next()); /// ``` </ins> mod prim_char { } #[doc(primitive = "unit")]


Question:
Part of Here's what needs to be done to close out this issue: is great, but has a lot of abbreviations, so the wording could be cleaned up a bit. should compare itself to , and should show a sample implementation. needs far better docs, as it is one of the most misunderstood traits in Rust. Specifically it should talk about its relationship with . It also needs an example implementation. needs a lot of work; it should talk about its usage in , it should show an example implementation, and general improvement. is mostly fine, but "generic impls" should say "implementations" and it should be above examples.
I am happy to mentor anyone who wants to tackle this issue.
I would be keen to give this one a go I'm interested in understanding this section better.
Awesome, ! Let me know if I can help you help me in any way
Hey , Just a couple of questions: the issue description for the trait you say to have the generic implementations above the examples, It turns out all of the traits have the examples above the generic implementations. Should I move the generic implementations above the examples for all of the traits? adding sample implementation do you like to make a generic example or use a common example from the std lib? I only ask because I have become familiar with through the usage within the package in creating paths and was thinking of using this as an example. What are your thoughts? relationship with is where I am having a bit of trouble explaining this concisely. Are we wanting to have a brief summarization of the section in the book and do we need to reciprocate or align with the documentation for the trait? I only ask as I feel to explain the difference I am describing the trait a bit and do not want to introduce a second differing description. Thanks :smile:
Hey ! Yes, that'd be great! Ideally, we'd have both: one extremely simple example for people to be able to copy/paste, and one more realistic example. Feel free to submit one or both yes it's tough! The second edition of the book does not have that chapter; synchronizing these API docs is the right way to go
OK great :smile: I will hopefully have something in today to start picking apart. :+1:
Hey , I had a look at the [RFC] mentioned in the contribution guide and couldn't find anything on the guidelines for line length. I only ask as one of the Travis builds failed due to the line exceeding 100 chars, so was wondering what I should be aiming for. Thanks again! :smile: [RFC]:
Standard library docs are wrapped to 80 characters. :)
This is now done!

//! Like many traits, these are often used as bounds for generic functions, to //! support arguments of multiple types. //! <ins> //! - Impl the `As*` traits for reference-to-reference conversions //! - Impl the `Into` trait when you want to consume the value in the conversion //! - The `From` trait is the most flexible, usefull for values _and_ references conversions //! //! As a library writer, you should prefer implementing `From<T>` rather than //! `Into<U>`, as `From` provides greater flexibility and offer the equivalent `Into` //! implementation for free, thanks to a blanket implementation in the standard library. //! //! **Note: these traits must not fail**. If the conversion can fail, you must use a dedicated //! method which return an `Option<T>` or a `Result<T, E>`. //! //! # Generic impl //! //! - `AsRef` and `AsMut` auto-dereference if the inner type is a reference //! - `From<U> for T` implies `Into<T> for U` //! - `From` and `Into` are reflexive, which means that all types can `into()` //!   themselves and `from()` themselves //! </ins> //! See each trait for usage examples. #![stable(feature = "rust1", since = "1.0.0")]


Question:
Part of Here's what needs to be done to close out this issue: is great, but has a lot of abbreviations, so the wording could be cleaned up a bit. should compare itself to , and should show a sample implementation. needs far better docs, as it is one of the most misunderstood traits in Rust. Specifically it should talk about its relationship with . It also needs an example implementation. needs a lot of work; it should talk about its usage in , it should show an example implementation, and general improvement. is mostly fine, but "generic impls" should say "implementations" and it should be above examples.
I am happy to mentor anyone who wants to tackle this issue.
I would be keen to give this one a go I'm interested in understanding this section better.
Awesome, ! Let me know if I can help you help me in any way
Hey , Just a couple of questions: the issue description for the trait you say to have the generic implementations above the examples, It turns out all of the traits have the examples above the generic implementations. Should I move the generic implementations above the examples for all of the traits? adding sample implementation do you like to make a generic example or use a common example from the std lib? I only ask because I have become familiar with through the usage within the package in creating paths and was thinking of using this as an example. What are your thoughts? relationship with is where I am having a bit of trouble explaining this concisely. Are we wanting to have a brief summarization of the section in the book and do we need to reciprocate or align with the documentation for the trait? I only ask as I feel to explain the difference I am describing the trait a bit and do not want to introduce a second differing description. Thanks :smile:
Hey ! Yes, that'd be great! Ideally, we'd have both: one extremely simple example for people to be able to copy/paste, and one more realistic example. Feel free to submit one or both yes it's tough! The second edition of the book does not have that chapter; synchronizing these API docs is the right way to go
OK great :smile: I will hopefully have something in today to start picking apart. :+1:
Hey , I had a look at the [RFC] mentioned in the contribution guide and couldn't find anything on the guidelines for line length. I only ask as one of the Travis builds failed due to the line exceeding 100 chars, so was wondering what I should be aiming for. Thanks again! :smile: [RFC]:
Standard library docs are wrapped to 80 characters. :)
This is now done!

/// /// [book]: ../../book/borrow-and-asref.html /// <ins> /// **Note: this trait must not fail**. If the conversion can fail, use a dedicated method which /// return an `Option<T>` or a `Result<T, E>`. /// </ins> /// # Examples /// /// Both `String` and `&str` implement `AsRef<str>`:


Question:
Part of Here's what needs to be done to close out this issue: is great, but has a lot of abbreviations, so the wording could be cleaned up a bit. should compare itself to , and should show a sample implementation. needs far better docs, as it is one of the most misunderstood traits in Rust. Specifically it should talk about its relationship with . It also needs an example implementation. needs a lot of work; it should talk about its usage in , it should show an example implementation, and general improvement. is mostly fine, but "generic impls" should say "implementations" and it should be above examples.
I am happy to mentor anyone who wants to tackle this issue.
I would be keen to give this one a go I'm interested in understanding this section better.
Awesome, ! Let me know if I can help you help me in any way
Hey , Just a couple of questions: the issue description for the trait you say to have the generic implementations above the examples, It turns out all of the traits have the examples above the generic implementations. Should I move the generic implementations above the examples for all of the traits? adding sample implementation do you like to make a generic example or use a common example from the std lib? I only ask because I have become familiar with through the usage within the package in creating paths and was thinking of using this as an example. What are your thoughts? relationship with is where I am having a bit of trouble explaining this concisely. Are we wanting to have a brief summarization of the section in the book and do we need to reciprocate or align with the documentation for the trait? I only ask as I feel to explain the difference I am describing the trait a bit and do not want to introduce a second differing description. Thanks :smile:
Hey ! Yes, that'd be great! Ideally, we'd have both: one extremely simple example for people to be able to copy/paste, and one more realistic example. Feel free to submit one or both yes it's tough! The second edition of the book does not have that chapter; synchronizing these API docs is the right way to go
OK great :smile: I will hopefully have something in today to start picking apart. :+1:
Hey , I had a look at the [RFC] mentioned in the contribution guide and couldn't find anything on the guidelines for line length. I only ask as one of the Travis builds failed due to the line exceeding 100 chars, so was wondering what I should be aiming for. Thanks again! :smile: [RFC]:
Standard library docs are wrapped to 80 characters. :)
This is now done!

/// let s = "hello".to_string(); /// is_hello(s); /// ``` <ins> /// /// # Generic Impls /// /// - `AsRef` auto-dereference if the inner type is a reference or a mutable /// reference (eg: `foo.as_ref()` will work the same if `foo` has type `&mut Foo` or `&&mut Foo`) /// </ins> #[stable(feature = "rust1", since = "1.0.0")] pub trait AsRef<T: ?Sized> { /// Performs the conversion.


Question:
Part of Here's what needs to be done to close out this issue: is great, but has a lot of abbreviations, so the wording could be cleaned up a bit. should compare itself to , and should show a sample implementation. needs far better docs, as it is one of the most misunderstood traits in Rust. Specifically it should talk about its relationship with . It also needs an example implementation. needs a lot of work; it should talk about its usage in , it should show an example implementation, and general improvement. is mostly fine, but "generic impls" should say "implementations" and it should be above examples.
I am happy to mentor anyone who wants to tackle this issue.
I would be keen to give this one a go I'm interested in understanding this section better.
Awesome, ! Let me know if I can help you help me in any way
Hey , Just a couple of questions: the issue description for the trait you say to have the generic implementations above the examples, It turns out all of the traits have the examples above the generic implementations. Should I move the generic implementations above the examples for all of the traits? adding sample implementation do you like to make a generic example or use a common example from the std lib? I only ask because I have become familiar with through the usage within the package in creating paths and was thinking of using this as an example. What are your thoughts? relationship with is where I am having a bit of trouble explaining this concisely. Are we wanting to have a brief summarization of the section in the book and do we need to reciprocate or align with the documentation for the trait? I only ask as I feel to explain the difference I am describing the trait a bit and do not want to introduce a second differing description. Thanks :smile:
Hey ! Yes, that'd be great! Ideally, we'd have both: one extremely simple example for people to be able to copy/paste, and one more realistic example. Feel free to submit one or both yes it's tough! The second edition of the book does not have that chapter; synchronizing these API docs is the right way to go
OK great :smile: I will hopefully have something in today to start picking apart. :+1:
Hey , I had a look at the [RFC] mentioned in the contribution guide and couldn't find anything on the guidelines for line length. I only ask as one of the Travis builds failed due to the line exceeding 100 chars, so was wondering what I should be aiming for. Thanks again! :smile: [RFC]:
Standard library docs are wrapped to 80 characters. :)
This is now done!

} /// A cheap, mutable reference-to-mutable reference conversion. <ins> /// /// **Note: this trait must not fail**. If the conversion can fail, use a dedicated method which /// return an `Option<T>` or a `Result<T, E>`. /// /// # Generic Impls /// /// - `AsMut` auto-dereference if the inner type is a reference or a mutable /// reference (eg: `foo.as_ref()` will work the same if `foo` has type `&mut Foo` or `&&mut Foo`) /// </ins> #[stable(feature = "rust1", since = "1.0.0")] pub trait AsMut<T: ?Sized> { /// Performs the conversion.


Question:
Part of Here's what needs to be done to close out this issue: is great, but has a lot of abbreviations, so the wording could be cleaned up a bit. should compare itself to , and should show a sample implementation. needs far better docs, as it is one of the most misunderstood traits in Rust. Specifically it should talk about its relationship with . It also needs an example implementation. needs a lot of work; it should talk about its usage in , it should show an example implementation, and general improvement. is mostly fine, but "generic impls" should say "implementations" and it should be above examples.
I am happy to mentor anyone who wants to tackle this issue.
I would be keen to give this one a go I'm interested in understanding this section better.
Awesome, ! Let me know if I can help you help me in any way
Hey , Just a couple of questions: the issue description for the trait you say to have the generic implementations above the examples, It turns out all of the traits have the examples above the generic implementations. Should I move the generic implementations above the examples for all of the traits? adding sample implementation do you like to make a generic example or use a common example from the std lib? I only ask because I have become familiar with through the usage within the package in creating paths and was thinking of using this as an example. What are your thoughts? relationship with is where I am having a bit of trouble explaining this concisely. Are we wanting to have a brief summarization of the section in the book and do we need to reciprocate or align with the documentation for the trait? I only ask as I feel to explain the difference I am describing the trait a bit and do not want to introduce a second differing description. Thanks :smile:
Hey ! Yes, that'd be great! Ideally, we'd have both: one extremely simple example for people to be able to copy/paste, and one more realistic example. Feel free to submit one or both yes it's tough! The second edition of the book does not have that chapter; synchronizing these API docs is the right way to go
OK great :smile: I will hopefully have something in today to start picking apart. :+1:
Hey , I had a look at the [RFC] mentioned in the contribution guide and couldn't find anything on the guidelines for line length. I only ask as one of the Travis builds failed due to the line exceeding 100 chars, so was wondering what I should be aiming for. Thanks again! :smile: [RFC]:
Standard library docs are wrapped to 80 characters. :)
This is now done!

/// A conversion that consumes `self`, which may or may not be expensive. /// <ins> /// **Note: this trait must not fail**. If the conversion can fail, use a dedicated method which /// return an `Option<T>` or a `Result<T, E>`. /// /// Library writer should not implement directly this trait, but should prefer the implementation /// of the `From` trait, which offer greater flexibility and provide the equivalent `Into` /// implementation for free, thanks to a blanket implementation in the standard library. /// </ins> /// # Examples /// /// `String` implements `Into<Vec<u8>>`:


Question:
Part of Here's what needs to be done to close out this issue: is great, but has a lot of abbreviations, so the wording could be cleaned up a bit. should compare itself to , and should show a sample implementation. needs far better docs, as it is one of the most misunderstood traits in Rust. Specifically it should talk about its relationship with . It also needs an example implementation. needs a lot of work; it should talk about its usage in , it should show an example implementation, and general improvement. is mostly fine, but "generic impls" should say "implementations" and it should be above examples.
I am happy to mentor anyone who wants to tackle this issue.
I would be keen to give this one a go I'm interested in understanding this section better.
Awesome, ! Let me know if I can help you help me in any way
Hey , Just a couple of questions: the issue description for the trait you say to have the generic implementations above the examples, It turns out all of the traits have the examples above the generic implementations. Should I move the generic implementations above the examples for all of the traits? adding sample implementation do you like to make a generic example or use a common example from the std lib? I only ask because I have become familiar with through the usage within the package in creating paths and was thinking of using this as an example. What are your thoughts? relationship with is where I am having a bit of trouble explaining this concisely. Are we wanting to have a brief summarization of the section in the book and do we need to reciprocate or align with the documentation for the trait? I only ask as I feel to explain the difference I am describing the trait a bit and do not want to introduce a second differing description. Thanks :smile:
Hey ! Yes, that'd be great! Ideally, we'd have both: one extremely simple example for people to be able to copy/paste, and one more realistic example. Feel free to submit one or both yes it's tough! The second edition of the book does not have that chapter; synchronizing these API docs is the right way to go
OK great :smile: I will hopefully have something in today to start picking apart. :+1:
Hey , I had a look at the [RFC] mentioned in the contribution guide and couldn't find anything on the guidelines for line length. I only ask as one of the Travis builds failed due to the line exceeding 100 chars, so was wondering what I should be aiming for. Thanks again! :smile: [RFC]:
Standard library docs are wrapped to 80 characters. :)
This is now done!

/// let s = "hello".to_string(); /// is_hello(s); /// ``` <ins> /// /// # Generic Impls /// /// - `From<T> for U` implies `Into<U> for T` /// - `into()` is reflexive, which means that `Into<T> for T` is implemented /// </ins> #[stable(feature = "rust1", since = "1.0.0")] pub trait Into<T>: Sized { /// Performs the conversion.


Question:
Part of Here's what needs to be done to close out this issue: is great, but has a lot of abbreviations, so the wording could be cleaned up a bit. should compare itself to , and should show a sample implementation. needs far better docs, as it is one of the most misunderstood traits in Rust. Specifically it should talk about its relationship with . It also needs an example implementation. needs a lot of work; it should talk about its usage in , it should show an example implementation, and general improvement. is mostly fine, but "generic impls" should say "implementations" and it should be above examples.
I am happy to mentor anyone who wants to tackle this issue.
I would be keen to give this one a go I'm interested in understanding this section better.
Awesome, ! Let me know if I can help you help me in any way
Hey , Just a couple of questions: the issue description for the trait you say to have the generic implementations above the examples, It turns out all of the traits have the examples above the generic implementations. Should I move the generic implementations above the examples for all of the traits? adding sample implementation do you like to make a generic example or use a common example from the std lib? I only ask because I have become familiar with through the usage within the package in creating paths and was thinking of using this as an example. What are your thoughts? relationship with is where I am having a bit of trouble explaining this concisely. Are we wanting to have a brief summarization of the section in the book and do we need to reciprocate or align with the documentation for the trait? I only ask as I feel to explain the difference I am describing the trait a bit and do not want to introduce a second differing description. Thanks :smile:
Hey ! Yes, that'd be great! Ideally, we'd have both: one extremely simple example for people to be able to copy/paste, and one more realistic example. Feel free to submit one or both yes it's tough! The second edition of the book does not have that chapter; synchronizing these API docs is the right way to go
OK great :smile: I will hopefully have something in today to start picking apart. :+1:
Hey , I had a look at the [RFC] mentioned in the contribution guide and couldn't find anything on the guidelines for line length. I only ask as one of the Travis builds failed due to the line exceeding 100 chars, so was wondering what I should be aiming for. Thanks again! :smile: [RFC]:
Standard library docs are wrapped to 80 characters. :)
This is now done!

/// Construct `Self` via a conversion. /// <ins> /// **Note: this trait must not fail**. If the conversion can fail, use a dedicated method which /// return an `Option<T>` or a `Result<T, E>`. /// </ins> /// # Examples /// /// `String` implements `From<&str>`:


Question:
Part of Here's what needs to be done to close out this issue: is great, but has a lot of abbreviations, so the wording could be cleaned up a bit. should compare itself to , and should show a sample implementation. needs far better docs, as it is one of the most misunderstood traits in Rust. Specifically it should talk about its relationship with . It also needs an example implementation. needs a lot of work; it should talk about its usage in , it should show an example implementation, and general improvement. is mostly fine, but "generic impls" should say "implementations" and it should be above examples.
I am happy to mentor anyone who wants to tackle this issue.
I would be keen to give this one a go I'm interested in understanding this section better.
Awesome, ! Let me know if I can help you help me in any way
Hey , Just a couple of questions: the issue description for the trait you say to have the generic implementations above the examples, It turns out all of the traits have the examples above the generic implementations. Should I move the generic implementations above the examples for all of the traits? adding sample implementation do you like to make a generic example or use a common example from the std lib? I only ask because I have become familiar with through the usage within the package in creating paths and was thinking of using this as an example. What are your thoughts? relationship with is where I am having a bit of trouble explaining this concisely. Are we wanting to have a brief summarization of the section in the book and do we need to reciprocate or align with the documentation for the trait? I only ask as I feel to explain the difference I am describing the trait a bit and do not want to introduce a second differing description. Thanks :smile:
Hey ! Yes, that'd be great! Ideally, we'd have both: one extremely simple example for people to be able to copy/paste, and one more realistic example. Feel free to submit one or both yes it's tough! The second edition of the book does not have that chapter; synchronizing these API docs is the right way to go
OK great :smile: I will hopefully have something in today to start picking apart. :+1:
Hey , I had a look at the [RFC] mentioned in the contribution guide and couldn't find anything on the guidelines for line length. I only ask as one of the Travis builds failed due to the line exceeding 100 chars, so was wondering what I should be aiming for. Thanks again! :smile: [RFC]:
Standard library docs are wrapped to 80 characters. :)
This is now done!

/// /// assert_eq!(string, other_string); /// ``` <ins> /// # Generic impls /// /// - `From<T> for U` implies `Into<U> for T` /// - `from()` is reflexive, which means that `From<T> for T` is implemented /// </ins> #[stable(feature = "rust1", since = "1.0.0")] pub trait From<T>: Sized { /// Performs the conversion.


Question: We need to support references to static items in lvalues. This would be used for accessing a static lock or assigning to a static mut.

} } <ins> pub fn get_static_val<'a, 'tcx>(ccx: &CrateContext<'a, 'tcx>, did: DefId, ty: Ty<'tcx>) -> ValueRef { if let Some(node_id) = ccx.tcx().map.as_local_node_id(did) { base::get_item_val(ccx, node_id) } else { base::get_extern_const(ccx, did, ty) } } </ins>


Question: We need to support references to static items in lvalues. This would be used for accessing a static lock or assigning to a static mut.

use middle::def_id::DefId; use trans::{adt, closure, debuginfo, expr, inline, machine}; use trans::base::{self, push_ctxt}; <ins> use trans::common::{self, type_is_sized, ExprOrMethodCall, node_id_substs, C_nil, const_get_elt}; </ins> use trans::common::{CrateContext, C_integral, C_floating, C_bool, C_str_slice, C_bytes, val_ty}; <del> use trans::common::{type_is_sized, ExprOrMethodCall, node_id_substs, C_nil, const_get_elt}; </del> use trans::common::{C_struct, C_undef, const_to_opt_int, const_to_opt_uint, VariantInfo, C_uint}; use trans::common::{type_is_fat_ptr, Field, C_vector, C_array, C_null, ExprId, MethodCallKey}; use trans::declare;


Question: We need to support references to static items in lvalues. This would be used for accessing a static lock or assigning to a static mut.

} let opt_def = cx.tcx().def_map.borrow().get(&cur.id).map(|d| d.full_def()); if let Some(def::DefStatic(def_id, _)) = opt_def { <del> get_static_val(cx, def_id, ety) </del> <ins> common::get_static_val(cx, def_id, ety) </ins> } else { // If this isn't the address of a static, then keep going through // normal constant evaluation.


Question: We need to support references to static items in lvalues. This would be used for accessing a static lock or assigning to a static mut.

Ok(g) } } <del> fn get_static_val<'a, 'tcx>(ccx: &CrateContext<'a, 'tcx>, did: DefId, ty: Ty<'tcx>) -> ValueRef { if let Some(node_id) = ccx.tcx().map.as_local_node_id(did) { base::get_item_val(ccx, node_id) } else { base::trans_external_path(ccx, did, ty) } } </del>


Question: We need to support references to static items in lvalues. This would be used for accessing a static lock or assigning to a static mut.

DatumBlock::new(bcx, datum.to_expr_datum()) } def::DefStatic(did, _) => { <del> // There are two things that may happen here: //  1) If the static item is defined in this crate, it will be //     translated using `get_item_val`, and we return a pointer to //     the result. //  2) If the static item is defined in another crate then we add //     (or reuse) a declaration of an external global, and return a //     pointer to that. </del> let const_ty = expr_ty(bcx, ref_expr); <del> // For external constants, we don't inline. let val = if let Some(node_id) = bcx.tcx().map.as_local_node_id(did) { // Case 1. // The LLVM global has the type of its initializer, // which may not be equal to the enum's type for // non-C-like enums. let val = base::get_item_val(bcx.ccx(), node_id); let pty = type_of::type_of(bcx.ccx(), const_ty).ptr_to(); PointerCast(bcx, val, pty) } else { // Case 2. base::get_extern_const(bcx.ccx(), did, const_ty) }; </del> <ins> let val = get_static_val(bcx.ccx(), did, const_ty); </ins> let lval = Lvalue::new("expr::trans_def"); DatumBlock::new(bcx, Datum::new(val, const_ty, LvalueExpr(lval))) }


Question: We need to support references to static items in lvalues. This would be used for accessing a static lock or assigning to a static mut.

tcx.sess.bug(&format!("using operand temp {:?} as lvalue", lvalue)), }, mir::Lvalue::Arg(index) => self.args[index as usize], <del> mir::Lvalue::Static(_def_id) => unimplemented!(), </del> <ins> mir::Lvalue::Static(def_id) => { let const_ty = self.mir.lvalue_ty(tcx, lvalue); LvalueRef::new(common::get_static_val(ccx, def_id, const_ty.to_ty(tcx)), const_ty) }, </ins> mir::Lvalue::ReturnPointer => { let return_ty = bcx.monomorphize(&self.mir.return_ty); let llval = fcx.get_ret_slot(bcx, return_ty, "return");