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

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

d that’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

[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

[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{ > vartrackCountAndPublishDateText:String{ > varinfos:

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

[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

’m not quite sure what you’re getting at, but this prints what you’re > expecting in the output you have in the comments: > > class A { > var value = 1 > > func test() ->() ->Int { > let editInfo = { () ->Int in > self.value += 1 > return self.value > } &

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

alue] () -> Int in capturedValue += 1 return capturedValue } return editInfo } } let a = A() let editInfo = a.test() print(editInfo()) // 2 print(a.value) // 2 print(editInfo()) // 3 print(a.value) // 3 > > On Oct 5, 2016, at 9:06 PM, Cao Jiannan via &

[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

[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

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

<walla...@gmail.com> 写道： > > 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. > > >>

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

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

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

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

goes beyond previous discussions on > the topic? > On Wed, Aug 10, 2016 at 21:59 Cao, Jiannan via swift-evolution > <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: > It is no a mistake. since fn1: (A|B)->Void is subtype of fn0: A->Void > > De

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

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

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

0: A->Void= {print(v0)} var 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 &

[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

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

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

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

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

gt;>> 在 2016年7月7日，11:29，Douglas Gregor <dgre...@apple.com> 写道： >>> >>> >>>> On Jul 6, 2016, at 8:25 PM, Cao, Jiannan via swift-evolution >>>> <swift-evolution@swift.org> wrote: >>>> >>>> Don't agree wit

[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 <dgre...@apple.com> 写道： >> >> >>> On Jul 6, 2016, at 8:25 PM, Cao, Jiannan via swift-evolution &

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

om> > 主题: 回复： [swift-evolution] [Proposal] Union Type > 日期: 2016年7月2日 GMT+8 01:03:17 > 收件人: Cao Jiannan <frog...@163.com> > 抄送: swift-evolution <swift-evolution@swift.org> > >> >> On Jul 1, 2016, at 2:08 AM, Cao Jiannan via swift-evolution >> <swif

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

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

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

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

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

[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

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

B)->Void = {print(v0)} fn0 = fn1 // OK var fn2: (A|B|C)->Void = {print($0)} fn0 = fn2 // OK fn1 = fn2 // OK > 下面是被转发的邮件： > > 发件人: Cao Jiannan via swift-evolution <swift-evolution@swift.org> > 主题: [swift-evolution] Fwd: Union instead of Optional > 日期: 2016年5月15日 GMT+8 18

[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()

[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