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 no

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' it is obvious that we are creating a key path. >> Ther

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 th

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 all

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 > wrote: > > 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

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. Using ‘\’ as a continuation

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 a

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 p

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 try/cat

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 that

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 > wrote: > > Thanks for you considerate reply. My concern over the proliferation of “sugar > proposals” is a general one. This proposal has more merit and general > u

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

inding 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 2017, alle ore 0

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 Swift

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 someone

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 b

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 ext

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 cla

Re: [swift-evolution] [Pitch] Improve `init(repeating:count)`

We might as well add the index to the call so elements can be created from other lists, etc. Array(repeatedlyCalling: { (index:Int) in MyView( forIndex:index ) }, count: 3) // This might by syntactically correct... > On Aug 17, 2017, at 9:24 AM, Rob Mayoff via swift-evolution > wrote: > >

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* using typed errors via `Result

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 established

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] [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 for fragile (closed) >> and internal/private/filepri

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 > mailto:swift-evolution@swift.org>> wrote: > >> I am still unsure why we are choosing again a default that protects library >> writers more than lib

Re: [swift-evolution] Enums and Source Compatibility

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

Re: [swift-evolution] Enums and Source Compatibility

> On Sep 17, 2017, at 6:33 AM, Rod Brown via swift-evolution > wrote: > > >> On 17 Sep 2017, at 4:35 am, Christopher Kornher > <mailto:ckorn...@me.com>> wrote: >> >>> On Sep 16, 2017, at 11:28 AM, Christopher Kornher via swift-evolution

Re: [swift-evolution] Enums and Source Compatibility

ep 2017, at 4:35 am, Christopher Kornher >>> <mailto:ckorn...@me.com>> wrote: >>>> >>>>> On Sep 16, 2017, at 11:28 AM, Christopher Kornher via swift-evolution >>>>> mailto:swift-evolution@swift.org>> wrote: >>>>>

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 C compilers, many of the warnings produced *should* be

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

Forwarding on behalf of Chris Kornher: I think that this is a great idea. It would be nice to: 1) Have a standard way to generate these values from textual or other serialized representations. 2) A way to be able to store these vales (as preferences, for example) A simple way to

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 which, I'd add: `where` suggests there's a subord

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 beca

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

> On May 31, 2016, at 1:47 PM, Xiaodi Wu wrote: > > > > On Tue, May 31, 2016 at 2:45 PM, Christopher Kornher via swift-evolution > mailto:swift-evolution@swift.org>> wrote: >> >> Not allowed: >> … >> let a = a >> let b = b where b >

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

I should have left the entire context in my reply. > On May 31, 2016, at 1:59 PM, Xiaodi Wu wrote: > > On Tue, May 31, 2016 at 2:51 PM, Christopher Kornher via swift-evolution > mailto:swift-evolution@swift.org>> wrote: > >> On May 31, 2016, at 1:47 PM,

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

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

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 down to > these: > > Q: H

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 is inside some other data s

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

016, at 2:20 PM, Christopher Kornher via swift-evolution >> mailto:swift-evolution@swift.org>> wrote: >> >>> On Jun 1, 2016, at 12:53 PM, Paul Cantrell via swift-evolution >>> mailto:swift-evolution@swift.org>> wrote: >>> >>> This is the ca

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 > mailto:swift-evolution@swift.org>> wrote: > >> let _ = scaleAndCropImage(image: myImage, toSize: size, operation: .fill) >> >> You would not be able

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: > > The official way to build

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

This could be useful in categorizing and grouping within large enums ErrorType enums come to mind. Would there be any problem with making the subset more explicit? e.g. ``` swift enum Colors { case red, orange, yellow, green, blue, indigo, violet … } extension Colors {

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, gre

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 su

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 confusion with arr

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 and > ambiguity of ```Array`

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 that throws? >> >> Any comparison function that exami

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 th

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 > Author: Brent Royal-Gordon

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 t

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, it's just an opinion if 'wh

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 > mailto:swift-evolution@swift.org>> wrote: > Thanks for the laugh! > > The last week or so is actually stressing me out about the direction where > sw

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

I wonder how reactionary I will become when Swift is 5 years old :) I goggled a bit, to get some context on the use of “where” in mathematics. I was surprised to learn that and the use of “where” in mathematics is disliked by some mathematicians for its lack of precision: In his famous paper H

[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 und

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

> On Jun 26, 2016, at 4:25 PM, Russ Bishop wrote: > > >> On Jun 26, 2016, at 12:10 PM, Christopher Kornher via swift-evolution >> wrote: >> >> I may be too late for Swift 3, but I am planning to propose changes to the >> default behavior for cl

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 > wrote: > > On 06/26/2016 09:10 PM, Christopher Kornher via swift-evolution wrote: >> The core proposal: >> —— >> >> Closures capturing object references should automatically capture al

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 > part that I slightly disagree w

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

xen...@gmail.com>> wrote: >>> >>> >>>> On Jun 26, 2016, at 12:10 PM, Christopher Kornher via swift-evolution >>>> mailto:swift-evolution@swift.org>> wrote: >>>> >>>> I may be too late for Swift 3, but I am planning to p

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

`[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 >> capture since object is intuitively strongly captured the

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

iate the burden 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 &

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 >>> wrote: >>> On 06/26/2016 09:10 PM, Christopher Kornher via swift-evo

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 >>> mailto:swift-evolution@swift.org>> wrote: >>>

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 >> the Swift core team is strong enough so that I cannot

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 times without accessing the

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 sy

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, Slav

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] 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, C

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 > wrote: > > Requiring "override" when anything overrides a method defined in a protocol > extension shou

Re: [swift-evolution] Keyword for protocol conformance

olymorphism) 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 all. - Chris K >

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] 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 diction

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 >> > wrote: >>> >>> Everything *can* be bridged to an o

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 v

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

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 >>> mailto:swift-evolution@swift.org>> wrote: >>> >>> 1_ From what i understood from this discu

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

t; >> >> On Jan 24, 2017, at 3:10 PM, Christopher Kornher via swift-evolution >> mailto:swift-evolution@swift.org>> wrote: >> >> Your example is only has only one case, which is not typical. Perhaps I am >> missing something, but the only reason that I can

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

;> Sent from my iPhone >> >> On Jan 24, 2017, at 2:18 PM, Christopher Kornher via swift-evolution >> mailto:swift-evolution@swift.org>> wrote: >> >>> I agree that this rule would be consistent with the handing of Swift >>> function signatures,

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

h 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 > mailto:swift-evolution@swift.org>> wrote: >> On Jan 24, 2017, at 4:02 PM, Daniel Duan > <

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

gt; switch x { > case .anInt( let x ) : > break > > case .aString( let x ) : > break > } > } > > // Proposed: > > /* > enum theNewWay { > case a( value: Int ) : > case a( value: String ) : > } > > sw

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

"str") ) >> >> switch theCurrentWay { >> case .a( let x ) : >> switch x { >> case .anInt( let x ) : >> break >> >> case .aString( let x ) : >> break >> } >> } >> >&g

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 (SOM). As one of the developers

Re: [swift-evolution] Warning when omitting default case for imported enums

-1 This warning suggestion is of highly questionable value. Authors are free to add a default case or not, depending upon the nature of the enum and the logic to handle them. There is no “right” way to suggest, although for high-reliability code, default cases should usually be avoided in my opi

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 > mailto:swift-evolution@swift.org>> wrote: > >> +1, two small questions: >> >> - If two cases have the same base name but different full names, will >>

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

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

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 woul

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’ w