Re: [swift-evolution] [swift-dev] Make offset index available for String

Sorry for my unclear "offset indexable". So what I mean by "offset indexable" is providing a "collection-element level offset indexing". This indexing could provide to any collection, because it is the basic concept of collections. The unicode offset is different than it and is important to Strin

Re: [swift-evolution] array splatting for variadic parameters

t’s imho another useful aspect, something else that can be expressed > with an array literal > func f(args: Set) > > So you would not only make the language surface smaller, but also add new > abilities that basically come for free (they would still have to be > implemented, t

Re: [swift-evolution] array splatting for variadic parameters

What happened with this proposal? This looks easy to implement. func sumOf(numbers: Int...) -> Int { ... } typealias Function = [Int] -> Int let sumOfArray = unsafeBitCast(sumOf, Function.self) sumOfArray([1, 2, 3]) > Hello everyone. > > I understand that topic has already been discussed

[swift-evolution] [Bug] Foundation.URL should support semicolon(; ) appearing in URL path

http://host/book;id=1/page;2/ this URL is a valid URL, but URLComponents will ruin it with %3B http://host/book%3Bid=1/page%3B2/ Since Swift Server is coming out, this bug should be solved. ___ swift-evolution mailing list swift-evolution@swift.org h

[swift-evolution] [Pitch] allow non-nominal type extension

It is just same as current grammar: extension TrackCountProvider where Self : PublishDateProvider { ... } with a more logical format extension TrackCountProvider & PublishDateProvider { ... } > e.g. > > extensionTrackCountProvider&PublishDateProvider{ > vartrackCountAndPublishDateText:String{

[swift-evolution] [Pitch] allow non-nominal type extension

e.g. extension TrackCountProvider & PublishDateProvider { var trackCountAndPublishDateText: String { var infos: [String] = [] if let trackCount = trackCount { infos.append("\(trackCount)") } if let publishDateText = publishDate?.te

[swift-evolution] [Pich] allow embed type declaration in protocol & allow throw in property getter/setter

1. allow embed type declaration in protocol e.g.: protocol URLProvider { fun url() throws -> URL } extension URLProvider { enum Error: Swift.Error { invalidBaseURL invalidPath invalidQuery invalidFragment } } func parseURL() throws -> URL {

Re: [swift-evolution] [Pitch] inout with capture variable

I just want to demo how the inout capture works. the demo code just want to capture value avoiding capture self. > > On Oct 5, 2016, at 10:07 PM, Cao > > Jiannanmailto:frog...@163.com)>wrote: > > so if developer want to capture an variable inference, must declare a new > > variable. > I don’t f

Re: [swift-evolution] [Pitch] inout with capture variable

so if developer want to capture an variable inference, must declare a new variable. class A { var value = 1 func test() -> () -> Int { var capturedValue = self.value let editInfo = { () -> Int in capturedValue += 1 return capturedValue

[swift-evolution] [Pitch] inout with capture variable

for example: var a = 1 let block = { [inout a] in a += 1 } block() block() print(a) // 3 ___ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution

[swift-evolution] [Pitch] Several improvements points about extension and typealias

1. Allow extension specific dictionary e.g. extension Dictionary where Key == String, Value == String or extension Dictionary 2. Allow extending Equatable internally currently any type extend to Equatable should make theme public 3. Allow internal typealias for a public type this internal typeali

[swift-evolution] [Pitch] allow define submodule in Foundation or file group like Swift Standard Library?

I notice that Swift Standard Library using GroupInfo to define group of swift files. And Xcode can show that group in editor. e.g. Math. Will Apple allow Swift developer to define group in their own framework? So they can see the special generated type information instead of a long file. In Fou

[swift-evolution] [Pitch] improve import sentence: allow import specific nested types

Now Swift 3 allow us import specific enum/struct from module, but it only allow us import top-level declaration. For example: in MyFoudnation framework: public struct Time { public struct DateOnly {} } in App target: I can only import struct MyFoundation.Time But I cannot import struc

Re: [swift-evolution] [Pre-Proposal-Discussion] Union Type - Swift 4

21:42，Wallacy 写道： > > You don't need to act like a jerk. It's really difficult ask to you follow > the past discussions? > > Compositions type are "generally" well accepted for this community, but has > some problems to be solved first. > > >> E

Re: [swift-evolution] [Pre-Proposal-Discussion] Union Type - Swift 4

OK. I'll shut up since I waste your time. At 2016-08-11 13:41:59, "Chris Lattner" wrote: You’re certainly welcome to your opinion. Swift is not Typescript, and this topic has been discussed extensively in the past. We expect you to familiarize yourself with those discussions. Otherwise,

Re: [swift-evolution] [Accepted] SE-0091: Improving operator requirements in protocols

OK. I'll shut up since I wast your time. > 在 2016年7月14日，12:56，Chris Lattner via swift-evolution > 写道： > > >> On Jul 13, 2016, at 8:57 PM, Tony Allevato > > wrote: >> >> Thanks Chris! I'm happy that the proposal was well-received, and thanks to >> Doug for the grea

Re: [swift-evolution] [Pre-Proposal-Discussion] Union Type - Swift 4

Swift evolution seems not an evolution. I'll leave this mail list since this is not a good proposal environment. Typescript and other language community is more open to new idea. Swift-evolution is just a weird community. You just accept what you like and what you want. Is this called swift

Re: [swift-evolution] [Pre-Proposal-Discussion] Union Type - Swift 4

sions on > the topic? > On Wed, Aug 10, 2016 at 21:59 Cao, Jiannan via swift-evolution > mailto:swift-evolution@swift.org>> wrote: > It is no a mistake. since fn1: (A|B)->Void is subtype of fn0: A->Void > > Detail explain: > > var fn0: A->Void = {print($0

Re: [swift-evolution] [Pre-Proposal-Discussion] Union Type - Swift 4

https://github.com/apple/swift-evolution/blob/master/commonly_proposed.md> > > Is there anything in your proposal that goes beyond previous discussions on > the topic? > On Wed, Aug 10, 2016 at 21:59 Cao, Jiannan via swift-evolution > mailto:swift-evolution@swift.org>> wro

Re: [swift-evolution] [Pre-Proposal-Discussion] Union Type - Swift 4

ar fn1: (A|B)->Void= {print(v0)} fn0 = fn1 // OK, because Original Type and Union Type has a sub-typing relationshipvar fn2: (A|B|C)->Void= {print($0)} fn0 = fn2 // OK fn1 = fn2 // OK` On Aug 10, 2016, at 9:28 PM, Cao Jiannan via swift-evolution wrote: Hi all, I want to make

[swift-evolution] [Pre-Proposal-Discussion] Union Type - Swift 4

Hi all, I want to make a discussion about union type for swift 4. See https://github.com/frogcjn/swift-evolution/blob/master/proposals/-union-type.md Add union type grammar, represents the type which is o

Re: [swift-evolution] [Accepted] SE-0111: Remove type system significance of function argument labels

If you like, you can try to modify your code as you writes. It is crazy. > 在 2016年7月10日，00:08，Austin Zheng via swift-evolution > 写道： > >> >> On Jul 9, 2016, at 1:56 AM, Goffredo Marocchi via swift-evolution >> mailto:swift-evolution@swift.org>> wrote: >> >> >> Sent from my iPhone >> >> On

Re: [swift-evolution] [Accepted] SE-0111: Remove type system significance of function argument labels

func needsCallback(callback: (a: Int, b: Int) -> Void) { callback(a: 1,b: 2) } func needsCallback(callback: (Int, Int) -> Void) { callback(1, 2) } Is the first one will be forbidden? So you'd like to keep the second one? > 在 2016年7月7日，11:06，Chris Lattner via swift-evolution > 写道： >

[swift-evolution] [swift-evolution-announce] [Accepted] SE-0111: Remove type system significance of function argument labels

gt; Félix >> >>> Le 6 juil. 2016 à 20:50:17, Cao, Jiannan via swift-evolution >>> a écrit : >>> >>> l'd like the way of Python to handle the function signature.Assign lost >>> other possibility of that function: >>>

Re: [swift-evolution] [swift-evolution-announce] [Accepted] SE-0111: Remove type system significance of function argument labels

, there is little precedent for them and doing so either > drastically limits what kinds of default arguments can be expressed or causes > values of function type to become large (so they can encode the computation > of the default values). > >- Doug > >> >>> 在 2016年7

[swift-evolution] Fwd: [swift-evolution-announce] [Accepted] SE-0111: Remove type system significance of function argument labels

so how you call bar and get default values for a, b, c? why lost default value for that function? it is wired. > >> 在 2016年7月7日，11:29，Douglas Gregor 写道： >> >> >>> On Jul 6, 2016, at 8:25 PM, Cao, Jiannan via swift-evolution >>> wrote: >>> &g

Re: [swift-evolution] [swift-evolution-announce] [Accepted] SE-0111: Remove type system significance of function argument labels

Don't agree with this one. func foo(a: Int = 0, b: Int = 1, c: Int = 2) { print(a, b, c) } foo(a: 1, c: 3) let bar = foo bar(1, 3) will different than foo(a: 1, c: 3) > 在 2016年7月7日，11:06，Chris Lattner 写道： > > Proposal Link: > https://github.com/apple/swift-evolution/blob/master/proposal

[swift-evolution] Fwd: [Proposal] Union Type

ft-evolution] [Proposal] Union Type > 日期: 2016年7月2日 GMT+8 01:03:17 > 收件人: Cao Jiannan > 抄送: swift-evolution > >> >> On Jul 1, 2016, at 2:08 AM, Cao Jiannan via swift-evolution >> mailto:swift-evolution@swift.org>> wrote: >> >> >> >> Hi

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

But in the union type design, String == String | String, this is always true > I already answered that question: > > For example: > > typealias ABC = A | B | C > > typealias ABCD = ABC | D > > we just use an existed type ABC to construct ABCD > > But how about generic wrap? > > Bikeshedding:

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

what if OneOf? duplicate variable compile warning? > 在 2016年7月1日，20:59，Adrian Z. > 写道： > > Just one simple thing to add: > > If ...T equals 10 then <...T, U> = 10 + 1 = 11 types > If ...U equals 17 then = 1 + 17 = 18 types > If ...T equals 20 and ...Uequals 22

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

I can't compile your code. I'm really not sure your code will pass the complex generic check 🙃 Union version more complex or generic version? I think union version is more normal. > For example: > > typealias ABC = A | B | C > > typealias ABCD = ABC | D > > we just use an existed type ABC to c

Re: [swift-evolution] [apple/swift-evolution] Proposal: Union Type

> 下面是被转发的邮件： > > 发件人: Cao Jiannan > 主题: 回复： [apple/swift-evolution] Proposal: Union Type (#404) > 日期: 2016年7月1日 GMT+8 21:22:32 > 收件人: apple/swift-evolution > > > what if OneOf? > > duplicate variable compile warning? > >> 在 2016年7月1日，20:59，Adrian Z. > > 写道：

[swift-evolution] [Proposal] Union Type

Hi all, I'm now officially proposal the union type feature for Swift. Please see: https://github.com/frogcjn/swift-evolution/blob/master/proposals/-union-type.md Introduction Add union type grammar, re

[swift-evolution] [Proposal] Union Type

https://github.com/frogcjn/swift-evolution/blob/master/proposals/-union-type.md Hi, I'm now officially proposal the union type feature for Swift. Please see: https://github.com/apple/swift/commit/eb7311d

[swift-evolution] [proposal] Union Type

Union is far better then generic enum/protocol solution. * It can extend the original enum and make it powerful. enum ResultDataType { case Music case Video case File } enum FailureType { case HTTP404 case HTTP502 } enum FailureTypev2 { case HTTP45

Re: [swift-evolution] Union instead of Optional

Hi Austin, let me repeat the example so that clarify my point from this example. protocol cannot do this: func input(value: ProtocolForABC) { print(value.someCommonProperty) if value is A { } else if value is B { } else if value is C { } else {

Re: [swift-evolution] Union instead of Optional

Consider this case: class A { var someCommonProperty: Int = 0 } class B { var someCommonProperty: Int = 0 } class C { var someCommonProperty: Int = 0 } protocol UnionABC { var someCommonProperty: Int } extension A: UnionABC {} extension B: UnionABC {} extension C: UnionABC {}

[swift-evolution] [Proposal] Using Union instead of Generic Enum to implement Optional

nt($0)} fn0 = fn2 // OK fn1 = fn2 // OK > 下面是被转发的邮件： > > 发件人: Cao Jiannan via swift-evolution > 主题: [swift-evolution] Fwd: Union instead of Optional > 日期: 2016年5月15日 GMT+8 18:34:44 > 收件人: Adrian Zubarev via swift-evolution > 回复－收件人: Cao Jiannan > > for example, ther

[swift-evolution] Fwd: Union instead of Optional

for example, there is a method input union of 3 types: A, B, C, This is the three class. class A {} class B {} class C {} This is how it implemented under Swift 2: enum UnionABC { case classA(A) case classB(B) case classC(C) } func input(value: UnionABC) { } let a = A() let

Re: [swift-evolution] Union instead of Optional

ee what your proposal is trying to solve? > >> On 15 May 2016, at 04:33, Cao Jiannan via swift-evolution >> wrote: >> >> >> It’s kind of same idea of TypeScipt 2, at 46:21 in this video. >> >> https://channel9.msdn.com/Events/Build/2016/B881 >> >

[swift-evolution] IUO type, treat nil as normal error, not fatal error

Hi all, I want to discuss the Implicitly Unwrapped Optional Type. In Swift 1 and Swift2, when a variable declared as IUO type, its value should be non-nil. If its value is nil, it will crash the program when read the value. I believe it is better to let developer catch this event, treat it as