4 ms·

I really, really hope that abstract return types make it in or are not considered a breaking change for a future release: https://stackoverflow.com/questions/2

• arthursilva 12y ago
  Since it's not a breaking change it's not coming in 1.0, probably shortly after it though.
  • kzrdude 12y ago
    it looks like a breaking change, say if you change the return type of `fn iter()` on a slice.
    • arthursilva 12y ago
      It seems to me it's inference so the type will stay the same, just inferred.
      • kibwen 12y ago
        It actually does have the potential to break things, because to do this today requires you to explicitly list out all the types of the return type (which should really be considered implementation details). If a user of your function accidentally relies on one of these details, their code would be broken once you switch from the fully-specified return type to an anonymized return type.
        • arthursilva 12y ago
          Well, if you take advantage of it may break stuff. Although this doesn't really qualify as a breaking change since older code is going to compile when it's introduced.
          • kzrdude 12y ago
            Older code that uses specific features of that iterator will break. The slice iterator has its own methods (turn it into a slice), it's clonable and it is Copy.
            • Gankro 12y ago
              It's only a breaking change to one's API to actually use the functionality, though. I don't think there's anywhere in std's public APIs where we would suddenly change from returning a concrete iterator to an "abstract" one.
• kibwen 12y ago
  Anonymized return types will sadly not be a blocker for 1.0, though they will be an enormously high priority post-1.0. In particular, the biggest pain point for the lack of anonymized return types won't be the use case mentioned in that SO thread (which is heinously ugly and leaks implementation details, but at least it's possible), but will rather be the fact that without anonymized return types it will be impossible for a function to construct a closure and then return that closure without stuffing it into a box (though note that it will still be possible for functions to return unboxed closures if it accepted that closure as a parameter to the function).
  • scanr 12y ago
    Great to hear that folk are aware of this and that it's not considered a breaking change for a future release. Where is the best place to get updates on these kinds of features? I was following the github ticket until it closed and it wasn't clear where to go afterwards.
    • steveklabnik 12y ago
      Language changes are proposed through our RFC process, which is at this repository: https://github.com/rust-lang/rfcs https://github.com/rust-lang/rfcs Open issues start a discussion, and then morph to a more formal proposal.
      • scanr 12y ago
        Thanks, Steve. I was following the previous RFC but it got closed. Do you know if there is a new one for abstract / anonymous return types? This was the previous one for abstract return types: https://github.com/rust-lang/rfcs/pull/105 https://github.com/rust-lang/rfcs/pull/105
        • steveklabnik 12y ago
          It appears that (at least with my searching) we don't have an issue on the RFC repo, so I opened one. https://github.com/rust-lang/rfcs/issues/518 https://github.com/rust-lang/rfcs/issues/518
• aalvarado 12y ago
  Yup, seeing method signatures like these is discouraging: ``` core::iter::Zip<core::iter::FilterMap<'_, (&std::collections::hash::set::HashSet<attr::Attribute>, &attr::Attribute), &attr::Attribute, core::iter::Zip<core::iter::Repeat<&std::collections::hash::set::HashSet<attr::Attribute>>, core::iter::Map<'_, (&attr::Attribute, &()), &attr::Attribute, std::collections::hash::map::Entries<'_, attr::Attribute, ()>>>>, core::iter::FilterMap<'_, (&std::collections::hash::set::HashSet<attr::Attribute>, &attr::Attribute), &attr::Attribute, core::iter::Zip<core::iter::Repeat<&std::collections::hash::set::HashSet<attr::Attribute>>, core::iter::Map<'_, (&attr::Attribute, &()), &attr::Attribute, std::collections::hash::map::Entries<'_, attr::Attribute, ()>>>>> ``
  • kibwen 12y ago
    Ha, we hate them too, which is why we're so eager to finalize their design so that we can replace all of that hideous garbage with just `impl Iterator`. :) And who knows, it might happen for 1.0 if enough people push on the design and are willing to put in the legwork of implementing it.
    • aalvarado 12y ago
      thanks for your hard work. Sometimes we take simplicity for granted!
  • jimbokun 12y ago
    What is that, if I may ask?
    • mitchmindtree 12y ago
      That particular type is an Iterator over two HashSet intersections zipped together. I'm looking forward to getting rid of it!
  • bjz_ 12y ago
    This is a huge ergonomic issue that the team is very aware of. There are plans to fix it post 1.0.