Re: [swift-evolution] Why you can't make someone else's class Decodable: a long-winded explanation of 'required' initializers

Thanks for the detailed explanation Jordan! Comment inline: > On 3 Aug 2017, at 02:08, Jordan Rose wrote: > > David Hart recently asked on Twitter > if there was a good > way to add Decodable support to somebody

Re: [swift-evolution] [Pitch] New Version of Array Proposal

> On Aug 3, 2017, at 12:45 AM, Daryle Walker wrote: >> On Aug 2, 2017, at 4:44 PM, Karl Wagner via swift-evolution >> > wrote: >> >> I’m -1 on adding a fixed-sized Array type. >> >> It goes back to something which I

Re: [swift-evolution] [Pitch] New Version of Array Proposal

> On Aug 2, 2017, at 21:45, Daryle Walker via swift-evolution > wrote: > > I’m not good at explicit explanations, so having to justify adding a type > that’s been around for a long time (at least FORTRAN 4+ decades ago) an > almost every systems programming

Re: [swift-evolution] [Pitch] #dup -- a duplication "macro"(?)

> On Aug 2, 2017, at 21:39, Daryle Walker wrote: > >>> On Aug 1, 2017, at 9:56 AM, Daryle Walker wrote: >>> On Jul 31, 2017, at 10:38 PM, David Sweeris wrote: On Jul 31, 2017, at 7:23 PM, Daryle Walker via swift-evolution

Re: [swift-evolution] [Pitch] New Version of Array Proposal

FSA indices may be nominal, but you still need some way to store them. A good example of this is when you’re implementing cubemaps with 3-tuple vectors. Selecting a cube face involves selecting components of the vector at a variable offset supplied by a function parameter. Doing this with a switch

Re: [swift-evolution] [Pitch] New Version of Array Proposal

> On Aug 2, 2017, at 4:44 PM, Karl Wagner via swift-evolution > wrote: > > I’m -1 on adding a fixed-sized Array type. > > It goes back to something which I remember reading from John McCall earlier > this week but can’t find any more: about tuple indices being

Re: [swift-evolution] [Pitch] #dup -- a duplication "macro"(?)

> On Aug 1, 2017, at 9:56 AM, Daryle Walker wrote: > >> On Jul 31, 2017, at 10:38 PM, David Sweeris > > wrote: >> >>> On Jul 31, 2017, at 7:23 PM, Daryle Walker via swift-evolution >>>

Re: [swift-evolution] [Pitch] New Version of Array Proposal

> On Aug 1, 2017, at 7:21 PM, John McCall wrote: > >> On Aug 1, 2017, at 5:49 PM, David Sweeris via swift-evolution >> wrote: >>> On Aug 1, 2017, at 10:54 AM, Daryle Walker via swift-evolution >>> wrote: >>> >>> A

Re: [swift-evolution] TrigonometricFloatingPoint/MathFloatingPoint protocol?

On Wed, Aug 2, 2017 at 10:58 PM, Xiaodi Wu wrote: > On Wed, Aug 2, 2017 at 21:55 Taylor Swift wrote: > >> Swift Breeze *was* on Github ,, i don’t >> know whose argument that strengthens here :) >> > > No, no, I mean,

Re: [swift-evolution] TrigonometricFloatingPoint/MathFloatingPoint protocol?

On Wed, Aug 2, 2017 at 21:55 Taylor Swift wrote: > Swift Breeze *was* on Github ,, i don’t > know whose argument that strengthens here :) > No, no, I mean, doesn't GitHub itself fit the roles you defined earlier? And by implication, why

Re: [swift-evolution] TrigonometricFloatingPoint/MathFloatingPoint protocol?

Swift Breeze *was* on Github ,, i don’t know whose argument that strengthens here :) Here was the original thread it was introduced in. It got a lot of attention and +1’s but

Re: [swift-evolution] TrigonometricFloatingPoint/MathFloatingPoint protocol?

Hmm, I'd never heard of Swift Breeze. Doesn't seem like it'd be a successful model to follow. Is there a reason why GitHub itself doesn't meet these criteria? On Wed, Aug 2, 2017 at 21:42 Taylor Swift wrote: > Trying to gather together a bunch of unpaid people won’t

Re: [swift-evolution] TrigonometricFloatingPoint/MathFloatingPoint protocol?

That's not what I'm saying at all. I'm responding to your contention that no library without "backing" will see wide adoption: if, as you say, you would like to have a math library with sufficient "backing," then realize that you're arguing for someone to devote financial resources to the problem.

Re: [swift-evolution] TrigonometricFloatingPoint/MathFloatingPoint protocol?

On Wed, Aug 2, 2017 at 9:18 PM, Xiaodi Wu wrote: > On Wed, Aug 2, 2017 at 7:29 PM, Taylor Swift wrote: > >> >> >> On Wed, Aug 2, 2017 at 7:54 PM, Xiaodi Wu wrote: >> >>> On Wed, Aug 2, 2017 at 6:29 PM, Taylor Swift

Re: [swift-evolution] TrigonometricFloatingPoint/MathFloatingPoint protocol?

On Wed, Aug 2, 2017 at 7:29 PM, Taylor Swift wrote: > > > On Wed, Aug 2, 2017 at 7:54 PM, Xiaodi Wu wrote: > >> On Wed, Aug 2, 2017 at 6:29 PM, Taylor Swift >> wrote: >> >>> See, my problem with statements like this one, is that

[swift-evolution] Why you can't make someone else's class Decodable: a long-winded explanation of 'required' initializers

David Hart recently asked on Twitter if there was a good way to add Decodable support to somebody else's class. The short answer is "no, because you don't control all the subclasses", but David already understood that and wanted to know

Re: [swift-evolution] TrigonometricFloatingPoint/MathFloatingPoint protocol?

> On Aug 2, 2017, at 4:29 PM, Nicolas Fezans wrote: > > Your notation is indeed correct, even though using x on both side might > confuse some people, this is correct. But no I would not go that far, I would, just not right now. There are more important issues to the

Re: [swift-evolution] TrigonometricFloatingPoint/MathFloatingPoint protocol?

> On Aug 2, 2017, at 4:29 PM, Xiaodi Wu wrote: > >> On Wed, Aug 2, 2017 at 6:17 PM, David Sweeris wrote: >> >> >> >> Sent from my iPad >> On Aug 2, 2017, at 3:43 PM, Xiaodi Wu via swift-evolution >> wrote: >> >>>

Re: [swift-evolution] TrigonometricFloatingPoint/MathFloatingPoint protocol?

Your notation is indeed correct, even though using x on both side might confuse some people, this is correct. But no I would not go that far, but I think the example I just replied before which should execute also on octave/scilab (most people in the list probably do not have a matlab license)

Re: [swift-evolution] TrigonometricFloatingPoint/MathFloatingPoint protocol?

On Wed, Aug 2, 2017 at 6:17 PM, David Sweeris wrote: > > > > Sent from my iPad > On Aug 2, 2017, at 3:43 PM, Xiaodi Wu via swift-evolution < > swift-evolution@swift.org> wrote: > > > On Wed, Aug 2, 2017 at 17:37 Nicolas Fezans > wrote: > >> I think

Re: [swift-evolution] TrigonometricFloatingPoint/MathFloatingPoint protocol?

See, my problem with statements like this one, is that the answer “should be supported as a third-party library” can also be interpreted as “not my problem, go figure it out yourselves”. The idea that central entity can only pay attention to what they want to, and the Community™ will magically

Re: [swift-evolution] [Planning][Request] "constexpr" for Swift 5

> On Aug 2, 2017, at 6:29 PM, Karl Wagner wrote: > > >> On 3. Aug 2017, at 00:21, John McCall > > wrote: >> >> >>> On Aug 2, 2017, at 6:10 PM, John McCall via swift-evolution >>>

Re: [swift-evolution] Inconsistencies related to prepositions

On Wed, Aug 2, 2017 at 5:48 PM, Mike Sanderson wrote: > > On Wed, Aug 2, 2017 at 1:49 PM, Xiaodi Wu via swift-evolution < > swift-evolution@swift.org> wrote: > >> ... >> >> This topic was reviewed extensively at the beginning of Swift Evolution. >> The idea is that type

Re: [swift-evolution] TrigonometricFloatingPoint/MathFloatingPoint protocol?

Sent from my iPad > On Aug 2, 2017, at 3:43 PM, Xiaodi Wu via swift-evolution > wrote: > > >> On Wed, Aug 2, 2017 at 17:37 Nicolas Fezans wrote: >> I think that the items mentioned earlier in the list (just reminded below) >> should not

Re: [swift-evolution] TrigonometricFloatingPoint/MathFloatingPoint protocol?

> On 3. Aug 2017, at 00:43, Xiaodi Wu via swift-evolution > wrote: > > > On Wed, Aug 2, 2017 at 17:37 Nicolas Fezans > wrote: > I think that the items mentioned earlier in the list (just reminded below)

Re: [swift-evolution] Inconsistencies related to prepositions

On Wed, Aug 2, 2017 at 1:49 PM, Xiaodi Wu via swift-evolution < swift-evolution@swift.org> wrote: > ... > > This topic was reviewed extensively at the beginning of Swift Evolution. > The idea is that type information does not need to be repeated in the > label. Since the locale is of type Locale,

Re: [swift-evolution] TrigonometricFloatingPoint/MathFloatingPoint protocol?

On Wed, Aug 2, 2017 at 17:37 Nicolas Fezans wrote: > I think that the items mentioned earlier in the list (just reminded below) > should not all be treated equally. > > - RNG and cryptography library (CryptoSwift could be a good base for this) > - Generic Math

Re: [swift-evolution] TrigonometricFloatingPoint/MathFloatingPoint protocol?

I think that the items mentioned earlier in the list (just reminded below) should not all be treated equally. - RNG and cryptography library (CryptoSwift could be a good base for this) - Generic Math library/Vector library - Basic data structures (Tree, Balanced Tree, Heap, Queue, SkipList,

Re: [swift-evolution] [Planning][Request] "constexpr" for Swift 5

> On 3. Aug 2017, at 00:21, John McCall wrote: > > >> On Aug 2, 2017, at 6:10 PM, John McCall via swift-evolution >> > wrote: >> >>> On Aug 2, 2017, at 5:56 PM, Karl Wagner >>

Re: [swift-evolution] [Planning][Request] "constexpr" for Swift 5

> On Aug 2, 2017, at 5:56 PM, Karl Wagner wrote: >> On 31. Jul 2017, at 21:09, John McCall via swift-evolution >> > wrote: >> >>> On Jul 31, 2017, at 3:15 AM, Gor Gyolchanyan >>

Re: [swift-evolution] [Planning][Request] "constexpr" for Swift 5

> On 31. Jul 2017, at 21:09, John McCall via swift-evolution > wrote: > >> On Jul 31, 2017, at 3:15 AM, Gor Gyolchanyan >> wrote: >>> On Jul 31, 2017, at 7:10 AM, John McCall via swift-evolution >>> wrote:

Re: [swift-evolution] TrigonometricFloatingPoint/MathFloatingPoint protocol?

On Wed, Aug 2, 2017 at 12:23 PM, Taylor Swift wrote: > > > On Wed, Aug 2, 2017 at 12:45 PM, Gor Gyolchanyan < > gor.f.gyolchan...@icloud.com> wrote: > >> >> On Aug 2, 2017, at 4:35 AM, Xiaodi Wu via swift-evolution < >> swift-evolution@swift.org> wrote: >> >> On Tue, Aug 1,

Re: [swift-evolution] Inconsistencies related to prepositions

On Wed, Aug 2, 2017 at 2:23 PM, Robert Bennett wrote: > I guess I will accept that implicit types will serve to explain the > purpose of prepositions and do not need to be written explicitly. But I’m > curious if there are any other thoughts on the trend exemplified by >

Re: [swift-evolution] [Pitch] New Version of Array Proposal

I’m -1 on adding a fixed-sized Array type. It goes back to something which I remember reading from John McCall earlier this week but can’t find any more: about tuple indices being nominal and not ordinal. How do fixed-size Arrays differ? Are their indexes truly not nominal? The difference

Re: [swift-evolution] Inconsistencies related to prepositions

I guess I will accept that implicit types will serve to explain the purpose of prepositions and do not need to be written explicitly. But I’m curious if there are any other thoughts on the trend exemplified by `fetch(withRecordID:)` and the issue that the “how” is described but not the “what”,

Re: [swift-evolution] [Proposal] Explicit Non-Default-Implemented Protocol Requirements

It seems that this discussion got sidetracked from the original proposal, that aimed to provide more visibility about default implementation for protocols, to the merits of writing functionality for classes and structs in same-file extensions. 1. `default` for Protocols First, the issue the

Re: [swift-evolution] [Proposal] Explicit Non-Default-Implemented Protocol Requirements

I have always found it curious that extensions cannot be named. Since same-file extension are considered to be superior to comments as a way of separating concerns, wouldn’t it make sense to allow naming of extensions? Extension names could possibly be included in symbols for entities in the

Re: [swift-evolution] Inconsistencies related to prepositions

On Wed, Aug 2, 2017 at 12:00 Robert Bennett via swift-evolution < swift-evolution@swift.org> wrote: > I agree with some of your points and disagree with others. You are right > that Swift did not get everything right when it “Swiftified” some > Objective-C names. However, I don’t think your

Re: [swift-evolution] [Proposal] Explicit Non-Default-Implemented Protocol Requirements

I disagree about the back-conversion being different. I would've just as easily made a property in CasualAnswer that returns a Bool. The fact that its implemented as an extension of Bool is purely cosmetic and avoids namespace clutter. Also, it doesn't make sense to add semantics to the

Re: [swift-evolution] [Proposal] Explicit Non-Default-Implemented Protocol Requirements

i would have written it like this < https://gist.github.com/kelvin13/ba42b620f80ee94fbb0d0841056aac97> On Wed, Aug 2, 2017 at 12:34 PM, Gor Gyolchanyan < gor.f.gyolchan...@icloud.com> wrote: > > On Aug 2, 2017, at 7:31 PM, Tino Heth <2...@gmx.de> wrote: > > > Consider these two alternative ways

Re: [swift-evolution] TrigonometricFloatingPoint/MathFloatingPoint protocol?

> On Aug 2, 2017, at 8:23 PM, Taylor Swift wrote: > > > > On Wed, Aug 2, 2017 at 12:45 PM, Gor Gyolchanyan > > wrote: > >> On Aug 2, 2017, at 4:35 AM, Xiaodi Wu via swift-evolution >>

Re: [swift-evolution] TrigonometricFloatingPoint/MathFloatingPoint protocol?

On Wed, Aug 2, 2017 at 12:45 PM, Gor Gyolchanyan < gor.f.gyolchan...@icloud.com> wrote: > > On Aug 2, 2017, at 4:35 AM, Xiaodi Wu via swift-evolution < > swift-evolution@swift.org> wrote: > > On Tue, Aug 1, 2017 at 7:38 PM, Taylor Swift wrote: > >> >> >> On Tue, Aug 1, 2017

Re: [swift-evolution] Inconsistencies related to prepositions

I agree with some of your points and disagree with others. You are right that Swift did not get everything right when it “Swiftified” some Objective-C names. However, I don’t think your criticisms are all correct. At some point, Swift decided to omit needless “helpful” names from method names.

Re: [swift-evolution] TrigonometricFloatingPoint/MathFloatingPoint protocol?

> On Aug 2, 2017, at 4:35 AM, Xiaodi Wu via swift-evolution > wrote: > > On Tue, Aug 1, 2017 at 7:38 PM, Taylor Swift > wrote: > > > On Tue, Aug 1, 2017 at 5:50 PM, Xiaodi Wu

Re: [swift-evolution] TrigonometricFloatingPoint/MathFloatingPoint protocol?

A thousand times yes to this. On Tue, Aug 1, 2017 at 9:35 PM, Xiaodi Wu via swift-evolution < swift-evolution@swift.org> wrote: > On Tue, Aug 1, 2017 at 7:38 PM, Taylor Swift wrote: > >> >> >> On Tue, Aug 1, 2017 at 5:50 PM, Xiaodi Wu wrote: >> >>>

Re: [swift-evolution] [Proposal] Explicit Non-Default-Implemented Protocol Requirements

> On Aug 2, 2017, at 7:31 PM, Tino Heth <2...@gmx.de> wrote: > > >> Consider these two alternative ways of writing the same code: >> https://gist.github.com/technogen-gg/17b6d5e13c13080850dceda28cfe1caa >> > Great example

Re: [swift-evolution] [Planning][Request] "constexpr" for Swift 5

> On Aug 2, 2017, at 12:17 PM, Félix Cloutier wrote: > `[Int x N]` solves all of the problems that I mentioned, and I'm happy with > that syntax. In fact, I'm championing its merits versus an approach that > doesn't include the number of elements. :) > > Unless I got

Re: [swift-evolution] [Proposal] Explicit Non-Default-Implemented Protocol Requirements

> Consider these two alternative ways of writing the same code: > https://gist.github.com/technogen-gg/17b6d5e13c13080850dceda28cfe1caa > Great example — the first is better. But not because of extensions: // MARK: - String

Re: [swift-evolution] [Planning][Request] "constexpr" for Swift 5

> The bound value is still fundamentally part of the type of the variable; it's > just that the actual value is not known statically. I don't know enough about the internals to prove such a conclusion ;-), but my intuition said that this would be possible… My intuition also says that this

Re: [swift-evolution] [Planning][Request] "constexpr" for Swift 5

`[Int x N]` solves all of the problems that I mentioned, and I'm happy with that syntax. In fact, I'm championing its merits versus an approach that doesn't include the number of elements. :) Unless I got things wrong this entire time, the proposed spelling

Re: [swift-evolution] [Proposal] Explicit Non-Default-Implemented Protocol Requirements

Consider these two alternative ways of writing the same code: https://gist.github.com/technogen-gg/17b6d5e13c13080850dceda28cfe1caa > On Aug 2, 2017, at 6:57 PM, Taylor Swift wrote: > > I don’t

Re: [swift-evolution] [Planning][Request] "constexpr" for Swift 5

> On Aug 2, 2017, at 11:44 AM, Félix Cloutier via swift-evolution > wrote: > > >> Le 31 juil. 2017 à 18:54, Xiaodi Wu > > a écrit : >> It doesn't allow you to specify the size of the array, it's just a promise >>

Re: [swift-evolution] RFC: structuring forums for best use for swift-evolution

> For Swift 4, the core team identified a set of priorities. Provided the same > will be done for Swift 5, these are natural categories for the evolution part > of the forum, to my mind. We fully agree on this point. > It should have the positive effect of encouraging discussion to be focused,

Re: [swift-evolution] [Proposal] Explicit Non-Default-Implemented Protocol Requirements

I don’t understand how extensions help with code locality. It’s literally a matter of *curly braces*. I already glue the extension block to the bottom } of the protocol block anyway by omitting the empty linebreak. protocol Protocol { func default_function() } extension Protocol { func

Re: [swift-evolution] [Proposal] Explicit Non-Default-Implemented Protocol Requirements

> On Aug 2, 2017, at 6:49 PM, Rock Yang wrote: > > I found maybe it's unable to provide implementation in protocol declaration > which has associatedtype. > > Here is Sequence, which has Subsequence as associatedtype. AnySequence is > inferred if no custom Subsequence is

Re: [swift-evolution] [Planning][Request] "constexpr" for Swift 5

> Le 31 juil. 2017 à 18:54, Xiaodi Wu a écrit : > It doesn't allow you to specify the size of the array, it's just a promise > that the array is some immutable size. For instance, a `fixed [CGFloat]` > would be a terrible type to represent a vector, but a

Re: [swift-evolution] [Proposal] Explicit Non-Default-Implemented Protocol Requirements

> On Aug 2, 2017, at 6:18 PM, Tino Heth <2...@gmx.de> wrote: > > Hi Gor, > > [I'll continue to answer below, but that wont help you with your proposal…] > > The question is wether this > protocol Equatable { > > static func == (_ some: Self, _ other: Self) -> Bool > > default

[swift-evolution] Inconsistencies related to prepositions

When Swift 3 launched, it introduced a new concept of placing the preposition inside the parentheses. (See discussion here: https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160208/009523.html). I'm fine with that, however this change got implemented in an inconsistent manner,

Re: [swift-evolution] [Proposal] Explicit Non-Default-Implemented Protocol Requirements

> On Aug 2, 2017, at 6:15 PM, Taylor Swift wrote: > > I agree with this, extensions on types defined in the same file are generally > silly, and default implementations belong in the protocol body. I don’t agree > with certain style guides prescription of same-file

Re: [swift-evolution] [Proposal] Explicit Non-Default-Implemented Protocol Requirements

Hi Gor, [I'll continue to answer below, but that wont help you with your proposal…] The question is wether this protocol Equatable { static func == (_ some: Self, _ other: Self) -> Bool default static func != (_ some: Self, _ other: Self) -> Bool } extension Equatable {

Re: [swift-evolution] [Proposal] Explicit Non-Default-Implemented Protocol Requirements

> On Aug 2, 2017, at 5:30 PM, Xiaodi Wu wrote: > > Besides the comments below on consensus about how to deal with the > documentation aspect, I should point out that your example is incorrect. != > is not a protocol requirement of Equatable with a default implementation,

Re: [swift-evolution] [Proposal] Explicit Non-Default-Implemented Protocol Requirements

Besides the comments below on consensus about how to deal with the documentation aspect, I should point out that your example is incorrect. != is not a protocol requirement of Equatable with a default implementation, but a protocol extension method that cannot be overridden which is *not* a

Re: [swift-evolution] RFC: structuring forums for best use for swift-evolution

For Swift 4, the core team identified a set of priorities. Provided the same will be done for Swift 5, these are natural categories for the evolution part of the forum, to my mind. It should have the positive effect of encouraging discussion to be focused, and would allow even new participants to

Re: [swift-evolution] [Proposal] Explicit Non-Default-Implemented Protocol Requirements

> On Aug 2, 2017, at 3:33 PM, Tino Heth <2...@gmx.de> wrote: > > >> The same-file mentality comes from Swift 3, which introduced fileprivate >> (which, since Swift 4, got merged into private within a single file scope). >> With that feature, implementors don't have to choose between access

Re: [swift-evolution] [Proposal] Explicit Non-Default-Implemented Protocol Requirements

> The same-file mentality comes from Swift 3, which introduced fileprivate > (which, since Swift 4, got merged into private within a single file scope). > With that feature, implementors don't have to choose between access > protection and code locality and can get both. You weren't here when

Re: [swift-evolution] [Proposal] Explicit Non-Default-Implemented Protocol Requirements

On Wed, Aug 2, 2017 at 1:09 PM, Gor Gyolchanyan via swift-evolution < swift-evolution@swift.org> wrote: > > and if you have a huge entity, it doesn't get better just because you > split it and hide its complexity. > > > Splitting and hiding complexity is by far the only reasonable way of >

Re: [swift-evolution] [Proposal] Explicit Non-Default-Implemented Protocol Requirements

On Wed, Aug 2, 2017 at 12:26 PM, Tino Heth via swift-evolution < swift-evolution@swift.org> wrote: > > That would work as well, but it has the downside of forcing a potentially > huge number of methods to be implemented in a single place, reducing the > readability as opposed to packing them into

Re: [swift-evolution] [Proposal] Explicit Non-Default-Implemented Protocol Requirements

> On Aug 2, 2017, at 1:26 PM, Tino Heth <2...@gmx.de> wrote: > > >> That would work as well, but it has the downside of forcing a potentially >> huge number of methods to be implemented in a single place, reducing the >> readability as opposed to packing them into semantically related groups

Re: [swift-evolution] [Proposal] Explicit Non-Default-Implemented Protocol Requirements

> That would work as well, but it has the downside of forcing a potentially > huge number of methods to be implemented in a single place, reducing the > readability as opposed to packing them into semantically related groups in > the form of extensions. I really don't get why people are so

Re: [swift-evolution] [Proposal] Explicit Non-Default-Implemented Protocol Requirements

That would work as well, but it has the downside of forcing a potentially huge number of methods to be implemented in a single place, reducing the readability as opposed to packing them into semantically related groups in the form of extensions. Also, please include the original message for

Re: [swift-evolution] [Proposal] Explicit Non-Default-Implemented Protocol Requirements

The problem is real, but afaics, there is some consensus that the best solution is to allow default implementations inside the protocol declaration: Less typing, no new keywords, easy to understand. - Tino ___ swift-evolution mailing list

[swift-evolution] [Proposal] Explicit Non-Default-Implemented Protocol Requirements

Good day, swift community! This time, I'd like to bring your attention to an everyday problem which, I'm sure, you've all dealt with at some point. Motivation Many protocols have a lot of default-implemented requirements so that they can be customized, which would otherwise be impossible to

Re: [swift-evolution] RFC: structuring forums for best use for swift-evolution

> On 2 Aug 2017, at 09:44, Tino Heth via swift-evolution > wrote: > > Thanks for the update! > >> - We currently have swift-evolution and swift-evolution-announce. Should >> we use a specific “category” in the forum for "proposals that are in active >> review" —

Re: [swift-evolution] RFC: structuring forums for best use for swift-evolution

Thanks for the update! > - We currently have swift-evolution and swift-evolution-announce. Should we > use a specific “category” in the forum for "proposals that are in active > review" — and possibly remove the need to have something like > swift-evolution-announce? Guess

Re: [swift-evolution] RFC: structuring forums for best use for swift-evolution

> On Aug 1, 2017, at 10:30 PM, Rick Mann wrote: > > My inclination is to start with two broad-level categories: Evolution and > User (this presumes both the evolution and user lists are moving to > Discourse). Just to help frame the rest of the discussion on this