Re: [swift-users] Overload by return type optionality?

I know, but a simple let x = 2/3 becomes ambiguous which I don’t like. > On Oct 13, 2016, at 8:00 PM, Mark Lacey wrote: > > >> On Oct 13, 2016, at 5:37 PM, Hooman Mehr via swift-users >> mailto:swift-users@swift.org>> wrote: >> >> >>> On Oct 13, 2016, at 3:31 PM, Rick Mann via swift-users

Re: [swift-users] Overload by return type optionality?

> On Oct 13, 2016, at 5:37 PM, Hooman Mehr via swift-users > wrote: > > >> On Oct 13, 2016, at 3:31 PM, Rick Mann via swift-users >> mailto:swift-users@swift.org>> wrote: >> >> Would it make sense to be able to specify priority for a set of overloaded >> methods to help resolve ambiguity?

Re: [swift-users] Subsequences and shared indices

`Slice` family of types (there are many) are well documented to share the indices and inherit the semantics. All collections that have a SubSequence of a Slice type, share indices. Unfortunately, standard library is not well documented in general and collection API have undergone big changes in

Re: [swift-users] Build Android GUI apps with Swift 3.0 via a framework/library

Yeah, I do not disagree with you. People who have succeeded have gone down the code generation route. a) This require them to build a special Swift compiler that generates Android Java Code from Swift code. They generate a 95% complete Java Android app and finish it in Android Studio. By doing it

Re: [swift-users] Subsequences and shared indices

Alright. Does this mean that we can otherwise assume that collections share indices with their subsequences? It might be worth documenting, one way or the other. > On 14 Oct 2016, at 02:40, Hooman Mehr wrote: > > This is a bug reported multiple times in different forms. My version of it > is:

Re: [swift-users] Subsequences and shared indices

This is a bug reported multiple times in different forms. My version of it is: SR-1487 . It remains open because it is not easy to fix with the existing design of String. Apparently core standard library team are working on an overhaul of String to addres

Re: [swift-users] Overload by return type optionality?

> On Oct 13, 2016, at 3:31 PM, Rick Mann via swift-users > wrote: > > Would it make sense to be able to specify priority for a set of overloaded > methods to help resolve ambiguity? This might be pretty useful in some situations, but I am not sure if the semantic complexity that it introduce

Re: [swift-users] Build Android GUI apps with Swift 3.0 via a framework/library

I think it is too soon to tackle this issue. I think there is room for making adapters for a lightweight GUI toolkit for embedded applications. For example, a Swift adapter for EFL (of Enlightenment) or something like that. But when we talk about Androi

[swift-users] Subsequences and shared indices

Is it a requirement that collections share indices with its subsequence? Array and ArraySlice do share indices, which is why ArraySlice isn’t zero-based, and I think this is convenient. But String.CharacterView doesn’t seem to share indices with its subsequence (which is String.CharacterView as

Re: [swift-users] Overload by return type optionality?

> On Oct 13, 2016, at 3:27 PM, Rick Mann wrote: > >> >> On Oct 13, 2016, at 14:47 , Joe Groff wrote: >> >> >>> On Oct 13, 2016, at 2:36 PM, Rick Mann via swift-users >>> wrote: >>> >>> It seems I can write this: >>> >>> extension String >>> { >>> public func deleting(prefix inPrefix: Str

Re: [swift-users] Overload by return type optionality?

> On Oct 13, 2016, at 14:51 , Greg Parker wrote: > >> >> On Oct 13, 2016, at 2:36 PM, Rick Mann via swift-users >> wrote: >> >> It seems I can write this: >> >> extension String >> { >> public func deleting(prefix inPrefix: String) -> String >> public func deleting(prefix inPrefix: String

Re: [swift-users] Overload by return type optionality?

> On Oct 13, 2016, at 14:47 , Joe Groff wrote: > > >> On Oct 13, 2016, at 2:36 PM, Rick Mann via swift-users >> wrote: >> >> It seems I can write this: >> >> extension String >> { >> public func deleting(prefix inPrefix: String) -> String >> public func deleting(prefix inPrefix: String) ->

Re: [swift-users] Build Android GUI apps with Swift 3.0 via a framework/library

Ok, Can I take the fact that there no feedback yet on a) The community is not interested in writing Android apps in Swift or b) Wrong forum despite the fact the inventor the Swift programming language pointed me here, or c) This has been tried and failed before. I sincerely interested in the Swift

Re: [swift-users] Overload by return type optionality?

> On Oct 13, 2016, at 2:36 PM, Rick Mann via swift-users > wrote: > > It seems I can write this: > > extension String > { > public func deleting(prefix inPrefix: String) -> String > public func deleting(prefix inPrefix: String) -> String? > } > > But I was hoping it would do the right thing

Re: [swift-users] Overload by return type optionality?

> On Oct 13, 2016, at 2:36 PM, Rick Mann via swift-users > wrote: > > It seems I can write this: > > extension String > { > public func deleting(prefix inPrefix: String) -> String > public func deleting(prefix inPrefix: String) -> String? > } > > But I was hoping it would do the right thing

Re: [swift-users] Overload by return type optionality?

It works if you specify the types of the variables: let a: String = … if let b: String = … Nevin On Thu, Oct 13, 2016 at 5:36 PM, Rick Mann via swift-users < swift-users@swift.org> wrote: > It seems I can write this: > > extension String > { > public func deleting(prefix inPrefix: String) ->

[swift-users] Overload by return type optionality?

It seems I can write this: extension String { public func deleting(prefix inPrefix: String) -> String public func deleting(prefix inPrefix: String) -> String? } But I was hoping it would do the right thing: let a = s.deleting(prefix: "foo") if let b = s.deleting(prefix: "foo") { } But it fi

Re: [swift-users] How to be DRY on ranges and closed ranges?

The more idiomatic way is to look at API design in a new way. Note these points: 1. `Countable` variant is preferred when you want to deal with integer ranges as it more closely matches the element type. 2. Both countable range variants share a common protocol conformance already: `RandomAccessCo

Re: [swift-users] How to be DRY on ranges and closed ranges?

On more thing: The result type of my `random()` extension is optional. This might not be ideal. It is not an expected and likely case that `random()` returns nil. I would personally prefer it to be non-optional and crash if the array is empty, just like it would if you tried to reference a non

Re: [swift-users] Data reflection metadata?

> On Oct 13, 2016, at 9:19 AM, Austin Zheng via swift-users > wrote: > > You probably want to check out this repo: https://github.com/Zewo/Reflection > > It's clever stuff. Really, really reliant on implementation details of the > runtime to function, so I'd be loathe to use it in any sort of

Re: [swift-users] Data reflection metadata?

You probably want to check out this repo: https://github.com/Zewo/Reflection It's clever stuff. Really, really reliant on implementation details of the runtime to function, so I'd be loathe to use it in any sort of production application, but as a proof of c

[swift-users] Data reflection metadata?

In a recent-ish post on swift-evolution , Chris Lattner mentioned: > …the extensive work on data reflection metadata that was put into Swift 3. > It is key to enabling the Xcode 8 memory visualization / debugge

Re: [swift-users] How to be DRY on ranges and closed ranges?

I recommend having explicit precondition and reducing repetition like this: import Foundation func random(from range: CountableRange) -> Int { precondition(range.count > 0, "The range can't be empty.") return random(from: CountableClosedRange(range)) } func random(

Re: [swift-users] find std lib doc

> On 12 Oct 2016, at 16:13, Lars-Jørgen Kristiansen via swift-users > wrote: > > I recommend Dash 😏 Which has, unfortunately, recently been deleted from the app store due to alleged fraudulent reviews. However, the Mac version is still available here: https://kapeli.com/dash It is really go