Re: [swift-evolution] [Review] SE 0192 - Non-Exhaustive Enums

> On Dec 21, 2017, at 8:17 PM, Jordan Rose wrote: > > > >> On Dec 20, 2017, at 12:54, Charlie Monroe > > wrote: >> >> I think that the main confusion here stems from the word library as we are >>

Re: [swift-evolution] [Review] SE 0192 - Non-Exhaustive Enums

I think that the main confusion here stems from the word library as we are addressing something that can be divided further (and this is IMHO as many macOS/iOS devs see it): - libraries that come with the OS - here, it absolutely makes sense to make the enums non-exhaustive as the apps are

Re: [swift-evolution] Add transformers to Codable

For me definitely +1 as it's getting near to what I need to call the Decoding usable. > On Dec 18, 2017, at 5:51 PM, Arsen Gasparyan via swift-evolution > wrote: > > Hello everyone, > > I’m suggesting to add a new way to encode/decode JSON properties for >

Re: [swift-evolution] Remove AnyObject Constraint for Objective-C Lightweight Generics

I find more limiting the ability not to declare @objc a property of a class that doesn't inherit from NSObject: class Foo { var x: Int = 0 } class Bar { var foo = Foo() // Why shouldn't we allow this @objc? } or protocol BarProtocol: AnyObject { func fooDidBar(_ foo:

Re: [swift-evolution] Enums and Source Compatibility

+1 for everything Vladimir says - which is why I'm pushing for switch! (just like try!, etc.) which would preserve current behavior. > On Oct 2, 2017, at 5:25 PM, Vladimir.S via swift-evolution > wrote: > > > Sorry to bother, but I still can't understand how the

Re: [swift-evolution] Problems with generics - should be fixed for Xcode 9?

This IMHO isn't a bug as the behavior is not completely defined. Joanna mentioned that Args is not generic, but it actually is, once you address it from global namespace - as it inherits the T type (while not used anywhere): NSStringFromClass(Event.Args.self) NSStringFromClass(Event.Args.self)

Re: [swift-evolution] Enums and Source Compatibility

> On Sep 6, 2017, at 8:50 AM, Rod Brown wrote: > > >> On 6 Sep 2017, at 2:31 pm, Charlie Monroe > > wrote: >>> On Sep 6, 2017, at 5:44 AM, Rod Brown via swift-evolution >>>

Re: [swift-evolution] Enums and Source Compatibility

> On Sep 6, 2017, at 5:44 AM, Rod Brown via swift-evolution > wrote: > >> >> On 6 Sep 2017, at 12:05 pm, Jarod Long via swift-evolution >> > wrote: >> >> From the perspective of primarily an app

Re: [swift-evolution] Beyond Typewriter-Styled Code in Swift, Adoption of Symbols

> On Aug 29, 2017, at 4:57 AM, John Pratt via swift-evolution > wrote: > > I sent a postal envelope to the Swift team with an article I wrote, arguing > that > symbols and graphics would push the programming language forward. > > Wouldn’t it be nice to have an

Re: [swift-evolution] typed throws

> On Aug 18, 2017, at 10:22 AM, John McCall wrote: > >> On Aug 18, 2017, at 3:28 AM, Charlie Monroe > > wrote: >>> On Aug 18, 2017, at 8:27 AM, John McCall via swift-evolution >>>

Re: [swift-evolution] typed throws

> On Aug 18, 2017, at 8:27 AM, John McCall via swift-evolution > wrote: > >> On Aug 18, 2017, at 12:58 AM, Chris Lattner via swift-evolution >> wrote: >> Splitting this off into its own thread: >> >>> On Aug 17, 2017, at 7:39 PM, Matthew

Re: [swift-evolution] "layoutSubviews()" and "layoutIfNeeded()" camel casing mistake

Hi Matthias, UIKit is not part of Swift - it's maintained by Apple. You may file a bug report at bugreport.apple.com , but my guess is that the chances that this will change are very slim. > On Aug 14, 2017, at 6:11 PM, Matthias Heymann via swift-evolution >

Re: [swift-evolution] Draft: Regular Expression in Swift

Hi Joshua, while this is a great idea, I'm afraid that this needs to be more thought-through. For example, which regex standards would you like to include? I really hope that Swift's regex support will not get stuck with plain ICU regexes like NSRegularExpression. I personally would love to

Re: [swift-evolution] Enums and Source Compatibility

Hi Jordan, let's say I'm writing my custom number formatter and I switch over NSNumberFormatterStyle (NumberFormatter.Style in Swift) - the question always is what to do with the default case - it's a value that I am not programmatically counting with. I would personally just put in fatalError

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

Hi, can you provide a usecase for this? I remember this being used in ObjC for +version, but I'm not sure anymore where I'd use this... BTW you don't need to stringify, use ObjectIdentifier (part of stdlib). > On Aug 9, 2017, at 12:54 PM, Mathew Huusko V via swift-evolution >

Re: [swift-evolution] Enums and Source Compatibility

While I agree with the entire idea and would actually use behavior like this in a few instances, I feel that in most cases, you would simply put default: fatalError() The huge downside of this is that you no longer get warned by the compiler that you are missing a case that was added

Re: [swift-evolution] [Pitch?] Way to declare a Swift Array that guarantees it can't be empty

I had a similar though some time ago (and even suggested it here) - as e.g. "Hello".components(separatedBy: "123") will always produce a non-empty array. Even "".components(separatedBy: "") is [""]. Which would allow e.g. first, last and some other members to loose the optionality - which

Re: [swift-evolution] ability to derive a class from a struct or other value type

What happens when you pass C somewhere where S is required? Is that an error? C() is S // Is this true or false? If it's true, then you can pass a mutable instance somewhere let is used, if it's false, then it is really confusing... > On Jun 21, 2017, at 8:29 PM, Mike Kluev via

Re: [swift-evolution] Revisiting SE-0110

> On Jun 15, 2017, at 6:01 AM, Chris Lattner via swift-evolution > wrote: > > >> On Jun 12, 2017, at 10:07 PM, Paul Cantrell wrote: >> >> What’s the status of this Chris’s double parens idea below? It garnered some >> positive responses, but

Re: [swift-evolution] Pitch: Limit typealias extensions to the typealias

> On Jun 9, 2017, at 6:12 PM, Jacob Williams wrote: > >> On Jun 9, 2017, at 9:53 AM, Charlie Monroe > > wrote: >> >> -1 - this would disallow e.g. to share UI code between iOS and macOS: >> >> #if os(iOS) >>

Re: [swift-evolution] Pitch: Limit typealias extensions to the typealias

-1 - this would disallow e.g. to share UI code between iOS and macOS: #if os(iOS) typealias XUView = UIView #else typealias XUView = NSView #endif extension XUView { ... } or with any similar compatibility typealiases. > On Jun 9, 2017, at 5:38 PM, Jacob Williams via

Re: [swift-evolution] Yet another fixed-size array spitball session

M, Jean-Daniel via swift-evolution >>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >>> >>>> >>>> Le 30 mai 2017 à 12:42, Charlie Monroe via swift-evolution >>>> <swift-evolution@swift.org <mailto:swift

Re: [swift-evolution] Yet another fixed-size array spitball session

There was someone a few weeks ago trying to port his Go game to Swift from (I believe) C++ and found out that the lack of fixed-size arrays was causing the move-computing algorithm to slow down significantly. This is due to fixed arrays being able to live on stack, while "normal Array" is

Re: [swift-evolution] [Pitch] Improve String Literals

AFAIK, there was an optimization for literal string concatenation that was broken in Xcode 8.3 (and the Swift version that comes with it), but is now fixed in master. https://bugs.swift.org/browse/SR-4348 > On May 16, 2017, at 10:47 PM, Ben Rimmington

Re: [swift-evolution] Swift's Optional Int as NSNumber in Objective-C

This is not much of an argument given that NSString is an object in ObjC (heap-allocated), String in Swift is an struct and also given that most NSNumber's nowadays are not really allocated, but just tagged pointers. Given that NSNumber is immutable, you get the value semantics anyway... > On

Re: [swift-evolution] Pitch: Automatically deriving Equatable/Hashable for more value types

lass to be hashable and equatable. It's all opt-in, there's no magic - I don't quite see the downside to it. > On Thu, May 4, 2017 at 23:45 Charlie Monroe via swift-evolution > <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: > I'm also leaning

Re: [swift-evolution] [Pitch] Remove type-inference for stored property

> On Apr 10, 2017, at 7:22 PM, Sean Heber via swift-evolution > wrote: > > >> On Apr 10, 2017, at 11:38 AM, Daniel Duan wrote: >> >> Using tools isn't a bad thing. Designing language assuming users are using >> tools with certain capability is

Re: [swift-evolution] [Pitch] Remove type-inference for stored property

+1 on removing the inference. I actually always declare the type for stored properties as well for better readability... > On Apr 9, 2017, at 5:28 PM, Lucas Neiva via swift-evolution > wrote: > > (Forgot CC. How's that Discord coming along? ) > > On 7 Apr 2017, at

Re: [swift-evolution] Enhancing access levels without breaking changes

This seems like a nice compromise, though it introduces a "horizontal" issue of indentation. Not a huge issue IMHO, though I think some people may see it as a downside. For me, it's +1, though. > On Apr 8, 2017, at 2:03 PM, Tino Heth via swift-evolution > wrote: >

Re: [swift-evolution] [Review] SE-0169: Improve Interaction Between private Declarations and Extensions

> On Apr 7, 2017, at 10:35 AM, Andrey Fidrya <a...@zabiyaka.com> wrote: > >> On 7 Apr 2017, at 07:57, Charlie Monroe via swift-evolution >> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >> >> -1 for reas

Re: [swift-evolution] [Review] SE-0169: Improve Interaction Between private Declarations and Extensions

-1 for reasons I've previously expressed in the discussions: - It encourages everything to be stuffed in one file. - It doesn't actually solve anything as the new private is very close to fileprivate, while abolishing private as truly scoped - which is a tool I use on regular basis. Simply as

Re: [swift-evolution] [Review] SE-0169: Improve Interaction Between private Declarations and Extensions

> On Apr 7, 2017, at 2:38 AM, Charles Srstka via swift-evolution > wrote: > >> On Apr 6, 2017, at 7:34 PM, Xiaodi Wu via swift-evolution >> > wrote: >> >> `private` works for extensions exactly how the

Re: [swift-evolution] 'Random' Improvements

> On Apr 5, 2017, at 7:00 PM, Peter Dillinger via swift-evolution > wrote: > > Haha: > >> https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170227/033482.html >> >> In general, I’d recommend against providing a default that we know won’t >> meet

Re: [swift-evolution] Does protocol support add to an object's size?

> On Apr 4, 2017, at 1:48 AM, Daryle Walker via swift-evolution > wrote: > > >> On Apr 3, 2017, at 4:33 PM, Jordan Rose > > wrote: >> >>> On Mar 31, 2017, at 09:39, Joe Groff via swift-evolution >>>

Re: [swift-evolution] Type-based ‘private’ access within a file

Exactly, this is pretty much what "protected" does - as much as there are voices against the idea to base access control based on the type, it is actually unevitable in the future IMHO anyway. I'd personally leave the private/fileprivate access levels as they are currently and would focus the

Re: [swift-evolution] multi-line string literals.

Thanks! Unfortunately, it didn't make it to Xcode 8.3... > On Apr 3, 2017, at 9:53 PM, Ben Rimmington wrote: > > (Merged 10 days ago) > >> On 3 Apr 2017, at 20:32, Charlie Monroe wrote: >> >>> On Apr 3, 2017, at 9:25 PM, Ben

Re: [swift-evolution] multi-line string literals.

> On Apr 3, 2017, at 9:25 PM, Ben Rimmington via swift-evolution > wrote: > > >> On 3 Apr 2017, at 17:55, Tony Allevato wrote: >> >> I just checked with -O and without and was surprised to find that `let x = >> "abc" + "def" + "ghi"` wasn't collapsed into a single

Re: [swift-evolution] Type-based ‘private’ access within a file

For me, -1 for two reasons: - Mainly, it still encourages stuffing everything into one file. I don't claim that having a 50-line files is the goal, but neither is having 1500 lines of code within one file. With less complex types, you're mostly fine with private/fileprivate as they are. For

Re: [swift-evolution] multi-line string literals.

Yes, but with ", you need to escape " occurrences - which is a fairly common character - I'd say more common than |. The trailing whitespace - why can't it just be included in the string automatically? Just for supporting comments? > On Apr 3, 2017, at 11:19 AM, Adrian Zubarev

Re: [swift-evolution] multi-line string literals.

While I long for multiline string literals, I'd also very like to see a different syntax as in many cases, these can be XML/HTML snippets and the use of quotes is ubiqituous. I'd very much like to see a variant where you can simply paste almost any string without escaping it. For example,

Re: [swift-evolution] Pitch: @objc attribute for top-level functions

+1, missed this on a number of occasions. > On Mar 31, 2017, at 5:00 PM, Charles Srstka via swift-evolution > wrote: > > MOTIVATION: > > Sometimes, it’s necessary to write a top-level C function in order to > interact with some C-based code. This can come up, for

Re: [swift-evolution] [Review] SE-0160: Limiting @objc inference

>> 1) New projects that are generally pure Swift or include some ObjC files as >> a bridge for interaction with C++ or some other stuff Swift can't currently >> do. In such case, the NSObject inheritence is usually due to the >> NSObjectProtocol requirement defined by most delegates in Cocoa

Re: [swift-evolution] Disallowing unreachable code

I'm personally -1 on this. I find it useful from time to time when debugging certain features - instead of commenting some part of code (and potentially forgetting to uncomment it), I wrap it in an "if false" statement - while I get a warning about the code not being reachable (or the if

Re: [swift-evolution] [Review] SE-0160: Limiting @objc inference

> On Mar 25, 2017, at 11:46 PM, Brent Royal-Gordon via swift-evolution > wrote: > >> On Mar 24, 2017, at 10:09 AM, Douglas Gregor wrote: >> >>> I'm actually not worried about methods so much as properties. KVC is >>> completely untyped on the

Re: [swift-evolution] [Pitch] Localized Swift Frameworks

I have to second (third) that. Also, cosider the fact that there were very passionate debates about naming certain methods to follow Swift 3 API guidelines. Who would localize the language? Enthusiasts? Who'd approve the localization? Would we allow anyone create his own? Imagine one school

Re: [swift-evolution] [Review] SE-0160: Limiting @objc inference

> >>> >>> On Mar 23, 2017, at 9:03 AM, Charlie Monroe <char...@charliemonroe.net >>> <mailto:char...@charliemonroe.net>> wrote: >>> >>>> >>>> On Mar 23, 2017, at 9:44 AM, Slava Pestov <spes...@apple.com >>>

Re: [swift-evolution] [Review] SE-0160: Limiting @objc inference

> On Mar 23, 2017, at 9:44 AM, Slava Pestov <spes...@apple.com> wrote: > >> >> On Mar 22, 2017, at 10:34 PM, Charlie Monroe via swift-evolution >> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >> >>> >>>

Re: [swift-evolution] [Proposal] [Discussion] Explicit Toll-Free Conversions

> On Mar 23, 2017, at 6:41 AM, Slava Pestov via swift-evolution > wrote: > > >> On Mar 22, 2017, at 10:35 PM, Robert Widmann via swift-evolution >> > wrote: >> >> Alternatives considered >> >> Do

Re: [swift-evolution] [Review] SE-0160: Limiting @objc inference

> On Mar 23, 2017, at 12:02 AM, Douglas Gregor via swift-evolution > wrote: > > >> On Mar 22, 2017, at 3:22 PM, Haravikk via swift-evolution >> wrote: >> >> >>> On 22 Mar 2017, at 06:03, Chris Lattner via swift-evolution >>>

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

> On Mar 21, 2017, at 6:43 PM, Jose Cheyo Jimenez <ch...@masters3d.com> wrote: > >> >> On Mar 21, 2017, at 1:10 AM, Charlie Monroe via swift-evolution >> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >> >>

Re: [swift-evolution] [Proposal] Factory Initializers

he cases of 0 elements when NSArray itself is > created we can avoid allocating, when the count is 1 and it is an NSArray > itself we can emit a more effecient storage, then when the type is immuatable > we can fall to CF, and finally in the abstract case we can store elements in > a buff

Re: [swift-evolution] [Proposal] Factory Initializers

I believe that this proposal is trying to solve something that can be solved by allowing assignment to self within convenience initializers. Unfortunately, even convenience initializers are allocating which makes it harder to achieve with backward compatibility - though I'm not entirely sure

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

> On Mar 21, 2017, at 8:26 AM, Slava Pestov <spes...@apple.com> wrote: > >> >> On Mar 20, 2017, at 11:07 PM, Charlie Monroe via swift-evolution >> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >> >> -1 on this as we

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

-1 on this as well for similar reasons. Places where I use fileprivate (aside from what was automatically migrated by Xcode) can be counted on fingers of one or two hands. I feel that this proposal is reverting something without offering an alternative solution. > On Mar 21, 2017, at 3:33

Re: [swift-evolution] Swift null safety questions

There are linters that will do this for you. In particular swiftlint has a force_unwrapping rule that you can enable. You can add a script build phase to your Xcode project and e.g. have it run only when archiving the project, etc. > On Mar 13, 2017, at 5:59 AM, Kenny Leung via swift-evolution

Re: [swift-evolution] [Pitch] Introducing `Unwrappable` protocol

> On Mar 8, 2017, at 2:33 AM, Guillaume Lessard via swift-evolution > wrote: > > >> On Mar 7, 2017, at 4:30 PM, Erica Sadun wrote: >> >> I deliberately moved it out of proposal format for that reason, so it could >> be discussed first. > >

Re: [swift-evolution] Random

While I am not against the idea, I believe that this is not as easy as one would think as everyone has a different understanding of the word "random" as most of random generators aren't "true" random generators. I think this would ideally require a new protocol RandomGenerator which would be

Re: [swift-evolution] Argument labels in callbacks

This was pointed out during the discussions surrounding this proposal and it was agreed that the type simplification was important. There were several suggestions how to bring this back using different features - e.g. compound names that would contain the labels. For example: let

Re: [swift-evolution] [Proposal Draft] Remove open Access Modifier

> On Feb 22, 2017, at 8:15 AM, Jean-Daniel via swift-evolution > wrote: > > >> Le 21 févr. 2017 à 17:19, Tino Heth via swift-evolution >> > a écrit : >> >> >>> I’ll concede that the proposal makes a

Re: [swift-evolution] final + lazy + fileprivate modifiers

-goal of Swift to actively support, by the addition >> of new features, all imaginable styles of organizing code. >> >> >> >> >> >> There is, objectively, an actual minimum number of access modifiers, which >> is two. Those two are: visible only

Re: [swift-evolution] final + lazy + fileprivate modifiers

> On Feb 17, 2017, at 9:29 AM, Slava Pestov <spes...@apple.com> wrote: > > >> On Feb 17, 2017, at 12:09 AM, Charlie Monroe via swift-evolution >> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >> >> True, what I meant w

Re: [swift-evolution] final + lazy + fileprivate modifiers

riable anyway. > On Fri, Feb 17, 2017 at 01:04 Charlie Monroe via swift-evolution > <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: > I'm aware of this, but that's fairly a long time ago - before Swift was open > source and had community feedback and befor

Re: [swift-evolution] final + lazy + fileprivate modifiers

7, at 7:47 AM, Jose Cheyo Jimenez <ch...@masters3d.com> wrote: > > https://developer.apple.com/swift/blog/?id=11 > <https://developer.apple.com/swift/blog/?id=11> > > > > On Feb 16, 2017, at 10:05 PM, Charlie Monroe via swift-evolution > <swift-evolution

Re: [swift-evolution] final + lazy + fileprivate modifiers

How about removing fileprivate, getting Swift 2 meaning of private (as most people here now suggest) and add additional @protected annotation for those who want a more fine-grained solution: @protected private - members accessable only from the class/struct/enum/... and their extensions within

Re: [swift-evolution] Pitch: Replacement for FileHandle

> On Feb 16, 2017, at 7:18 AM, Kevin Nattinger via swift-evolution > wrote: > > >> On Feb 15, 2017, at 3:45 PM, Tony Parker via swift-evolution >> > wrote: >> >>> >>> On Feb 15, 2017, at 2:25 PM,

Re: [swift-evolution] final + lazy + fileprivate modifiers

IMHO this sounds more like portected access that is crippled to the same file. I've personally argued with large files (500-1500 lines of code) and to be honest, I've tried breaking those up into several files each focusing on some aspect of the class and often ran into issues that the methods

Re: [swift-evolution] Pitch: Replacement for Process

> On Feb 14, 2017, at 4:37 PM, Charles Srstka via swift-evolution > wrote: > > MOTIVATION: > > In Swift 3, NSTask was renamed to Process, making it the de facto API for > spawning external tasks in Swift applications. Unfortunately, NSTask uses > Objective-C

Re: [swift-evolution] Simplifying Default Access Modifiers

-1. Aside from everyone being used to current behavior that I personally do find more logical since it prevents you from accidently exposing internal members via public API, the migrator won't have a choice but to slap "internal" everywhere during migration and like there are now projects full

Re: [swift-evolution] final + lazy + fileprivate modifiers

I've found the new private to be useful in various scenarious, where I nest classes/structs/enums inside each other. Without it, it's impossible to declare a member with the intend to be used privately by just that class. With the old private, it was not obvious whether a private member is

Re: [swift-evolution] final + lazy + fileprivate modifiers

> On Feb 12, 2017, at 5:19 PM, David Hart via swift-evolution > wrote: > > I was reading this nice listing of Swift keywords > (https://medium.com/the-traveled-ios-developers-guide/swift-keywords-v-3-0-1-f59783bf26c#.2s2yis3zh > >

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

> On Feb 7, 2017, at 7:54 PM, Tanner Nelson wrote: > > You'd still get the compiler helping you with new cases when working with > enums within your module. That's my point. My projects usually consist of several modules, as I've noted and I don't need to extend the enum

Re: [swift-evolution] Proposal to improve C pointer type import

> On Feb 7, 2017, at 5:56 PM, Florent Bruneau via swift-evolution > wrote: > > Anyone interested in that subject? > >> Le 31 janv. 2017 à 09:16, Florent Bruneau via swift-evolution >> a écrit : >> >> Hi swift-evolution, >> >> For the

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

-1 Not having the default case allows you to rely on the compiler to handle new options once they are added. Most of my apps consist nowadays from multiple modules and this would be massively inconvenient. The possible future features may be non-breaking if we consider that we will not allow

Re: [swift-evolution] Initializers

No, but you can declare it as: lazy var myStateDerivedProperty: Int = self.myStateManager.property Of course, there are still more complex scenarious that require IUOs. For example anything that gets loaded from the UI (currently marked as @IBOutlet). IUOs are definitely useful for items that

[swift-evolution] [Discussion] Protocol member deprecations

I am currently working on updating some protocol APIs in a framework that's shared among several of my projects. The issue here is that the protocol has an extension with default implementation. For example: protocol Foo { func doSomethingWithArray(_ arr: [String]) } extension Foo {

Re: [swift-evolution] for-else syntax

+1 This is generally why I've suggested about a week or two ago "NonEmptyArray" - an array that ensures it's not empty. Which is IMHO a sensible thing to use sometimes instead... > On Feb 1, 2017, at 8:38 PM, Sean Heber via swift-evolution > wrote: > > I usually

Re: [swift-evolution] Removing enumerated?

> On Jan 31, 2017, at 3:24 PM, Chris Eidhof via swift-evolution > wrote: > > Hey everyone, > > I've organized a number of Swift workshops over the last two years. There are > a couple of things that keep coming up, and a couple of mistakes that I see > people

Re: [swift-evolution] Warn about unused Optional.some(())

> On Jan 31, 2017, at 1:03 AM, Matthew Johnson via swift-evolution > wrote: > > > > Sent from my iPad > >> On Jan 30, 2017, at 5:25 PM, Slava Pestov via swift-evolution >> wrote: >> >> >>> On Jan 30, 2017, at 2:58 PM, Daniel Duan via

Re: [swift-evolution] Public struct init is unexpectedly internal

Unfortunately, I've come across this several times, but read here that it's intended behavior. If I remember correctly, it has something to do with the automatically generated initializers - it's implicitly internal so that you don't expose the initializer by mistake. The most annoying about

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

> On Jan 27, 2017, at 5:43 PM, Tino Heth <2...@gmx.de> wrote: > >>> - runtime libraries for Swift 4 >>> - all system frameworks will need to contain two variants - one compatible >>> with Swift 4 and one with Swift 5. This is IMHO absolutely unmaintainable >>> in the long run. For how long

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

> On Jan 27, 2017, at 11:35 AM, Tino Heth via swift-evolution > wrote: > > >> I don’t disagree with your overall point, but I do want to emphasize that >> forcing apps to bundle the stdlib and runtime is more than just suboptimal. > > Wouldn't it be possible to

Re: [swift-evolution] Strings in Swift 4

> On Jan 20, 2017, at 2:48 PM, Jonathan Hull via swift-evolution > wrote: > > ... > > • One thing that stood out was the interpolation format syntax, which seemed > a bit convoluted and difficult to parse: >> "Something with leading zeroes: \(x.format(fill: zero,

Re: [swift-evolution] Strings in Swift 4

> On Jan 20, 2017, at 12:55 PM, Maxim Veksler via swift-evolution > wrote: > > Please see discussion inline. > > On Fri, Jan 20, 2017 at 1:09 PM Jeremy Pereira > > > wrote: > > > On 20 Jan

Re: [swift-evolution] Closures from methods with default args

> On Jan 20, 2017, at 6:07 AM, David Sweeris <daveswee...@mac.com> wrote: > > > On Jan 9, 2017, at 02:13, Charlie Monroe via swift-evolution > <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: > >> I came across something

Re: [swift-evolution] [Idea] NonEmptyArray

> On Jan 17, 2017, at 2:14 PM, Haravikk <swift-evolut...@haravikk.me> wrote: > > >> On 17 Jan 2017, at 09:57, David Sweeris via swift-evolution >> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >> >> >> On J

[swift-evolution] [Idea] NonEmptyArray

I've come across multiple cases, where you simply know the array is never empty and hence the optionality on first, last and behavior of a few other members is slightly different. Also, there are cases where you want to declare that you shouldn't pass an empty array e.g. into an initializer. I

Re: [swift-evolution] [Proposal] Replace all Swift comments by end notes.

> On Jan 16, 2017, at 8:29 PM, Karl Wagner via swift-evolution > wrote: > > >> On 16 Jan 2017, at 20:26, David Sweeris via swift-evolution >> wrote: >> >> >> >>> On Jan 16, 2017, at 09:28, Amir Michail via swift-evolution >>>

Re: [swift-evolution] [Proposal] Replace all Swift comments by end notes.

> On Jan 16, 2017, at 5:38 PM, Amir Michail via swift-evolution > wrote: > > >> On Jan 16, 2017, at 10:55 AM, Tony Allevato wrote: >> >> As a general rule of thumb, changes to the language should not require the >> use of an IDE in order

Re: [swift-evolution] Allow ' in variable/constant names?

> On Jan 11, 2017, at 3:55 PM, Ben Rimmington wrote: > > >> On 11 Jan 2017, at 13:16, Charlie Monroe wrote: >> >> Instead, I'd personally love better character support in Swift in the future >> and allow a Character literals using ' - just like in C, except with

Re: [swift-evolution] Allow ' in variable/constant names?

-1. Why? Why not use foo2 instead? Is ' so much better? Instead, I'd personally love better character support in Swift in the future and allow a Character literals using ' - just like in C, except with Unicode support: let myChar = 'x' // Character let myChar2 = '∃' // Character let myChar3 =

[swift-evolution] Closures from methods with default args

I came across something that I'm not sure it's a bug or by design and if it's by design, whether this should be discussed here. Example: class Foo { init(number: Int) { /* ... */ } } let closure = Foo.init(number:) // (Int) -> Foo [1, 2, 3].map(closure) // [Foo, Foo, Foo] This works great

Re: [swift-evolution] [Proposal draft] Limiting @objc inference

I'm personally coming back and forth on this - my code is now 99% pure Swift, so I don't really need @objc declarations aside for: - CoreData - which is fairly obvious and @NSManaged will scream if the type isn't @objc-compatible - UI - and this is a big part. Unfortunately, I've relied on

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

You need to list all exception types that can be thrown. And when you call another throwing method without handling the exception, it needs to be listed as well. Which means that you can end up with a method that has a list of a dozen of exception names that can be thrown. > On Dec 27, 2016,

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

For me, handling Swift errors is a nightmare. You have no idea what to expect to be thrown. Some developers use NSError for use with Cocoa/UIKit (usually errors meant for user interaction), but some use enums that even can have a payload (extra info about the error). And you need to rely on the

Re: [swift-evolution] URL Literals

> On Dec 16, 2016, at 10:05 PM, Charles Srstka via swift-evolution > wrote: > >> On Dec 16, 2016, at 2:46 PM, Micah Hainline via swift-evolution >> wrote: >> >> I would like to be able to create a URL literal that is compile-time >>

Re: [swift-evolution] Nongeneric classes that inherit from generic classes not visible from objc

Hi Davide, AFAIK this is not (easily) possible (please, correct me someone if I'm wrong) since Swift's generics aren't "lightweight" as ObjC generics are. In ObjC, no matter what you use for the generics, you still have just 1 class that handles all call: @interface MyClass : NSObject @end

Re: [swift-evolution] Will Swift ever support optional methods without @objc?

> On Nov 16, 2016, at 3:52 PM, Karl via swift-evolution > wrote: > > >> On 16 Nov 2016, at 05:25, Shawn Erickson > > wrote: >> >> Again my point isn't worrying about point of calling out to the delegate but >>

Re: [swift-evolution] Will Swift ever support optional methods without @objc?

> On Nov 15, 2016, at 8:53 AM, Rick Mann <rm...@latencyzero.com> wrote: > > >> On Nov 14, 2016, at 22:51 , Charlie Monroe via swift-evolution >> <swift-evolution@swift.org> wrote: >> >> One major example is the NS/UITableViewDataSource or Delega

Re: [swift-evolution] Will Swift ever support optional methods without @objc?

One major example is the NS/UITableViewDataSource or Delegate - there are many many methods that you don't need to implement, hence are optional. But I think that this was partially solved by default implementation of protocol methods, which pretty much does what you want... > On Nov 15,

Re: [swift-evolution] [Proposal] Type Narrowing

> On Nov 7, 2016, at 8:03 PM, Haravikk wrote: > > >> On 7 Nov 2016, at 16:29, Charlie Monroe wrote: >> I'm simply worried a little about unwanted effects and additional compiler >> "cleverness". > > I don't believe there should be any;

  1   2   3   4   >