[swift-evolution] [META] Gmane and Swift Evolution

[Saagar Jha]

I’ve submitted a pull that includes everything except for SE-0094, 0095, and 0110, which I wasn’t able to find.

Saagar Jha



> On Aug 3, 2016, at 11:31, Erica Sadun via swift-evolution <swift-evolution at swift.org> wrote:
> 
> 
>> On Aug 2, 2016, at 9:22 AM, Ben Rimmington <me at benrimmington.com> wrote:
>> 
>> 
>>> On 2 Aug 2016, at 16:16, Erica Sadun via swift-evolution <swift-evolution at swift.org> wrote:
>>> 
>>> Anyone willing to adopt a proposal or a group and get them updated, please reply in-thread and submit a PR with changes.
>> 
>> [SE-0076 ... SE-0090] <https://github.com/apple/swift-evolution/pull/484>
>> 
>> -- Ben
>> 
> 
> Here's what's left
> 
> proposals/0092-typealiases-in-protocols.md:* Status: **Implemented in Swift 3.0** ([Rationale](http://thread.gmane.org/gmane.comp.lang.swift.evolution/17317))
> proposals/0094-sequence-function.md:Swift-evolution thread: [Discussion thread topic for that proposal](http://thread.gmane.org/gmane.comp.lang.swift.evolution/15743/focus=17108)
> proposals/0094-sequence-function.md:[SE-0045a]: http://article.gmane.org/gmane.comp.lang.swift.evolution/16119
> proposals/0095-any-as-existential.md:Discussion threads: [pre-proposal](https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160516/018109.html), [review thread 1](http://thread.gmane.org/gmane.comp.lang.swift.evolution/18349), [2](http://thread.gmane.org/gmane.comp.lang.swift.evolution/18350/focus=18447), [3](http://thread.gmane.org/gmane.comp.lang.swift.evolution/18351/focus=18440), [4](http://thread.gmane.org/gmane.comp.lang.swift.evolution/18518), [post-review thread](http://thread.gmane.org/gmane.comp.lang.swift.evolution/19463)
> proposals/0096-dynamictype.md:[RFC: didset and willset](http://thread.gmane.org/gmane.comp.lang.swift.evolution/17534)
> proposals/0097-negative-attributes.md:[RFC: didset and willset](http://thread.gmane.org/gmane.comp.lang.swift.evolution/17534)
> proposals/0098-didset-capitalization.md:[RFC: didset and willset](http://thread.gmane.org/gmane.comp.lang.swift.evolution/17534)
> proposals/0099-conditionclauses.md:[\[Pitch\] making where and ,	interchangeable in guard conditions](http://thread.gmane.org/gmane.comp.lang.swift.evolution/17926)
> proposals/0101-standardizing-sizeof-naming.md:* Swift Evolution Pitch: [\[Pitch\] Renaming sizeof, sizeofValue, strideof,	strideofValue](http://thread.gmane.org/gmane.comp.lang.swift.evolution/19459)
> proposals/0101-standardizing-sizeof-naming.md:* [Earlier Discussions](http://thread.gmane.org/gmane.comp.lang.swift.evolution/15830)
> proposals/0101-standardizing-sizeof-naming.md:* [SE-0101 Review](http://thread.gmane.org/gmane.comp.lang.swift.evolution/21103)
> proposals/0103-make-noescape-default.md:* [Make non-escaping closures the default](http://thread.gmane.org/gmane.comp.lang.swift.evolution/19756)
> proposals/0105-remove-where-from-forin-loops.md:Swift Evolution Discussion: [\[Pitch\] Retiring `where` from for-in loops](http://thread.gmane.org/gmane.comp.lang.swift.evolution/20142)
> proposals/0106-rename-osx-to-macos.md:Swift Evolution Discussion: [\[DRAFT\] Aliasing the OS X Platform Configuration	Test](http://thread.gmane.org/gmane.comp.lang.swift.evolution/20815)
> proposals/0108-remove-assoctype-inference.md:swift-evolution thread: [pre-proposal](http://thread.gmane.org/gmane.comp.lang.swift.evolution/21714)
> proposals/0108-remove-assoctype-inference.md:As Douglas Gregor (original author of the relevant type inference code) [puts it](http://article.gmane.org/gmane.comp.lang.swift.evolution/22058):
> proposals/0108-remove-assoctype-inference.md:To some extent, this is an issue inherent to any design which makes no distinctions at the site of implementation between members intended to satisfy protocol requirements and members that are explicitly not intended to satisfy protocol requirements. Rather than adding keywords to create this distinction, Douglas Gregor has [proposed and implemented type checker heuristics](http://article.gmane.org/gmane.comp.lang.swift.devel/1799) that will generate warnings when a programmer implements a member that "looks like" it should fulfill a protocol requirement but does not actually do so. This is one possible mitigation strategy that should be revisited as a way to decrease the possible impact of removing associated type witness inference from the compiler.
> proposals/0108-remove-assoctype-inference.md:As well, Dave Abrahams expresses a [potential issue](http://article.gmane.org/gmane.comp.lang.swift.evolution/21892):
> proposals/0109-remove-boolean.md:* Status: Accepted ([Rationale](http://thread.gmane.org/gmane.comp.lang.swift.evolution/23844))
> proposals/0109-remove-boolean.md:[Discussion thread](http://thread.gmane.org/gmane.comp.lang.swift.evolution/21559)
> proposals/0110-distingish-single-tuple-arg.md:Discussion: [pre-proposal](http://thread.gmane.org/gmane.comp.lang.swift.evolution/21732)
> 
> _______________________________________________
> 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/20160803/99774c48/attachment.html>