[swift-evolution] [Pitch/plea] Recursive protocol constraints

Mon Jan 2 13:46:17 CST 2017

Thank you for the kind comments and the review, Dave! I will be working to
address the points you brought up throughout the week. This will include
re-auditing the stdlib types based on both manual investigation and Doug's
branch.

Anyone who wants to help, by the way, is more than welcome to; I'm happy to
take PRs or just even a message describing what needs to change, and I'd of
course add you to the authors list...

Regarding "valid" recursive constraints breaking the compiler: it was a
reference to something Doug said in his original email:

> I also have a nagging feeling that we will need some form of restrictions
on this feature for implementation reasons, e.g., because some recursive
constraints will form unsolvable systems.

Best,
Austin

On Sat, Dec 31, 2016 at 11:29 AM, Dave Abrahams via swift-evolution <
swift-evolution at swift.org> wrote:

>
> on Sat Dec 31 2016, Dave Abrahams <swift-evolution at swift.org> wrote:
>
> > on Fri Dec 30 2016, Austin Zheng <swift-evolution at swift.org> wrote:
> >
> >> After overpromising and underdelivering, I finally managed to sit down
> >> and draft a proposal. Sorry it took so long.
> >
> > All your help is deeply appreciated, Austin!
> >
> >> You can find it here:
> >>
> >>
> > https://github.com/austinzheng/swift-evolution/
> blob/recursive-constraints/proposals/XXXX-recursive-
> protocol-constraints.md
> >>
> > <https://github.com/austinzheng/swift-evolution/
> blob/recursive-constraints/proposals/XXXX-recursive-
> protocol-constraints.md>
> >>
> >> It contains both a description of the change itself, as well as a list
> >> of stdlib changes that need to be made. I used the “FIXME(ABI)”
> >> comments in the codebase to compile that list of changes. I also went
> >> over parts of the stdlib myself to see if there was anything else I
> >> could find, but didn’t notice anything in particular. (I was hoping
> >> protocols like `_Integer` could go away, but I’m not sure the issue
> >> they’re working around is related to recursive constraints.)
> >
> > It is.
> >
> >> One thing that needs to be done before this can enter formal review is
> >> thinking through cases where “valid” recursive constraints might break
> >> the compiler.
> >
> > I haven't read it yet; does the document explain what you mean by that?
> > Because it's not obvious from this message
>
> ...or from the document.
>
> I left some commentary in
> https://github.com/austinzheng/swift-evolution/commit/
> ad1d28b3b74bb12cfd07c277322ea4eb2b78b8cd#diff-
> 6b60459047bfe1c675c50d5ca66cfe91R57
>
> in addition, I notice that many of the likely stdlib changes are
> missing... but it may be more efficient for you to watch the branch
> Doug's working on and see what changes are made there, and then propose
> those, than to try to anticipate what will change.
>
> >> Help on that (or any other feedback, really) would be greatly
> >> appreciated.
> >>
> >> Best,
> >> Austin
> >>
> >>> On Nov 21, 2016, at 6:42 PM, Austin Zheng <austinzheng at gmail.com>
> >> wrote:
> >>>
> >>> Never mind, I just saw SE-0142. I need to go back and read all the
> proposals again!
> >>>
> >>> On Mon, Nov 21, 2016 at 6:32 PM, Austin Zheng
> >>> <austinzheng at gmail.com
> >>> <mailto:austinzheng at gmail.com>> wrote:
> >>> I'm still working on this. When you mention where clauses on
> >>> associated types, how should I handle that in the context of the
> >>> proposal?
> >>>
> >>> * Consider where clauses part of the proposal (so that the proposal
> >>> becomes "recursive associated type constraints + where clauses on
> >>> associated types")
> >>> * Assume that where clauses will definitely be accepted, and write the
> stdlib changes assuming that
> >>> * Assume that where clauses might not be accepted, and write the
> >>> stdlib changes assuming that, but also have a section containing
> >>> further stdlib changes conditional on where clauses being accepted
> >>>
> >>> Best,
> >>> Austin
> >>>
> >>> On Sun, Nov 13, 2016 at 7:55 PM, Douglas Gregor
> >>> <dgregor at apple.com
> >>> <mailto:dgregor at apple.com>> wrote:
> >>>
> >>>
> >>>
> >>>
> >>> On Nov 13, 2016, at 4:03 PM, Austin Zheng
> >>> <austinzheng at gmail.com
> >>> <mailto:austinzheng at gmail.com>> wrote:
> >>>
> >>>> I'd be happy to put something together, unless someone else wants to
> take it on.
> >>>
> >>> Great, thanks!
> >>>
> >>>>
> >>>> Doug, I also owe you a PR adding a minor amendment to one of the
> >>>> accepted proposals. I'll get to that this week.
> >>>
> >>> Sounds great.
> >>>
> >>>   - Doug
> >>>
> >>>> Austin
> >>>>
> >>>> On Sun, Nov 13, 2016 at 10:13 PM, Douglas Gregor via swift-evolution <
> swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
> >>>> Recursive protocol constraints is one small-looking feature that
> could greatly improve the standard library. The generics manifesto
> describes it this way:
> >>>>
> >>>> "Currently, an associated type cannot be required to conform to its
> enclosing protocol (or any protocol that inherits that protocol). For
> example, in the standard library SubSequence type of a Sequence should
> itself be a Sequence:
> >>>>
> >>>> protocol Sequence { associatedtype Iterator : IteratorProtocol ...
> associatedtype SubSequence : Sequence // currently ill-formed, but should
> be possible }
> >>>> The compiler currently rejects this protocol, which is unfortunate:
> it effectively pushes the SubSequence-must-be-a-Sequence requirement into
> every consumer of SubSequence, and does not communicate the intent of this
> abstraction well."
> >>>>
> >>>>  <https://github.com/apple/swift/blob/master/docs/
> GenericsManifesto.md#nested-generics>It's actually slightly worse than
> the above implies: the standard library has a pile of underscore-prefixed
> protocols (e.g., _Sequence) specifically to dodge this restriction. They
> are ugly, and we want them to go away. Many of these places are marked with
> an ABI FIXME in the standard library sources.
> >>>>
> >>>> Would someone like to write up a proposal for this feature? The
> syntax and basic semantics are pretty direct, but a proposal should also
> capture the expected effects on the standard library, particularly when
> combined with where clauses on associated types.
> >>>>
> >>>> I also have a nagging feeling that we will need some form of
> restrictions on this feature for implementation reasons, e.g., because some
> recursive constraints will form unsolvable systems.
> >>>>
> >>>> For reference, we've already been implementing this feature. Some
> information about the compiler internal issues is captured at:
> >>>>
> >>>>   https://gist.github.com/DougGregor/e7c4e7bb4465d6f5fa2b59be72dbdba6
> <https://gist.github.com/DougGregor/e7c4e7bb4465d6f5fa2b59be72dbdba6>
> >>>>
> >>>>   - Doug
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>> _______________________________________________
> >>>> swift-evolution mailing list
> >>>> swift-evolution at swift.org
> >> <mailto:swift-evolution at swift.org>
> >>>> https://lists.swift.org/mailman/listinfo/swift-evolution
> >> <https://lists.swift.org/mailman/listinfo/swift-evolution>
> >>>>
> >>>>
> >>>
> >>>
> >>
> >> _______________________________________________
> >> swift-evolution mailing list
> >> swift-evolution at swift.org
> >> https://lists.swift.org/mailman/listinfo/swift-evolution
> >>
>
> --
> -Dave
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170102/9f1eda6c/attachment.html>