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

> On Jul 10, 2016, at 6:42 PM, Jordan Rose via swift-evolution > wrote: > >>> 2016/07/09 23:30、Matthew Johnson > のメール： This leaves the scenario of a case where you depend on a 3rd party,

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 <jordan_r...@apple.com> wrote: >> On Jul 6, 2016, at 09:16, John McCall via swift-evolution >> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >> >>> On Jul 5, 2016, at 10:56 PM, Chri

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

;> >>>> >>>> Am 08. Juli 2016 um 15:11 schrieb Matthew Johnson via swift-evolution >>>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>>: >>>> >>>>> >>>>> >>>>> Sent from my

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 >

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

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

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

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

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

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

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 <clatt...@apple.com> wrote: >> On Jul 5, 2016, at 6:53 PM, John McCall via swift-evolution >> <swift-evolution@swift.org> wrote: >> >>> >>> I think Kevin Lundberg is right to worry about test

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

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

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

On Jun 29, 2016, at 10:27 PM, L. Mihalkovic <laurent.mihalko...@gmail.com> >>> wrote: >>> >>> On Jun 29, 2016, at 9:54 PM, John McCall via swift-evolution >>> <swift-evolution@swift.org> wrote: >>> >>>>> On Jun 29, 2016, at

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

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,

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 > <swift-evolution@swift.org> wrote: >> On Jun 30, 2016, at 10:41 PM, Xiaodi Wu <xiaodi...@gmail.com >> <mailto:xiaodi...@gmail.com>> wrote: >> On Fri, Jul 1, 2016 at 12:03 AM, Dave Abraham

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 > > wrote: > > on Thu Jun 30 2016, John McCall wrote: > > >> On Jun 30, 2016, at 6:12 PM,

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

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

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

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

> On Jun 30, 2016, at 11:25 AM, Matthew Johnson <matt...@anandabits.com> wrote: > On Jun 30, 2016, at 1:08 PM, John McCall via swift-evolution > <swift-evolution@swift.org> wrote: > >>> On Jun 30, 2016, at 2:34 AM, Anton Zhilin via swift-evolution >

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

> On Jun 30, 2016, at 11:07 AM, Andrew Trick <atr...@apple.com> wrote: >> On Jun 30, 2016, at 1:21 AM, John McCall via swift-evolution >> <swift-evolution@swift.org> wrote: >> >>> On Jun 29, 2016, at 10:17 PM, L. Mihalkovic <laurent.mihalko...@gmail.c

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

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

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

> On Jun 29, 2016, at 10:17 PM, L. Mihalkovic <laurent.mihalko...@gmail.com> > wrote: >> On Jun 29, 2016, at 8:39 PM, Vladimir.S via swift-evolution >> <swift-evolution@swift.org> wrote: >> >> How about `public(extensible)` ? >> >> On 2

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

> On Jun 29, 2016, at 10:27 PM, L. Mihalkovic <laurent.mihalko...@gmail.com> > wrote: > > On Jun 29, 2016, at 9:54 PM, John McCall via swift-evolution > <swift-evolution@swift.org> wrote: > >>> On Jun 29, 2016, at 12:05 PM, Michael Peternell <michael.p

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

d by the >>>> "implicitly sealed" behavior. And with this proposal, when I read >>>> `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 >>>> unn

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

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

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

> On Jun 28, 2016, at 2:20 PM, Christopher Kornher <ckorn...@me.com> wrote: >> On Jun 28, 2016, at 2:31 PM, John McCall via swift-evolution >> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >> >>> On Jun 28, 2016, at

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

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

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

> On Jun 28, 2016, at 9:12 AM, L. Mihalkovic <laurent.mihalko...@gmail.com> > wrote: > > Question inline > Regards > LM > (From mobile) > On Jun 28, 2016, at 1:01 AM, John McCall via swift-evolution > <swift-evolution@swift.org> wrote: > >>> O

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

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

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

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 >> > wrote: >> >>> On Jun 15, 2016, at 8:36 PM, Robert Widmann

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

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

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

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

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

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

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 >> > wrote: >> >> Hi Everyone, >> >> As I mentioned before, the

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,

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

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

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

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

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

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

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 >> > wrote: >> >> Unavailable doesn't mean un-callable. >> If you're marking an

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. >

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

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

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

> On Jun 9, 2016, at 3:17 PM, Trent Nadeau wrote: > When would be a good time to actual put out a PR to the swift-evolution repo > for this proposal? The feedback so far has been very light, but I'm not sure > if that's because everyone's gearing up for WWDC, if there's

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

> 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 Jun 08 2016, Brent Royal-Gordon >>

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

> On Jun 9, 2016, at 9:04 AM, Dave Abrahams via swift-evolution > wrote: > on Wed Jun 08 2016, Brent Royal-Gordon > wrote: > >>> I'm not sure that these ideas are consistent with the Swift >>> error-handling philosophy, which IIUC

Re: [swift-evolution] Remove nil and NilLiteralConvertible

> On Jun 8, 2016, at 1:41 PM, Антон Жилин via swift-evolution > wrote: > (No joking) > Points: > > 1. When nil was added to the language, we could not infer enumeration type: > if x != Optional.none { ... } > > Now it looks like this: > if x != .none { ... } > > If

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

> On Jun 8, 2016, at 11:15 AM, Dave Abrahams wrote: > on Wed Jun 08 2016, John McCall wrote: > >>> On Jun 7, 2016, at 4:25 PM, Dave Abrahams wrote: >>> on Tue Jun 07 2016, John McCall wrote: >>> > On Jun 5, 2016, at 5:18 PM, Dave Abrahams via

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

> On Jun 7, 2016, at 4:25 PM, Dave Abrahams wrote: > on Tue Jun 07 2016, John McCall wrote: > >>> On Jun 5, 2016, at 5:18 PM, Dave Abrahams via swift-evolution >>> wrote: >>> on Thu Jun 02 2016, John McCall >>

Re: [swift-evolution] Philosophy of Swift

> On Jun 8, 2016, at 8:35 AM, J. Charles M. N. via swift-evolution > wrote: > +1 Brandon > Sound like the first real fully open source language. This is not fair to any number of other languages. We're proud of how open the Swift development process is, but we can't

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

> On Jun 7, 2016, at 7:25 PM, Brent Royal-Gordon via swift-evolution > wrote: >> @escaping would be part of the parameter type just as @noescape is today. >> Your foo(closure:) example wouldn't compile with my proposal, the same as >> today if you marked the

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

> On Jun 4, 2016, at 11:54 AM, Chris Lattner <clatt...@apple.com> wrote: > On Jun 2, 2016, at 9:08 AM, John McCall via swift-evolution > <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >> >> The official way to build a literal of a sp

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

> On Jun 5, 2016, at 5:18 PM, Dave Abrahams via swift-evolution > wrote: > on Thu Jun 02 2016, John McCall > wrote: > >> The official way to build a literal of a specific type is to write the >> literal

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

> On Jun 3, 2016, at 8:11 PM, Ben Rimmington wrote: > I think your original proposal is good, but just in case: > > [Currently] > >// Literal `7` is converted to `Swift.IntegerLiteralType` typealias. >UInt16(7) calls UInt16.init(_ value: Int) > > [Suggested] >

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

> On Jun 3, 2016, at 7:08 PM, Matthew Johnson wrote: >> On Jun 3, 2016, at 8:11 PM, John McCall wrote: >> >>> On Jun 3, 2016, at 5:13 PM, Matthew Johnson wrote: >>> On Jun 3, 2016, at 6:23 PM, John McCall

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

> On Jun 3, 2016, at 5:31 PM, Ben Rimmington via swift-evolution > wrote: > John McCall wrote: > >> I think that's a very promising way of thinking about literals. Writing >> a literal creates a notional value whose type is the informal, infinite- >> precise type of

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

> On Jun 3, 2016, at 5:13 PM, Matthew Johnson wrote: > On Jun 3, 2016, at 6:23 PM, John McCall wrote: > On Jun 3, 2016, at 4:07 PM, David Sweeris wrote: On Jun 3, 2016, at 16:17, Matthew Johnson via swift-evolution

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

@anandabits.com >>> <mailto:matt...@anandabits.com>> wrote: >>> On Jun 2, 2016, at 6:51 PM, John McCall via swift-evolution >>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >>> >>>>> On Jun 2, 2016, at 4

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

> On Jun 2, 2016, at 10:31 PM, L. Mihalkovic <laurent.mihalko...@gmail.com> > wrote: > On Jun 2, 2016, at 6:08 PM, John McCall via swift-evolution > <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: > >> The official way to build a

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

> On Jun 2, 2016, at 6:48 PM, Matthew Johnson <matt...@anandabits.com> wrote: > On Jun 2, 2016, at 6:51 PM, John McCall via swift-evolution > <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: > >>> On Jun 2, 2016, at 4:33 PM, Xiaodi Wu &

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

esent a couple of examples >>>>> where such initialization(like UInt16(7)) can produce some unexpected >>>>> behavior / error at runtime? >>>> >>>> UIntN has unlabeled initializers taking all of the standard integer types, >>>>

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

> On Jun 2, 2016, at 4:33 PM, Xiaodi Wu wrote: > The IntegerLiteral type idea might be worth exploring. It does seem to > provide some additional consistency. For example, wasn't it clarified on this > list just recently that literals don't have a type and adopt one based

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

> On Jun 2, 2016, at 2:43 PM, Brent Royal-Gordon wrote: >> In my opinion, using this initializer-call syntax to build an >> explicitly-typed literal is an obvious and natural choice with several >> advantages over the "as" syntax. However, even if you disagree, it's

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

nge >> of values for UIntN. If the literal is in the legal range for an Int but >> not for the target type, this might trap at runtime. Now, for a built-in >> integer type like UInt16, we will recognize that the coercion always traps >> and emit an error at compile-time, but this

Re: [swift-evolution] [Pitch] Renaming sizeof, sizeofValue, strideof, strideofValue

> On Jun 2, 2016, at 2:05 PM, Xiaodi Wu <xiaodi...@gmail.com> wrote: > On Thu, Jun 2, 2016 at 3:46 PM, John McCall via swift-evolution > <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >> On Jun 2, 2016, at 1:43 PM, Russ Bishop <xen...@gm

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

integer type like UInt16, we will recognize that the coercion always traps and emit an error at compile-time, but this generally won't apply to other types. John. > > On 02.06.2016 19:08, John McCall via swift-evolution wrote: >> The official way to build a literal of a specific type is to

Re: [swift-evolution] [Pitch] Renaming sizeof, sizeofValue, strideof, strideofValue

> On Jun 2, 2016, at 1:43 PM, Russ Bishop <xen...@gmail.com> wrote: >> On Jun 2, 2016, at 11:30 AM, John McCall via swift-evolution >> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >> >> I still think the value-based APIs a

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

problem should be addressed one way or another. I prefer this solution, >> but if it is rejected for whatever reason we should at least explicitly >> outlaw A(literal) syntax in favor of "literal as A". >> >> Austin >> >> On Thu, Jun 2, 201

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

I prefer this solution, > but if it is rejected for whatever reason we should at least explicitly > outlaw A(literal) syntax in favor of "literal as A". > > Austin > > On Thu, Jun 2, 2016 at 9:08 AM, John McCall via swift-evolution > <swift-evolution@swift.o

Re: [swift-evolution] [Pitch] Renaming sizeof, sizeofValue, strideof, strideofValue

> On Jun 2, 2016, at 11:22 AM, Matthew Johnson wrote: > On Jun 2, 2016, at 12:01 PM, John McCall > wrote: > >>> On Jun 2, 2016, at 8:48 AM, Matthew Johnson via swift-evolution >>>

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

e top of my > head, but I’m not convinced that means they don’t exist. I do not think that anybody writes UInt64(0) and *wants* the 0 to be built as an Int and then coerced to UInt64. John. > > So… I’m tentatively -1 > > - Dave Sweeris > >> On Jun 2, 2016, at 11:08 AM,

Re: [swift-evolution] [Pitch] Renaming sizeof, sizeofValue, strideof, strideofValue

> On Jun 2, 2016, at 8:48 AM, Matthew Johnson via swift-evolution > wrote: >> On Jun 2, 2016, at 10:38 AM, Xiaodi Wu > > wrote: >> >> Well, as I understand it, it's not actually possible to write your own >>

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

The official way to build a literal of a specific type is to write the literal in an explicitly-typed context, like so: let x: UInt16 = 7 or let x = 7 as UInt16 Nonetheless, programmers often try the following: UInt16(7) Unfortunately, this does not attempt to construct the value

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0089: Replace protocol<P1, P2> syntax with Any<P1, P2>

> On May 29, 2016, at 6:38 AM, Thorsten Seitz wrote: > An, now I see what you mean. You are right, P ::= ∃ t : P . t is a > constrained existential type defining a subtype relationship. > Thanks for enlightening me! > > I haven’t perceived a protocol as an existential up to

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0089: Replace protocol<P1, P2> syntax with Any<P1, P2>

> On May 25, 2016, at 7:07 AM, Thorsten Seitz via swift-evolution > wrote: > This is unfortunate, because then the meaning of "existential" and > "non-existential" in Swift are just the opposite of their respective meaning > in standard terminology :-( I don't know

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0098: Lowercase didSet and willSet for more consistent keyword casing

> On May 24, 2016, at 11:21 AM, Joe Groff via swift-evolution > wrote: > didSet and willSet are already contextual rather than formal keywords, and > there's a conceivable future where didSet and willSet are no longer keywords > at all if we run with the "property

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

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

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

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

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 >> > wrote: >>> On May 20, 2016, at 10:25, John McCall

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.

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

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

[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] #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

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

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

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

<    1   2   3   4   5   >