Re: [swift-evolution] [Proposal] Enum subsets

Your original syntax makes LCDColors clearly a type. The typealias obscures the fact that a new type is being created. An alternative might be something like: ``` enum LCDColors : Colors { case red, green, blue } ``` or perhaps ``` enum LCDColors subset: Colors { case red,

Re: [swift-evolution] [Proposal] Enum subsets

The syntax I described here has a number of problems, among them being: 1) Creating a supersets in the way described breaks down badly when the declarations exist within multiple modules. 2) The empty enum declaration is currently illegal and probably should be 3) The

Re: [swift-evolution] Marking sort and sorted with rethrows

+1 This is straightforward and self-documenting. > On Jun 8, 2016, at 11:21 AM, Chris Lattner via swift-evolution > wrote: > > >> On Jun 8, 2016, at 7:52 AM, Brent Royal-Gordon >> wrote: >> >>> Is there a widely used comparison function

Re: [swift-evolution] Arrays Returning Optionals instead of Index Out of Bounds

> On Jun 6, 2016, at 12:02 PM, Rob Norback via swift-evolution > wrote: > > First of all, thank you all for bringing me up to date so quickly. I looked > over the proposal and it looks awesome. > > But as Chris mentioned, this doesn't solve the expected behavior

Re: [swift-evolution] Arrays Returning Optionals instead of Index Out of Bounds

The proposal needs to discuss arrays of optionals e.g.: ```Array``` These are not just legal, they are quite handy as well. Dictionaries can also be declared with optional values, of course: ```Dictionary``` These can be pretty confusing to deal with and we should not add to

Re: [swift-evolution] [Pitch] Retiring `where` from for-in loops

> On Jun 10, 2016, at 12:09 PM, Vladimir.S via swift-evolution > wrote: > > I don't think the 'where' in 'for' loop adds another dialect of Swift more > than using of [Int] vs Array or shorthand syntax for Optionals adds it. > (in addition to 'guard' vs 'if') > So,

Re: [swift-evolution] [DRAFT] Regularizing Where Grammar (was Re: Add a while clause to for loops)

> On Jun 10, 2016, at 1:52 PM, Xiaodi Wu via swift-evolution > wrote: > > On Fri, Jun 10, 2016 at 2:38 PM, Brandon Knope via swift-evolution > > wrote: > Thanks for the laugh! > > The last week or so is

Re: [swift-evolution] [DRAFT] Regularizing Where Grammar (was Re: Add a while clause to for loops)

-1 An alternative would be to: 1) State clearly in all relevant documentation that ‘where’ filters and ‘while’ terminates. 2) Eliminate the use of ‘where’ within ‘while’ clauses. This seems pretty straightforward to me. The principle in #1 should be easy for even beginners

Re: [swift-evolution] [DRAFT] Regularizing Where Grammar (was Re: Add a while clause to for loops)

+1 > On Jun 9, 2016, at 1:05 PM, Erica Sadun via swift-evolution > wrote: > > Gist: https://gist.github.com/erica/86f00c1b8ebf45dcf3507ae6ef642b57 > > > Regularizing Where grammar > > Proposal: TBD >

Re: [swift-evolution] [Accepted with Revision] SE-0099 Restructuring Condition Clauses

While I preferred a different solution, here, I think that the current “do not design by committee” process is a good one, and the accepted solution is definite improvement. A consistent vision is critical to a project as complex as this. It is certainly in Apple’s DNA, and has served it, and

Re: [swift-evolution] Ad hoc enums / options

Here is a correction to the equivalent declaration. It would be a RawRepresentable String enum to be compatible with serialization mechanisms e.g. JSON. and other representations. Again, the name could be auto-generated to keep the syntax succinct. … would be equivalent to class MyImage {

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0099: Restructuring Condition Clauses

> On May 31, 2016, at 1:00 PM, Erica Sadun via swift-evolution > wrote: > > >> On May 31, 2016, at 12:52 PM, Xiaodi Wu wrote: >> These lines of reasoning are what have compelled me to conclude that `where` >> might not be salvageable. > > To

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0099: Restructuring Condition Clauses

> > Not allowed: > … > let a = a > let b = b where b > 10 && a > 5 > > Why would this not be allowed by your rule? You're making use of `b` in your > where clause. As I demonstrated above, essentially any assertion can be > rewritten to work around your rule. In general: It is not allowed

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0099: Restructuring Condition Clauses

> On May 31, 2016, at 1:47 PM, Xiaodi Wu <xiaodi...@gmail.com> wrote: > > > > On Tue, May 31, 2016 at 2:45 PM, Christopher Kornher via swift-evolution > <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >> >> Not allo

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0099: Restructuring Condition Clauses

but I though that it was worth exploring. > On May 31, 2016, at 3:47 PM, Xiaodi Wu via swift-evolution > <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: > >> >> >> On Tue, May 31, 2016 at 2:45 PM, Christopher Kornher via s

Re: [swift-evolution] Proposal: 'T(literal)' should construct T using the appropriate literal protocol if possible

+1 I have started using the ‘()’ syntax without even thinking about it. I never knew that it behaved in the way described. Using ‘()’ syntax will be natural for anyone with C++ experience. > On Jun 2, 2016, at 10:08 AM, John McCall via swift-evolution > wrote: >

Re: [swift-evolution] Working with enums by name

> On Jun 1, 2016, at 12:53 PM, Paul Cantrell via swift-evolution > wrote: > > Indeed, you’re quite right: verified that I get “Mars” even when the enum is > in a framework. > > It took a little digging to get back what I was thinking of: it’s when the > enum value

Re: [swift-evolution] Ad hoc enums / options

> On Jun 1, 2016, at 7:48 PM, Ricardo Parada via swift-evolution > wrote: > > > On May 31, 2016, at 3:04 PM, Erica Sadun via swift-evolution > > wrote: > >> let _ = scaleAndCropImage(image: myImage,

Re: [swift-evolution] Working with enums by name

t; >> On Jun 1, 2016, at 2:20 PM, Christopher Kornher via swift-evolution >> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >> >>> On Jun 1, 2016, at 12:53 PM, Paul Cantrell via swift-evolution >>> <s

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0099: Restructuring Condition Clauses

Apologies for going off that tangent earlier. > On May 31, 2016, at 7:47 PM, Xiaodi Wu via swift-evolution > wrote: > > Revisiting this conversation, it seems that most of the design space has been > thoroughly explored. I think all suggestions presented so far boil

Re: [swift-evolution] [Pitch] #warning

> On May 30, 2016, at 2:35 PM, Chris Lattner via swift-evolution > wrote: > > >> On May 29, 2016, at 10:36 PM, Charlie Monroe >> wrote: >> >>> As to #warning, Swift’s use of warnings are significant different than the >>> use in C. In

Re: [swift-evolution] An upcoming proposal for simplifying leak free, safe closures.

gt;> On Jun 26, 2016, at 4:25 PM, Russ Bishop <xen...@gmail.com >>> <mailto:xen...@gmail.com>> wrote: >>> >>> >>>> On Jun 26, 2016, at 12:10 PM, Christopher Kornher via swift-evolution >>>> <swift-evolution@swift.org <mailto:swift-ev

Re: [swift-evolution] An upcoming proposal for simplifying leak free, safe closures.

bject in object.property } requires no explicit >> capture since object is intuitively strongly captured there. >> >> What do we think? Worth discussing? >> >> On Mon, Jun 27, 2016 at 12:10 PM Christopher Kornher via swift-evolution >> <swift-evolution@s

Re: [swift-evolution] An upcoming proposal for simplifying leak free, safe closures.

n another way: have the tooling insert >> `[strong self]` by default when autocompleting a block. >> >> BTW, @Manuel Krebber: this proposal would not affect your run-of-the-mill >> map statement. array.map { object in object.property } requires no explicit >> ca

Re: [swift-evolution] An upcoming proposal for simplifying leak free, safe closures.

> On Jun 26, 2016, at 11:22 PM, Charlie Monroe via swift-evolution > wrote: > >> All object references used within a closure must unwrap successfully for the >> closure to execute. > I agree with the logic of this proposal, but this is the confusing part or a >

Re: [swift-evolution] An upcoming proposal for simplifying leak free, safe closures.

> On Jun 27, 2016, at 2:45 AM, Manuel Krebber via swift-evolution > <swift-evolution@swift.org> wrote: > > On 06/26/2016 09:10 PM, Christopher Kornher via swift-evolution wrote: >> The core proposal: >> —— >> >> Closures capturing object r

[swift-evolution] An upcoming proposal for simplifying leak free, safe closures.

I may be too late for Swift 3, but I am planning to propose changes to the default behavior for closures capturing object references. The introduction of Swift Playgrounds has raised the importance of simplifying the coding of leak-free, crash-free closures. New developers should not have to

Re: [swift-evolution] [Accepted] SE-0112: Improved NSError Bridging

My 2 cents: Generic errors have caused me problems on multiple occasions.They often make it difficult to handle and pass-through arbitrary errors. This pseudo Swift3 code is what I have resorted to doing on some projects. ``` enum MyError : Error { … case wrappedError( Error

Re: [swift-evolution] What're the Swift team's thoughts on Go's concurrency?

Would this prevent an object from being “known" to multiple threads? …multiple queues? If so, it would be overly restrictive for a general-purpose language. I assume that the plan includes a way to allow “unsafe” behavior to support other concurrency models. > On Aug 10, 2016, at 4:24 PM,

Re: [swift-evolution] An upcoming proposal for simplifying leak free, safe closures.

> On Jun 26, 2016, at 4:25 PM, Russ Bishop <xen...@gmail.com> wrote: > > >> On Jun 26, 2016, at 12:10 PM, Christopher Kornher via swift-evolution >> <swift-evolution@swift.org> wrote: >> >> I may be too late for Swift 3, but I am planning t

Re: [swift-evolution] An upcoming proposal for simplifying leak free, safe closures.

> On Jun 27, 2016, at 11:52 PM, Charlie Monroe via swift-evolution > wrote: > > >> On Jun 27, 2016, at 9:10 PM, Christopher Kornher > > wrote: >> >> >>> On Jun 26, 2016, at 11:22 PM, Charlie Monroe via swift-evolution

Re: [swift-evolution] An upcoming proposal for simplifying leak free, safe closures.

> On Jun 28, 2016, at 6:53 AM, ad...@wheerd.de wrote: > > Am 27.06.2016 20:55, schrieb Christopher Kornher: >>> On Jun 27, 2016, at 2:45 AM, Manuel Krebber via swift-evolution >>> <swift-evolution@swift.org> wrote: >>> On 06/26/2016 09:10 PM, Chr

Re: [swift-evolution] [Proposal] Sealed classes by default

> On Jun 28, 2016, at 2:31 PM, John McCall via swift-evolution > wrote: > >> On Jun 28, 2016, at 12:39 PM, Michael Peternell via swift-evolution >> wrote: >> Sealing classes by default is a terrible idea IMHO. Fortunately, my faith in >>

Re: [swift-evolution] Proposal: Remove the underscore and `in` for `for` loop

> On Jul 4, 2016, at 2:39 PM, Karl Wagner via swift-evolution > wrote: > > -1. I like the underscore. If it turns out you do need the loop variable > later, it's easy to see where to add it. > > Karl -1 I agree with this and doing something a specific number of

Re: [swift-evolution] [Pitch] separate syntax of class inheritance and protocol conformance

-1 I hope that this does not seem too hash but I think that this would be a gratuitous change and it would not provide any benefit to me. With protocol extensions, the difference between classes and protocols is not that great. As far as I am converted, this change would just complicate the

Re: [swift-evolution] [draft] Compound Names For Enum Cases

Your example is only has only one case, which is not typical. Perhaps I am missing something, but the only reason that I can imagine for having a case with multiple ways to “construct” it is to have all variants of the case to match. If you don’t want them to match, use a different case name.

Re: [swift-evolution] [draft] Compound Names For Enum Cases

rnher via swift-evolution >> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >>> On Jan 24, 2017, at 4:02 PM, Daniel Duan <dan...@duan.org >>> <mailto:dan...@duan.org>> wrote: >>> >>> >>> >>

Re: [swift-evolution] A case for postponing ABI stability

> On Jan 27, 2017, at 3:08 PM, Freak Show via swift-evolution > wrote: > > Maybe so - but IBM solved this very problem along with release to release > binary compatibility for C++ and a number of other languages twenty years ago > with the System Object Model

Re: [swift-evolution] [draft] Compound Names For Enum Cases

te: > >> >> >> Daniel Duan >> Sent from my iPhone >> >> On Jan 24, 2017, at 2:18 PM, Christopher Kornher via swift-evolution >> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >> >>> I agree that

Re: [swift-evolution] [draft] Compound Names For Enum Cases

olution@swift.org>> wrote: > >> >> On Jan 24, 2017, at 3:10 PM, Christopher Kornher via swift-evolution >> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >> >> Your example is only has only one case, which is not typical. Perhap

Re: [swift-evolution] [draft] Compound Names For Enum Cases

} >> >> enum E { >> case a( a: MultipleTypes ) >> } >> >> let theCurrentWay = E.a( a: .aString( value: "str") ) >> >> switch theCurrentWay { >> case .a( let x ) : >> switch x { >> case .anInt( let x ) : >>

Re: [swift-evolution] [draft] Compound Names For Enum Cases

alue: String ) : } switch theCurrentWay { case .a( let x: Int ) : break case .a( let x: String ) : break } */ > > > On Tue, Jan 24, 2017 at 17:16 Christopher Kornher via swift-evolution > <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >&

Re: [swift-evolution] [Review] SE-0155: Normalize Enum Case Representation

> On Feb 18, 2017, at 6:16 AM, David Rönnqvist via swift-evolution > wrote: > > On 18 Feb 2017, at 09:30, Slava Pestov via swift-evolution > > wrote: > >> +1, two small questions: >> >> - If two cases

Re: [swift-evolution] [Review] SE-0155: Normalize Enum Case Representation

> On Feb 20, 2017, at 12:31 PM, Christopher Kornher via swift-evolution > <swift-evolution@swift.org> wrote: > >> >> On Feb 18, 2017, at 6:16 AM, David Rönnqvist via swift-evolution >> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>>

Re: [swift-evolution] [Review] SE-0156: Class and Subtype existentials

What is your evaluation of the proposal? It seems to be a very straightforward and natural extension of existing syntax to bring Swift closer to the functionality of Objective-C and other languages. My only concern is that using `AnyObject` at first glance seems less descriptive than ‘class’

Re: [swift-evolution] A Comprehensive Rethink of Access Levels in Swift

This is a very elegant improvement. I think of “fileprivate” as “C legacy”. A submodule system seems to be a much better way to implement grouping a set of tightly coupled code elements. After all, there is no reasonable upper-limit on how large such a set of components might become and it

Re: [swift-evolution] Keyword for protocol conformance

f your choice and assume that user preferences would exist to show/hide these indicators. > On Aug 24, 2016, at 11:13 AM, Christopher Kornher via swift-evolution > <swift-evolution@swift.org> wrote: > > Requiring "override" when anything overrides a method defined in

Re: [swift-evolution] Keyword for protocol conformance

heritance (not polymorphism) for structs and possibly even enums, if anyone knows of a use for that. This is a feature that I could have used on a few projects, but there are far more important features in the queue, and that discussion should probably wait until after Swift 4, if it happens at

Re: [swift-evolution] Keyword for protocol conformance

Requiring "override" when anything overrides a method defined in a protocol extension should be added - structure and enumerated included, of course. Protocol extensions added inheritance to structs and enums and this should be made explicit. Sent from my iPad > On Aug 24, 2016, at 12:55 AM,

Re: [swift-evolution] Add code to super methods.

If memory serves: the CLOS Metaobject Protocol had features like this. This might be good read if you are considering writing a proposal for this. (Dylan Lives! :) ) https://en.wikipedia.org/wiki/The_Art_of_the_Metaobject_Protocol

Re: [swift-evolution] Why is AnyObject's bridging so weird in Swift 3?

> On Dec 12, 2016, at 2:09 PM, Joe Groff via swift-evolution > wrote: > > >> On Dec 12, 2016, at 12:59 PM, Charles Srstka > > wrote: >> >>> On Dec 12, 2016, at 2:46 PM, Joe Groff >>

Re: [swift-evolution] Passing class protocols to functions accepting AnyObject

This issue bites me frequently and is a barrier to clean "protocol-based” programming. This is extremely counter-intuitive to me, at least. Not having a good workaround for this really makes the language seem incomplete. Recently I had the need to use instances of a protocol as keys in a

Re: [swift-evolution] Move placement of 'throws' statement

-1 for addressing this now. Typed throws will undoubtedly affect this change and the two issues should be addressed at the same time. As a Java veteran, I agree with the sentiment to avoid the Java exception typing mechanism which complicates using and maintaining large projects. Knowing the

Re: [swift-evolution] [Pitch] Add the DefaultConstructible protocol to the standard library

-1 1) There is no semantic meaning to empty initializers. 2) It is a simple protocol to create and apply for specific (and semantically meaningful) purposes 3) This would be a core protocol and I defer to the team. when it comes to low-level protocols. This seems to be in conflict with their

Re: [swift-evolution] [Pitch] Allow closures/default params to satisfy protocol requirements

> On Mar 26, 2017, at 3:09 PM, Christopher Kornher via swift-evolution > <swift-evolution@swift.org> wrote: > > A comment: Your description of #2 is a little confusing. Functions with > default arguments can currently satisfy protocols. Perhaps it should be > “Allow funct

Re: [swift-evolution] [Pitch] Allow closures/default params to satisfy protocol requirements

A comment: Your description of #2 is a little confusing. Functions with default arguments can currently satisfy protocols. Perhaps it should be “Allow functions with extra default arguments to satisfy protocols" I have not had the need for the features you mentioned, but it would be nice to

Re: [swift-evolution] Smart KeyPaths

I love the proposal and it is great to see this feature being considered. This provides a great foundation for future functionality. I too find the syntax confusing. The syntax is elegant and does not introduce any extra keywords, but accessing key paths is an advanced “meta” feature and does

Re: [swift-evolution] Smart KeyPaths

> On Mar 20, 2017, at 5:12 AM, David Hart via swift-evolution > wrote: > > > >> On 20 Mar 2017, at 10:39, Jonathan Hull via swift-evolution >> wrote: >> >> +1. This is my favorite solution so far. >> >> With ‘Person.keypath.name'

Re: [swift-evolution] [Review] SE-0159: Fix Private Access Levels

The goal of the review process is to improve the proposal under review through constructive criticism and, eventually, determine the direction of Swift. When writing your review, here are some questions you might want to answer in your review: What is your evaluation of the proposal? -1 Is

Re: [swift-evolution] [Accepted] SE-0168: Multi-Line String Literals

> On Apr 21, 2017, at 12:58 PM, Xiaodi Wu > wrote: > > Sorry, I don't follow. What's this about paragraphs? This was a common example of the many types of textual input that would benefit from concatenation characters in multiline text.

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] [Pitch] Guard/Catch

have a place as part of that effort. > On Jul 8, 2017, at 5:16 PM, Christopher Kornher via swift-evolution > <swift-evolution@swift.org> wrote: > > Thanks for you considerate reply. My concern over the proliferation of “sugar > proposals” is a general one. This proposal ha

Re: [swift-evolution] [Pitch] Guard/Catch

I am opposed to this proposal because it muddies up the language to support what is essentially an edge case. The standard way to exit a function early because an exception is thrown is to make the function itself throw, if it is part of a larger operation. The addition of a few lines of

Re: [swift-evolution] [Pitch] Guard/Catch

Thanks for you considerate reply. My concern over the proliferation of “sugar proposals” is a general one. This proposal has more merit and general utiliity than many others. I have never used a throwing function in a guard statement that was not itself in a throwing function, but I can see

[swift-evolution] Fwd: [Pitch] Guard/Catch

same monadic binding structure applied to throwing functions. Elviro ___ swift-evolution mailing list swift-evolution@swift.org <mailto:swift-evolution@swift.org> https://lists.swift.org/mailman/listinfo/swift-evolution > Il giorno 09 lug 2

Re: [swift-evolution] Would having "MyType.Protocol" to indicate a type's protocols mess anything up?

A full-fledged introspection system should provide this information, which I suppose could be useful for creating proxies through code generation or dynamic Objective-C like features, should they ever be added to the language. Would that be sufficient for your needs? It is not clear to me what

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

I am not sure that macros and annotations would be good, either. It may be impossible to avoid them, given Swift’s goal of “world domination”. Both features are very useful in certain applications. We could continue to use custom tools like Cog and Sourcery when we need to, or standardize and

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

For completeness: I forgot to mention that I have been meaning to check-out Sourcery, which is possibly a more “Swifty” tool. I use Cog’s file-scope extensively, and it is unclear to me if that is a feature of Sourcery https://github.com/krzysztofzablocki/Sourcery OK, now I am sure that

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

I assume that the planned “hygienic macro” facility, if it has access to metadata, or “annotations", could be used for these sorts of meta tasks, . This is slightly off-topic, but I hope that there is a way for macros to be fully expanded and debuggable (and even formatted). I use Cog with

Re: [swift-evolution] [discussion] Class stored properties?

Class variables are not common, but they are the most natural way to implement class-specific functionality. Off the top of my head, I have used class variables for: 1) Custom allocation schemes, e.g. pools, LRU implementations 2) Diagnostics, e.g. counting the number of instances of a given

Re: [swift-evolution] typed throws

> On Aug 18, 2017, at 7:38 AM, Matthew Johnson via swift-evolution > wrote: > > I would like to reiterate the point I made in the question that spawned this > thread: there are *many* Swift libraries for writing async code of various > sorts which are *already*

Re: [swift-evolution] [Review] SE-0176: Enforce Exclusive Access to Memory

https://github.com/apple/swift-evolution/blob/master/proposals/0176-enforce-exclusive-access-to-memory.md What is your evaluation of the proposal? +1 It seems to be a carefully considered

Re: [swift-evolution] Enums and Source Compatibility

> On Sep 16, 2017, at 8:41 AM, Rod Brown via swift-evolution > wrote: > > > On 16 Sep 2017, at 7:22 pm, Goffredo Marocchi via swift-evolution > > wrote: > >> I am still unsure why we are choosing again a

Re: [swift-evolution] Enums and Source Compatibility

> On Sep 16, 2017, at 11:28 AM, Christopher Kornher via swift-evolution > <swift-evolution@swift.org> wrote: > >> >> On Sep 16, 2017, at 8:41 AM, Rod Brown via swift-evolution >> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>>

Re: [swift-evolution] Enums and Source Compatibility

> On Sep 17, 2017, at 3:20 PM, Christopher Kornher via swift-evolution > <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: > >> >>> On Sep 17, 2017, at 6:33 AM, Rod Brown via swift-evolution >>> <swift-evolution@swift.org <ma

Re: [swift-evolution] [Pitch] Synthesized static enum property to iterate over cases

> On Sep 9, 2017, at 12:36 PM, Matthew Johnson via swift-evolution > wrote: > > > > Sent from my iPad > > On Sep 9, 2017, at 11:42 AM, gs. > wrote: > >> How does fragility play into this? Does this only work

Re: [swift-evolution] Two thoughts on concurrency

I don’t think that there are any simple rules that define “Complexity”. I hope that is not too off-topic... https://www.edwardtufte.com/tufte/books_vdqi > It makes sense to make a distinction between adding keywords/modifiers to implement a niche feature and implementing fairly well

Re: [swift-evolution] [SE-0155][Discuss] The role of labels in enum case patterns

Apologies for rehashing this, but we seem to be going down that path… I am in the minority on this issue and have held my opinions because I thought that they would have served as simply a distraction and I was extremely busy at the time. That may have been a mistake on my part, because raising

Re: [swift-evolution] Proposal: Introduce User-defined "Dynamic Member Lookup" Types

> On Dec 4, 2017, at 1:12 PM, Vladimir.S via swift-evolution > wrote: > > On 04.12.2017 19:27, Joe DeCapo via swift-evolution wrote: >>> On Dec 4, 2017, at 10:08 AM, Benjamin G via swift-evolution >>> >