Re: [swift-evolution] [Proposal] Make non-escaping closures the default

> On Jun 9, 2016, at 3:43 PM, Jordan Rose via swift-evolution > wrote: > > I'm against this for library evolution reasons: if someone releases a version > of their library that has a non-escaping closure and later discovers it needs > to be escaping, they can't change it. > > IIRC the counter

Re: [swift-evolution] [Proposal] Make non-escaping closures the default

> On Jun 9, 2016, at 4:15 PM, Jordan Rose wrote: >> On Jun 9, 2016, at 16:10, John McCall > > wrote: >> >>> On Jun 9, 2016, at 3:43 PM, Jordan Rose via swift-evolution >>> mailto:swift-evolution@swift.org>> wrote: >>> >>> I'm against this for library evolution reasons

Re: [swift-evolution] [Pitch] "unavailable" members shouldn't need an impl

> On Jun 10, 2016, at 2:22 PM, Austin Zheng via swift-evolution > wrote: > > Hello swift-evolutioneers, > > Here's an idea. It's technically additive, but it's small and I think it fits > in well with Swift 3's goals, one of which is to establish API conventions. > > Right now, you can declar

Re: [swift-evolution] [Pitch] "unavailable" members shouldn't need an impl

> On Jun 12, 2016, at 9:08 PM, Charlie Monroe wrote: >> On Jun 11, 2016, at 3:51 AM, Andrew Bennett via swift-evolution >> mailto:swift-evolution@swift.org>> wrote: >> >> Unavailable doesn't mean un-callable. >> If you're marking an override or required initialiser as unavailable, it's >> still

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

> On Jun 20, 2016, at 9:57 AM, Dave Abrahams wrote: > on Thu Jun 09 2016, John McCall wrote: > >>> On Jun 9, 2016, at 12:59 PM, Dave Abrahams wrote: >>> on Thu Jun 09 2016, John McCall wrote: >>> > On Jun 9, 2016, at 9:04 AM, Dave Abrahams via swift-evolution > wrote: > on Wed J

Re: [swift-evolution] State of @noescape ?

> On Jun 20, 2016, at 10:55 AM, Антон Жилин via swift-evolution > wrote: > IIRC, there were at least the following counter-arguments: > 1. One must break API and ABI compatibility to add @escaping to an existing > function > 2. @nonescaping case is actually quite as common as @escaping > > Fran

Re: [swift-evolution] Prohibit invisible characters in identifier names

> On Jun 20, 2016, at 5:22 PM, Jordan Rose via swift-evolution > wrote: > IIRC, some languages require zero-width joiners (though not zero-width > spaces, which are distinct) to properly encode some of their characters. I'd > be very leery of having Swift land on a model where identifiers can b

Re: [swift-evolution] Prohibit invisible characters in identifier names

> On Jun 20, 2016, at 7:07 PM, Xiaodi Wu wrote: > On Mon, Jun 20, 2016 at 8:58 PM, John McCall via swift-evolution > mailto:swift-evolution@swift.org>> wrote: >> On Jun 20, 2016, at 5:22 PM, Jordan Rose via swift-evolution >> mailto:swift-evolution@swift.org>&g

Re: [swift-evolution] [Proposal] Make non-escaping closures the default

> On Jun 20, 2016, at 11:24 AM, Anton Zhilin via swift-evolution > wrote: > Trent Nadeau via swift-evolution writes: > >> https://github.com/tanadeau/swift-evolution/blob/make-noescape- > default/proposals/-make-noescape-default.md > > -1 from me. > > 1. One must break API and ABI compati

Re: [swift-evolution] [Pitch] Detecting and working with Optionals from Any

> On Jun 22, 2016, at 12:15 AM, L. Mihalkovic via swift-evolution > wrote: > > Func asOpt(v:Any) -> Optional { > If let val = v as? T { > Return val > } > Return nil > } > Regards > LM > (From mobile) This is just: return v as? T John. > > On Jun 22, 2016, at 7:11 AM, Charlie Mo

Re: [swift-evolution] Swift 3 vs "additive" proposals

> On Jun 22, 2016, at 7:59 AM, Erica Sadun via swift-evolution > wrote: >> On Jun 21, 2016, at 11:55 PM, Chris Lattner via swift-evolution >> mailto:swift-evolution@swift.org>> wrote: >> >> Hi Everyone, >> >> As I mentioned before, the Swift 3 release is winding down. There is still >> time

Re: [swift-evolution] Swift 3 vs "additive" proposals

> On Jun 22, 2016, at 8:17 AM, Matthew Johnson via swift-evolution > wrote: > >> Rationalizing base conversion protocol names. I personally don't have the >> heart to try to re-address the "LiteralConvertible" protocol naming thing >> again but this would be the last chance to do anything abo

Re: [swift-evolution] [Pitch] Detecting and working with Optionals from Any

> On Jun 22, 2016, at 9:12 AM, Charlie Monroe wrote: > > Please consider the following code: > > let myString: String? = "Hello" > let anyValue: Any = myString > let obj: AnyObject? = anyValue as? AnyObject // nil, since it's > Optional, String being struct, >

Re: [swift-evolution] Swift 3 vs "additive" proposals

> On Jun 22, 2016, at 9:09 AM, Matthew Johnson wrote: >> On Jun 22, 2016, at 10:59 AM, John McCall > > wrote: >> >> >>> On Jun 22, 2016, at 8:17 AM, Matthew Johnson via swift-evolution >>> mailto:swift-evolution@swift.org>> wrote: >>> Rationalizing base conversi

Re: [swift-evolution] Swift 3 vs "additive" proposals

> On Jun 22, 2016, at 9:15 AM, Javier Soto wrote: > How would we evaluate the proposal to introduce the "sealed" specifier for > classes (open within module, final outside of module) and default to that, in > terms of source-code compatibility? > From my point of view it might be easier to do b

Re: [swift-evolution] Swift 3 vs "additive" proposals

no, there would not. John. > >> On Jun 22, 2016, at 9:48 AM, John McCall via swift-evolution >> mailto:swift-evolution@swift.org>> wrote: >> >>> On Jun 22, 2016, at 9:15 AM, Javier Soto >> <mailto:javier@gmail.com>> wrote: >&g

Re: [swift-evolution] Swift 3 vs "additive" proposals

> On Jun 22, 2016, at 1:38 PM, Matthew Johnson wrote: >> On Jun 22, 2016, at 11:48 AM, John McCall > > wrote: >> >>> On Jun 22, 2016, at 9:15 AM, Javier Soto >> > wrote: >>> How would we evaluate the proposal to introduce the "sealed" specif

Re: [swift-evolution] Add an implicit return nil if function reaches end before return explicitly called

> On Jun 22, 2016, at 1:36 PM, James Froggatt via swift-evolution > wrote: > Welcome, Logan. > > Functions currently return the empty tuple, ‘()’, by default. Void is a > typealias to the empty tuple type. It is also possible to write ‘return ()’ > explicitly, rather than just ‘return’. (This

Re: [swift-evolution] Swift 3 vs "additive" proposals

> On Jun 22, 2016, at 2:42 PM, Matthew Johnson wrote: >> On Jun 22, 2016, at 4:29 PM, Javier Soto > > wrote: >> >> I'll work on a formal proposal for sealed by default :) > > I have already been planning a proposal for sealed (in general) but didn’t > think it fit w

Re: [swift-evolution] [Discussion] A Problem With SE-0025?

> On Jun 23, 2016, at 6:03 PM, Jordan Rose via swift-evolution > wrote: >> On Jun 15, 2016, at 18:47, Charles Srstka via swift-evolution >> mailto:swift-evolution@swift.org>> wrote: >> >>> On Jun 15, 2016, at 8:36 PM, Robert Widmann >> > wrote: >>> >>> Point 3

Re: [swift-evolution] [Draft] UnsafeRawPointer API

> On Jun 24, 2016, at 10:58 AM, Andrew Trick via swift-evolution > wrote: >> On Jun 24, 2016, at 8:19 AM, Matthew Johnson > > wrote: >> >> Andrew, thank you for working on this. The latest draft is much improved! >> >> I have a few questions. >> >> Why do you re

Re: [swift-evolution] [Returned for revision] SE-0077: Improved operator declarations

> On Jun 25, 2016, at 10:57 AM, Anton Zhilin via swift-evolution > wrote: > I replaced `precedencegroup` with `precedence` and added `Precedence` > suffix to all precedence group names. See: > > https://github.com/Anton3/swift-evolution/blob/fix-operator- > precedence/proposals/0077-operator-pr

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

> On Jun 28, 2016, at 8:09 AM, Javier Soto via swift-evolution > wrote: > IMO the issue with the argument that we wouldn't be able to "monkey patch" > things on sealed classes is that that is already the nature of Swift. The > designer of an API can choose to use structs instead of classes, and

Re: [swift-evolution] [Returned for revision] SE-0077: Improved operator declarations

> On Jun 28, 2016, at 9:12 AM, L. Mihalkovic > wrote: > > Question inline > Regards > LM > (From mobile) > On Jun 28, 2016, at 1:01 AM, John McCall via swift-evolution > wrote: > >>> On Jun 25, 2016, at 10:57 AM, Anton Zhilin via swift-evolution >

Re: [swift-evolution] [Discussion] A Problem With SE-0025?

> On Jun 28, 2016, at 9:16 AM, Jordan Rose wrote: >> On Jun 28, 2016, at 01:14, David Hart > > wrote: >> >> Hello everybody, >> >> I tried using the access rules defined in SE-0025 in some code of mine to >> see what effect it would have. I came out of the experiment m

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

> 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 believe that this has a > chance of ever being implemented at all :) > > Why do

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

> On Jun 28, 2016, at 2:20 PM, Christopher Kornher wrote: >> On Jun 28, 2016, at 2:31 PM, John McCall via swift-evolution >> mailto:swift-evolution@swift.org>> wrote: >> >>> On Jun 28, 2016, at 12:39 PM, Michael Peternell via swift-evolution >>

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

> On Jun 28, 2016, at 4:01 PM, Michael Peternell > wrote: >> Am 29.06.2016 um 00:32 schrieb John McCall : >> >> The decision to make class methods polymorphic by default was always >> premised on being able to undo that in obvious cases where methods are never >> overridden. Making a class pu

Re: [swift-evolution] TreeLiteralConvertible

> On Apr 14, 2016, at 12:01 PM, Milos Rankovic via swift-evolution > wrote: > Hi Andrey and Laurent, > >> On 14 Apr 2016, at 19:23, Andrey Tarantsov > > wrote: >> >> Can you please give us a few real-world examples where initializing a >> nontrivial tree-like data

Re: [swift-evolution] TreeLiteralConvertible

> On Apr 14, 2016, at 1:34 PM, Milos Rankovic > wrote: > Hi John, > >> On 14 Apr 2016, at 21:09, John McCall > > wrote: >> >> I mean, you could just make your Tree type implement all the individual >> literal-convertible protocols. > > It does sound like something l

Re: [swift-evolution] TreeLiteralConvertible

> On Apr 14, 2016, at 2:03 PM, Milos Rankovic > wrote: >> On 14 Apr 2016, at 21:36, John McCall > > wrote: >> >> No, you just need Tree to conform to both ArrayLiteralConvertible and >> IntegerLiteralConvertible, and it implements the latter by building a Value >> ou

Re: [swift-evolution] TreeLiteralConvertible

> On Apr 14, 2016, at 2:20 PM, Brent Royal-Gordon > wrote: >> No, you just need Tree to conform to both ArrayLiteralConvertible and >> IntegerLiteralConvertible, and it implements the latter by building a Value >> out of it. > > That not only doesn't work if your type isn't a LiteralConvertibl

Re: [swift-evolution] TreeLiteralConvertible

> On Apr 14, 2016, at 2:56 PM, Milos Rankovic > wrote: > Hi John and Brent, > >> On 14 Apr 2016, at 22:22, John McCall > > wrote: >> >> multiple-conformance idea doesn't work > > > The idea is not multiple-conformance (or overloading), but multiple (two) > initial

Re: [swift-evolution] [pitch] Eliminate the "T1 -> T2" syntax, require "(T1) -> T2"

> On Apr 14, 2016, at 9:57 PM, Chris Lattner via swift-evolution > wrote: > > We currently accept function type syntax without parentheses, like: > > Int -> Float > String -> () > > etc. The original rationale aligned with the fact that we wanted to treat > all functions as taking a single

Re: [swift-evolution] [pitch] Eliminate the "T1 -> T2" syntax, require "(T1) -> T2"

> On Apr 14, 2016, at 10:28 PM, Chris Lattner wrote: > > On Apr 14, 2016, at 10:21 PM, John McCall wrote: >> >>> On Apr 14, 2016, at 9:57 PM, Chris Lattner via swift-evolution >>> wrote: >>> >>> We currently accept function type syntax without parentheses, like: > >> To me, the unparenthesi

Re: [swift-evolution] [pitch] Eliminate the "T1 -> T2" syntax, require "(T1) -> T2"

> On Apr 14, 2016, at 10:50 PM, Chris Lattner wrote: > On Apr 14, 2016, at 10:40 PM, John McCall wrote: To me, the unparenthesized style suggests that the input and output are peers, which feels more natural for the sort of value-to-value transform/predicate where this most commo

Re: [swift-evolution] TreeLiteralConvertible

> On Apr 15, 2016, at 1:29 AM, Milos Rankovic > wrote: >> On 15 Apr 2016, at 03:22, John McCall > > wrote: >> Your JSON literal example is already pretty well modeled by simply making a >> JSONValue type that conforms to all the literal protocols. It is completely >

Re: [swift-evolution] [pitch] Eliminate the "T1 -> T2" syntax, require "(T1) -> T2"

> On Apr 15, 2016, at 10:41 AM, Joe Groff wrote: >> On Apr 15, 2016, at 8:29 AM, John McCall via swift-evolution >> wrote: >> >>> On Apr 14, 2016, at 10:50 PM, Chris Lattner wrote: >>> On Apr 14, 2016, at 10:40 PM, John McCall wrote: >>>>&g

Re: [swift-evolution] [pitch] Eliminate the "T1 -> T2" syntax, require "(T1) -> T2"

> On Apr 15, 2016, at 2:47 PM, Joe Groff wrote: >> On Apr 15, 2016, at 11:43 AM, John McCall wrote: >>> On Apr 15, 2016, at 10:41 AM, Joe Groff wrote: >>>> On Apr 15, 2016, at 8:29 AM, John McCall via swift-evolution >>>> wrote: >>>> &g

Re: [swift-evolution] [swift-dev] Lazy var and deinit

> On Apr 21, 2016, at 2:29 AM, Alexandr.moq via swift-dev > wrote: > Should SWIFT initialize a variable in deinit method if it has not been > initialized? > > For example: > ```swift > class A { > lazy var b = B() > deinit { > b.clean() > } > } > var a = A() >

Re: [swift-evolution] ValueEnumerable protocol with derived implementation for enums

> On Apr 22, 2016, at 10:18 PM, Jacob Bandes-Storch wrote: > On Sat, Apr 16, 2016 at 5:20 AM, plx via swift-evolution > mailto:swift-evolution@swift.org>> wrote: > > > My 2c is that if this is to go in the standard library, it should be done > “right”, which would be more like this version of

Re: [swift-evolution] ValueEnumerable protocol with derived implementation for enums

> On Apr 22, 2016, at 11:11 PM, Jacob Bandes-Storch wrote: > On Fri, Apr 22, 2016 at 10:50 PM, John McCall > wrote: > > I have not been following this discussion, but I would be extremely antsy > about guaranteeing any particular representation for the set of values.

Re: [swift-evolution] ValueEnumerable protocol with derived implementation for enums

> On Apr 22, 2016, at 11:48 PM, Jacob Bandes-Storch wrote: > On Fri, Apr 22, 2016 at 11:34 PM, John McCall > wrote: >> On Apr 22, 2016, at 11:11 PM, Jacob Bandes-Storch > > wrote: >> On Fri, Apr 22, 2016 at 10:50 PM, John McCall >

Re: [swift-evolution] Mutability for Foundation types in Swift

> On Apr 25, 2016, at 10:32 AM, Douglas Gregor via swift-evolution > wrote: >> On Apr 25, 2016, at 9:20 AM, Tony Parker via swift-evolution >> mailto:swift-evolution@swift.org>> wrote: >> >> Hi Brent, >> >> Thanks for your feedback! You’ve got some great questions below, I’ll try to >> answer

Re: [swift-evolution] [swift-dev] [Compiler] Help IR gen in targetting MSVC

> On Apr 26, 2016, at 1:03 PM, Sangjin Han wrote: > The problem can be solved by modifying that code. Thanks you. I thought that > code will affect only to the CLong type not Int. It changes what 'long' gets imported as. If there's a Windows API defined using 'long' (rather than some more mean

Re: [swift-evolution] [swift-dev] [Compiler] Help IR gen in targetting MSVC

> On Apr 26, 2016, at 1:39 PM, Joe Groff wrote: >> On Apr 26, 2016, at 1:24 PM, John McCall via swift-evolution >> wrote: >> >>> On Apr 26, 2016, at 1:03 PM, Sangjin Han wrote: >>> The problem can be solved by modifying that code. Thanks you. I thought

Re: [swift-evolution] [Review] SE-0017: Change Unmanaged to use UnsafePointer

> On Apr 28, 2016, at 11:10 AM, Chris Lattner via swift-evolution > wrote: > Hello Swift community, > > The review of "SE-0017: Change Unmanaged to use UnsafePointer" begins now and > runs through May 3. The proposal is available here: > > > https://github.com/apple/swift-evolution/blob

Re: [swift-evolution] Should we rename "class" when referring to protocol conformance?

> On May 2, 2016, at 6:55 AM, David Sweeris via swift-evolution > wrote: > I was just thinking that: > protocol Foo : reference {} > might be more to the point than: > protocol Foo : class {} > > I know that it’s currently a moot point because classes are the only* > reference-semantics type of

Re: [swift-evolution] [Idea] Remove optional pattern binding

> On May 2, 2016, at 9:39 AM, Jordan Rose via swift-evolution > wrote: >> On May 1, 2016, at 13:09, Brent Royal-Gordon via swift-evolution >> wrote: >> >>> Pattern binding for optionals will look like: >>> >>> if let x? = y { ... } >> >> I suggested precisely this in February. The core team

Re: [swift-evolution] [Idea] Remove optional pattern binding

> On May 2, 2016, at 11:47 AM, Chris Lattner wrote: > On May 2, 2016, at 11:12 AM, John McCall via swift-evolution > wrote: >> >>> On May 2, 2016, at 9:39 AM, Jordan Rose via swift-evolution >>> wrote: >>>> On May 1, 2016, at 13:09, Brent

Re: [swift-evolution] [Idea] Remove optional pattern binding

<mailto:clatt...@apple.com>> wrote: > > On May 2, 2016, at 11:12 AM, John McCall via swift-evolution > > mailto:swift-evolution@swift.org>> wrote: > >> > >>> On May 2, 2016, at 9:39 AM, Jordan Rose via swift-evolution > >>> mailto:swift-

Re: [swift-evolution] [Idea] Remove optional pattern binding

> On May 2, 2016, at 2:35 PM, Chris Lattner wrote: >> On May 2, 2016, at 1:19 PM, John McCall > > wrote: >> >>> On May 2, 2016, at 12:13 PM, Антон Жилин >> > wrote: >>> I absolutely agree with John, and I think, we should push this through

Re: [swift-evolution] [Idea] Remove optional pattern binding

> On May 2, 2016, at 2:17 PM, David Hart wrote: > John, > > When the core team implemented the `if let x? = y` experiment and later > backtracked, were you enthusiastic about it? The way Jordan puts it "Yeah, as > nice as it sounds, it didn’t work out in practice.” sounds very definite, as > i

Re: [swift-evolution] #if os(Windows) and MSVC/Cygwin Compatibility

> On May 3, 2016, at 9:22 AM, Michael Buckley via swift-evolution > wrote: > I may be fundamentally misunderstanding the Windows Subsystem for Linux, but > I believe it just provides binary compatibility for Linux x86_64 command-line > tools, but doesn't quite implement enough of the Linux sysc

Re: [swift-evolution] #if os(Windows) and MSVC/Cygwin Compatibility

> On May 3, 2016, at 12:15 PM, Joe Groff via swift-evolution > wrote: >> On May 3, 2016, at 11:43 AM, Jordan Rose via swift-evolution >> wrote: >> >> We’ve had this kind of thing come up before, too, with the >> Linux/FreeBSD/Android group vs. the OSX/iOS/watchOS/tvOS group, or with >> 32-bi

[swift-evolution] [Review] Amendment: SE-0039: Moderning Playground Literals

Original proposal: https://github.com/apple/swift-evolution/blob/master/proposals/0039-playgroundliterals.md Pull request for modification: https://github.com/apple/swift-evolution/pull/324

Re: [swift-evolution] Winding down the Swift 3 release

> On May 16, 2016, at 2:06 PM, Chris Lattner via swift-evolution > wrote: >> On May 16, 2016, at 11:33 AM, Tim Hawkins > > wrote: >> >> At what point would you consider the Linux product to be viable for >> production server side application development. Do you th

Re: [swift-evolution] Removing "_ in" from empty closures

> On May 14, 2016, at 10:16 PM, Chris Lattner via swift-evolution > wrote: > On May 13, 2016, at 9:16 AM, Joe Groff via swift-evolution > wrote: >>> This encourages the use of empty closures over optional closures, which I >>> think is open for debate. In general I try to avoid optionals when

Re: [swift-evolution] Make access control private by default.

> On May 15, 2016, at 12:15 PM, Knut Lorenzen via swift-evolution > wrote: > I think internal as default is bad, because it discourages encapsulation. > > Building scalable software components relies on hiding implementation details > to create layers of abstraction. It’s a fundamental principl

Re: [swift-evolution] [Pitch] Nesting types without nesting in place (additional)

> On May 18, 2016, at 11:00 AM, Adrian Zubarev via swift-evolution > wrote: > May I revive this idea for a discussion. > > When I posted this first I didn’t thought about creating these nested types > inside extensions. > > So basically I could do this (over and over): > > extension SomeClas

Re: [swift-evolution] Removing "_ in" from empty closures

> On May 19, 2016, at 4:13 PM, Jordan Rose via swift-evolution > wrote: >> On May 14, 2016, at 22:16, Chris Lattner via swift-evolution >> mailto:swift-evolution@swift.org>> wrote: >> >> On May 13, 2016, at 9:16 AM, Joe Groff via swift-evolution >> mailto:swift-evolution@swift.org>> wrote: >>>

Re: [swift-evolution] Removing "_ in" from empty closures

> On May 20, 2016, at 10:37 AM, Erica Sadun via swift-evolution > wrote: >> On May 20, 2016, at 11:34 AM, Jordan Rose via swift-evolution >> mailto:swift-evolution@swift.org>> wrote: >>> On May 20, 2016, at 10:25, John McCall >> > wrote: >>> On May 19, 2016, at 4

Re: [swift-evolution] [Review] SE-0077: Improved operator declarations

> On May 17, 2016, at 8:30 PM, Chris Lattner via swift-evolution > wrote: > Hello Swift community, > > The review of "SE-0077: Improved operator declarations" begins now and runs > through May 23. The proposal is available here: > > > https://github.com/apple/swift-evolution/blob/master

Re: [swift-evolution] Removing "_ in" from empty closures

> On May 20, 2016, at 10:46 AM, Erica Sadun wrote: >> On May 20, 2016, at 11:42 AM, John McCall > > wrote: >> >>> On May 20, 2016, at 10:37 AM, Erica Sadun via swift-evolution >>> mailto:swift-evolution@swift.org>> wrote: On May 20, 2016, at 11:34 AM, Jordan Rose

Re: [swift-evolution] [Review] SE-0077: Improved operator declarations

> On May 20, 2016, at 1:25 PM, Антон Жилин wrote: > Inline: > > 2016-05-20 20:58 GMT+03:00 John McCall >: > The transitivity rule plus the ability to define precedence relationships in > both directions on a new precedence group allows a new precedence group to > cre

Re: [swift-evolution] Make access control private by default.

> On May 23, 2016, at 3:43 PM, Leonardo Pessoa via swift-evolution > wrote: > > I was just about to mention this too. I think it's interesting that > one can write a simple application in Swift without having to worry > (much) about visibility of elements. Please note I'm talking about > applic

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

> On Jun 29, 2016, at 11:11 AM, Xiaodi Wu via swift-evolution > wrote: > Do we really need a new keyword? Since we already have syntax like > `internal(set)` couldn't we do `internal(unsealed)`, etc. The spelling is definitely up for debate. I remember that Chris in particular wasn't happy wi

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

> On Jun 29, 2016, at 11:16 AM, Michael Peternell via swift-evolution > wrote: > Do you mean `public(unsealed)`? Because `internal(unsealed)` doesn't really > make sense. `internal` declarations are always sealed. Right. If "sealed" is the default behavior for public classes and methods — and

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

> On Jun 29, 2016, at 11:39 AM, Vladimir.S wrote: > How about `public(extensible)` ? Hmm. I started to work out an example with these as separate modifiers, and I think I understand the need to combine them in some way. I wonder if just "extensible" would be good enough. It is a term that's u

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

ch of a problem. Do you really anticipate writing so many Swift libraries with public classes? John. > > -Michael > >> Am 29.06.2016 um 20:39 schrieb Vladimir.S via swift-evolution >> : >> >> How about `public(extensible)` ? >> >> On 29.06.2016 21:

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

>>>> `unsealed` I can never know: "did this developer intend me to be able to >>>> subclass this class? or did he just not want to restrict me >>>> unnecessarily?" The documenting aspect of `unsealed` is so small. >>>> >>>> A

Re: [swift-evolution] [Discussion] A Problem With SE-0025?

> On Jun 29, 2016, at 7:07 PM, Xiaodi Wu via swift-evolution > wrote: > > [Resending with fewer recipients] > > On Wed, Jun 29, 2016 at 8:55 PM, Jordan Rose > wrote: > Updated in https://github.com/apple/swift-evolution/pull/396 >

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

> On Jun 29, 2016, at 10:27 PM, L. Mihalkovic > wrote: > > On Jun 29, 2016, at 9:54 PM, John McCall via swift-evolution > wrote: > >>> On Jun 29, 2016, at 12:05 PM, Michael Peternell >>> wrote: >>> I'm still unhappy about this "s

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

> On Jun 29, 2016, at 10:17 PM, L. Mihalkovic > wrote: >> On Jun 29, 2016, at 8:39 PM, Vladimir.S via swift-evolution >> wrote: >> >> How about `public(extensible)` ? >> >> On 29.06.2016 21:32, John McCall via swift-evolution wrote: >>>&g

Re: [swift-evolution] [Discussion] A Problem With SE-0025?

> On Jun 30, 2016, at 9:19 AM, Jordan Rose wrote: >> On Jun 29, 2016, at 23:34, John McCall > > wrote: >> >>> On Jun 29, 2016, at 7:07 PM, Xiaodi Wu via swift-evolution >>> mailto:swift-evolution@swift.org>> wrote: >>> >>> [Resending with fewer recipients] >>> >>> On

Re: [swift-evolution] [Review] SE-0077 v2: Improved operator declarations

> On Jun 30, 2016, at 2:34 AM, Anton Zhilin via swift-evolution > wrote: > https://github.com/apple/swift-evolution/blob/master/proposals > /0077-operator-precedence.md > > Idea #1 > > There is a high chance that 'higherThan'/'lowerThan' names will be > chosen. I still see a problem with that.

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

> On Jun 30, 2016, at 11:07 AM, Andrew Trick wrote: >> On Jun 30, 2016, at 1:21 AM, John McCall via swift-evolution >> wrote: >> >>> On Jun 29, 2016, at 10:17 PM, L. Mihalkovic >>> wrote: >>>> On Jun 29, 2016, at 8:39 PM, Vladimir.S via

Re: [swift-evolution] [Review] SE-0077 v2: Improved operator declarations

> On Jun 30, 2016, at 11:25 AM, Matthew Johnson wrote: > On Jun 30, 2016, at 1:08 PM, John McCall via swift-evolution > wrote: > >>> On Jun 30, 2016, at 2:34 AM, Anton Zhilin via swift-evolution >>> wrote: >>> https://github.com/apple/swift-evolution/b

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

> On Jun 29, 2016, at 1:33 PM, Xiaodi Wu wrote: > On Wed, Jun 29, 2016 at 2:54 PM, John McCall via swift-evolution > mailto:swift-evolution@swift.org>> wrote: > > On Jun 29, 2016, at 11:39 AM, Vladimir.S > <mailto:sva...@gmail.com>> wrote: > > How ab

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

> On Jun 30, 2016, at 1:44 PM, Xiaodi Wu wrote: > On Thu, Jun 30, 2016 at 3:36 PM, John McCall <mailto:rjmcc...@apple.com>> wrote: >> On Jun 29, 2016, at 1:33 PM, Xiaodi Wu > <mailto:xiaodi...@gmail.com>> wrote: >> On Wed, Jun 29, 2016 at 2:54 PM, John McCa

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

ll > <mailto:rjmcc...@apple.com>> wrote: >>> On Jun 29, 2016, at 1:33 PM, Xiaodi Wu >> <mailto:xiaodi...@gmail.com>> wrote: >>> On Wed, Jun 29, 2016 at 2:54 PM, John McCall via swift-evolution >>> mailto:swift-evolution@swift.org>> wro

Re: [swift-evolution] [Review] SE-0101: Rename sizeof and related functions to comply with API Guidelines

> On Jun 30, 2016, at 6:12 PM, Dave Abrahams via swift-evolution > wrote: > on Thu Jun 30 2016, Matthew Johnson > wrote: > >> Sent from my iPad >> >>> On Jun 30, 2016, at 6:59 PM, Erica Sadun via swift-evolution >>> wrote: >>> >>> > On Jun 30, 2016, a

Re: [swift-evolution] [Review] SE-0101: Rename sizeof and related functions to comply with API Guidelines

> On Jun 30, 2016, at 10:41 PM, Xiaodi Wu wrote: > On Fri, Jul 1, 2016 at 12:03 AM, Dave Abrahams via swift-evolution > mailto:swift-evolution@swift.org>> wrote: > > on Thu Jun 30 2016, John McCall wrote: > > >> On Jun 30, 2016, at 6:12 PM, Dave Abrahams via swift-evolution > >> mailto:swift-

Re: [swift-evolution] [Review] SE-0101: Rename sizeof and related functions to comply with API Guidelines

> On Jul 1, 2016, at 8:57 AM, John McCall via swift-evolution > wrote: >> On Jun 30, 2016, at 10:41 PM, Xiaodi Wu > <mailto:xiaodi...@gmail.com>> wrote: >> On Fri, Jul 1, 2016 at 12:03 AM, Dave Abrahams via swift-evolution >> mailto:swift-evolution@swift.or

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

> On Jul 1, 2016, at 2:08 AM, Brent Royal-Gordon wrote: >> That starts to look an awful lot like a fifth access level just for classes >> (I know you're not proposing one, but it could start to look that way to a >> user). > > You know, it *could* be. > > Suppose that, in `internal` scope, you

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

> On Jul 1, 2016, at 12:23 AM, Xiaodi Wu wrote: > That starts to look an awful lot like a fifth access level just for classes > (I know you're not proposing one, but it could start to look that way to a > user). I think there's much to be said for having the word public in front of > things tha

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

ossible to. >> >> opened class MyViewController: UIViewController { >> opened func displayMe(_ me: person) { … } >> } >> >> On 1 July 2016 at 13:47, John McCall via swift-evolution >> wrote: >>> On Jul 1, 2016, at 12:23 AM, Xiaodi Wu wr

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

> On Jul 2, 2016, at 10:58 AM, L. Mihalkovic > wrote: > > > Regards > LM > (From mobile) > > On Jun 30, 2016, at 9:12 AM, John McCall <mailto:rjmcc...@apple.com>> wrote: > >>> On Jun 29, 2016, at 10:27 PM, L. Mihalkovic >>> wro

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0117: Default classes to be non-subclassable publicly

> On Jul 5, 2016, at 6:45 PM, Brent Royal-Gordon via swift-evolution > wrote: > >> * What is your evaluation of the proposal? > > I think it's ultimately a good idea. Being noncommittal about > subclassability/overridability—and thus forbidding it in public scope, but > not making any p

Re: [swift-evolution] Public classes with private superclass

> On Jul 5, 2016, at 6:48 PM, Karl via swift-evolution > wrote: >> On 5 Jul 2016, at 08:49, Andre via swift-evolution >> wrote: >> >> Personally, it's perhaps more of an "aesthetic" thing I suppose but I would >> definitely prefer that my internal classes stay internal even if there is a >>

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0117: Default classes to be non-subclassable publicly

> On Jul 5, 2016, at 10:56 PM, Chris Lattner wrote: >> On Jul 5, 2016, at 6:53 PM, John McCall via swift-evolution >> wrote: >> >>> >>> I think Kevin Lundberg is right to worry about testability, but I don't >>> think that has to prevent t

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0117: Default classes to be non-subclassable publicly

ould be treating their external dependencies as black boxes and use their normal API. John. > > > On 7/5/2016 9:53 PM, John McCall via swift-evolution wrote: >>> On Jul 5, 2016, at 6:45 PM, Brent Royal-Gordon via swift-evolution >>> wrote: >>> >>>

Re: [swift-evolution] [Review] SE-0117: Default classes to be non-subclassable publicly

> On Jul 6, 2016, at 12:35 PM, Leonardo Pessoa via swift-evolution > wrote: > Intention. > > IMO, intention may lead to more secure systems (and libraries). By > having to explicitly final everything I have to choose with parts of > my class/library would be locked and have to worry and check if

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0117: Default classes to be non-subclassable publicly

> On Jul 6, 2016, at 1:41 PM, Goffredo Marocchi via swift-evolution > wrote: > Sent from my iPhone > >> On 6 Jul 2016, at 21:22, Paul Cantrell via swift-evolution >> wrote: >> >> In the era of increased open sourcing, easy forking, and more >> community-driven development, this concern is le

Re: [swift-evolution] [Review] SE-0077 v2: Improved operator declarations

> On Jul 7, 2016, at 9:23 AM, Dmitri Gribenko via swift-evolution > wrote: > > Proposal link: > > > > https://github.com/apple/swift-evolution/blob/master/proposals/0077-operator-precedence.md > > > > >

Re: [swift-evolution] [Review] SE-0117: Default classes to be non-subclassable publicly

n Jul 7, 2016, at 9:39 AM, Goffredo Marocchi via swift-evolution wrote: > I disagree that a stable for over 30 years of every OOP language that I know > is equivalent to lack of care for good library design, but if we want to push > value types by making working with classes harder so be it :P.

Re: [swift-evolution] [Discussion] "try" for function that does not throw

> On Jul 7, 2016, at 3:26 PM, Chris Lattner via swift-evolution > wrote: >> On Jul 7, 2016, at 10:58 AM, Vladimir.S via swift-evolution >> wrote: >> >> I didn't expect this is allowed(with warning): >> >> try print("foo") >> >> (Swift Ver. 3.0 (Jun 20, 2016)) >> >> Do we really need to allo

Re: [swift-evolution] [Review] SE-0117: Default classes to be non-subclassable publicly

> On Jul 7, 2016, at 4:16 PM, Goffredo Marocchi wrote: > > > > On Thu, Jul 7, 2016 at 11:15 PM, John McCall > wrote: > n Jul 7, 2016, at 9:39 AM, Goffredo Marocchi via swift-evolution > mailto:swift-evolution@swift.org>> wrote: >> I disagree that a stable for over

Re: [swift-evolution] [Review] SE-0117: Default classes to be non-subclassable publicly

>>> Sent from my iPad >>> >>> On Jul 8, 2016, at 8:48 AM, Thorsten Seitz >> <mailto:tseit...@icloud.com>> wrote: >>> >>>> >>>> >>>> Am 08. Juli 2016 um 15:11 schrieb Matthew Johnson via swift-evolution >

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0117: Default classes to be non-subclassable publicly

> On Jul 8, 2016, at 8:41 PM, Jordan Rose wrote: >> On Jul 6, 2016, at 09:16, John McCall via swift-evolution >> mailto:swift-evolution@swift.org>> wrote: >> >>> On Jul 5, 2016, at 10:56 PM, Chris Lattner >> <mailto:clatt...@apple.com>> wrot

<    1   2   3   4   5   >