Re: [swift-evolution] Name disambiguation of computed property/function with same type defined in extensions

IMO you have identified some of the symptoms of a larger issue with Swift. Currently swift lets us group our code into modules. Within a module we can use folders to physically group the files, but this is not mandatory (and xcode does not by default align the logical and physical structure of

Re: [swift-evolution] [swift-evolution-announce] [Returned for revision] SE-0089: Renaming String.init(_: T)

Sorry, I meant to reply to this but forgot. > For developers, like ourselves, it seems straight-forward that a string is > this simple primitive. We get them in, we process them, and we spit them back > out. However, this is a flawed system, as it one that is made easiest for the > programmer,

Re: [swift-evolution] [Review #2] SE-0089: Renaming String.init(_: T)

The issue I think is that it would open up serialisation for all sorts of formats, which is a much larger problem in itself, whereas this can just focus on a user-defined ‘lossless’ string. Patrick > On 5 Jun 2016, at 1:25 PM, David Sweeris via swift-evolution > wrote: > > >> On Jun 4, 2016

Re: [swift-evolution] [Review #2] SE-0089: Renaming String.init(_: T)

> On Jun 4, 2016, at 15:46, Jacob Bandes-Storch via swift-evolution > wrote: > > - The "lossless" protocol will be a welcome addition for > serialization/deserialization code, and it makes the replacement init(_:) API > very clear in its behavior. Speaking of which, would "Serializable" be

Re: [swift-evolution] Name disambiguation of computed property/function with same type defined in extensions

You forgot one :-) let capitalizedA = ModuleA { "hello swift".capitalized() } +1 on finding a way to explicitly resolve naming collisions. I'm generally in favor of something like #2 (or #3). A while back, there was a proposal to replace numerical operator precedence with a relative preceden

Re: [swift-evolution] [Review #2] SE-0089: Renaming String.init(_: T)

Instead of LosslessStringConvertible, could the existing Streamable be used? extension String { public init(_ streamable: T) { self.init() streamable.write(

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0099: Restructuring Condition Clauses

+1 I think that it is an improvement overall and the work for consistency is appreciated. On Sat, Jun 4, 2016 at 10:03 PM, Greg Titus via swift-evolution < swift-evolution@swift.org> wrote: > > I think that Jon has exactly described my view on this proposal. Thanks, > Jon. > > -1. > > -- Greg

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0099: Restructuring Condition Clauses

I think that Jon has exactly described my view on this proposal. Thanks, Jon. -1. -- Greg > On Jun 4, 2016, at 12:17 AM, Jon Shier via swift-evolution > wrote: > > The suitability of “where” as the keyword in these clauses is a > completely separate issue. Frankly, it just comes do

[swift-evolution] Name disambiguation of computed property/function with same type defined in extensions

+1. I agree that this could be a problem, especially if you’re importing a lot of similar modules. I like the `from` keyword, as I feel that is consistent with the language grammer. My vote would be for proposal #4. > Hello, everyone. > > I want to discuss the problem of name ambiguity when a

[swift-evolution] Name disambiguation of computed property/function with same type defined in extensions

Hello, everyone. I want to discuss the problem of name ambiguity when a computed property or function is defined with the same name and type in different modules. Currently there’s no way to disambiguate the implementation in use cases similar to the one contained in the gist below. https://gi

Re: [swift-evolution] [Proposal] Conditional Conformance on Protocols/Generic Types

Hey- Thanks for the quick response and for pointing me in the right direction! Dan > On Jun 4, 2016, at 4:18 PM, Austin Zheng wrote: > > Hello Dan, > > You'll be pleased to learn that conforming generic types conditionally to > protocols is on the roadmap (and is one of the highest priority

Re: [swift-evolution] [Proposal] Conditional Conformance on Protocols/Generic Types

Hello Dan, You'll be pleased to learn that conforming generic types conditionally to protocols is on the roadmap (and is one of the highest priority items for the versions of Swift following 3.0): https://github.com/apple/swift/blob/master/docs/GenericsManifesto.md#conditional-conformances- <

[swift-evolution] [Proposal] Conditional Conformance on Protocols/Generic Types

Hey, I was interested in adopting the ability for a type that's generic in some sense (either via generics or via associated types, in the case of protocols) to conform to other protocols conditionally based on its type parameter/associated type. For example: ``` extension CollectionType: Equa

Re: [swift-evolution] [Review #2] SE-0089: Renaming String.init(_: T)

(updating my evaluation of the first version of this proposal) > > https://github.com/apple/swift-evolution/blob/master/proposals/0089-rename-string-reflection-init.md > > * What is your evaluation of the proposal? > +1, because: - I believe the default/generic "printing" initializer i

Re: [swift-evolution] [Proposal] Enum subsets

It could be a more general solution. I am unclear about what 'subtype relationships' means here though. Are you talking a about what you allude to here? https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151130/000525.html The benefit of explicitly narrowing, in my opinion, is that

Re: [swift-evolution] Add conversion String -> Bool

I'm not particularly in favor of a String initializer for booleans. In fact, I'm not particularly in favor of a String initializer for any numeric type. Swift's String design ensures that developers can't make assumptions about encodings and a more international alphabet, which is a net win for

Re: [swift-evolution] [Proposal] Enum subsets

> On Jun 3, 2016, at 10:34 PM, Austin Zheng wrote: > > It seems like it would make sense to model enum subsets as a subtype > relationship. > > Is the core team planning on drawing up a structs/enums subtyping proposal > later this year? I would *love* to get it in Swift 3.x or Swift 4, but

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

On Jun 2, 2016, at 9:08 AM, John McCall via swift-evolution wrote: > > 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 fol

Re: [swift-evolution] Add conversion String -> Bool

Since the XML and JSON related objects are part of Foundation, I think it would be great to have that functionality in Foundation as well. For “true”, “false”, “1” and “0” (in addition to 1 and 0). Mirek > On Jun 4, 2016, at 06:10, Arsen Gasparyan via swift-evolution > wrote: > > Hello, >

Re: [swift-evolution] [swift-evolution-announce] [Returned for revision] SE-0089: Renaming String.init(_: T)

> On May 31, 2016, at 4:02 PM, Hooman Mehr via swift-evolution > wrote: > > This arises a different question: Should `description` always return the same > value? For example: Can `description` of “May 31th, 2016” return “Today” if > we evaluate it today and return “Yesterday” if we evaluate

[swift-evolution] Swift request list

Dear swift team I would like to propose the following features to the Swift which could be easily added IMHO Reflection support get/set proper by name, method invocation etc. Option to get property name from variable could be useful for parsing JSON etc. e.g. self.lastName.dynamicPropertyName sho

[swift-evolution] [Review #2] SE-0089: Renaming String.init(_: T)

Hello Swift community, The review of the revised proposal SE-0089: "Renaming String.init(_: T)" begins now and runs through June 7. The proposal is available here: https://github.com/apple/swift-evolution/blob/master/proposals/0089-rename-string-reflection-init.md Reviews are an import

Re: [swift-evolution] Add conversion String -> Bool

> On Jun 4, 2016, at 7:22 AM, Brent Royal-Gordon via swift-evolution > wrote: > >> It would be great if we had `init?(_ text: String)` for Bool class. Because >> sometime when you're processing JSON/XML it can help you a lot. > > Way ahead of you: > https://github.com/apple/swift-evolution/b

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

> On 04 Jun 2016, Erica Sadun wrote: > > Discussion has more or less drawn down. Are there any further significant > requests / issues that need addressing? Both standalone functions (my > recommended approach) and the MemoryLayout struct approach (alternative, > with reasons why I think it's

Re: [swift-evolution] Add conversion String -> Bool

You may be right, but I'd imagine such a conversion function would be in pretty much any library for serializing/deserializing data. I can't recall if this has been discussed before, but are we committed to One Standard Library to Rule Them All, or might we consider having a "standard" library

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

> On Jun 4, 2016, at 10:27 AM, LM wrote: > > > > On Jun 4, 2016, at 4:00 PM, Matthew Johnson via swift-evolution > mailto:swift-evolution@swift.org>> wrote: > >> >>> On Jun 3, 2016, at 9:30 PM, John McCall >> > wrote: >>> On Jun 3, 2016, at 7:08 PM, Matthew

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

> On Jun 4, 2016, at 4:00 PM, Matthew Johnson via swift-evolution > wrote: > > >>> On Jun 3, 2016, at 9:30 PM, John McCall wrote: >>> 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, Matth

Re: [swift-evolution] Ad hoc enums / options

Good point. This is one of my main concerns: Adding too much to the core language makes it harder to learn. I think we should focus on eliminating special cases and exceptions in the language and only add simple foundational enabling features that can enable addressing other issues (boilerpl

Re: [swift-evolution] Ad hoc enums / options

Sent from my iPhone > On Jun 4, 2016, at 9:58 AM, Hooman Mehr wrote: > > How about this: > > > Going back to Erica’s original example: > > func scaleAndCropImage( > image: UIImage, > toSize size: CGSize, > operation: (.Fit | .Fill) = .Fit > ) -> UIImage { > > And noting tha

Re: [swift-evolution] Ad hoc enums / options

Anyone thinking about complexity > On Jun 4, 2016, at 4:58 PM, Hooman Mehr via swift-evolution > wrote: > > How about this: > > > Going back to Erica’s original example: > > func scaleAndCropImage( > image: UIImage, > toSize size: CGSize, > operation: (.Fit | .Fill) = .Fit >

Re: [swift-evolution] Ad hoc enums / options

How about this: Going back to Erica’s original example: func scaleAndCropImage( image: UIImage, toSize size: CGSize, operation: (.Fit | .Fill) = .Fit ) -> UIImage { And noting that we are already allowed to declare an enum inside the function, compiler can generate an enum sco

Re: [swift-evolution] Add conversion String -> Bool

> It would be great if we had `init?(_ text: String)` for Bool class. Because > sometime when you're processing JSON/XML it can help you a lot. Way ahead of you: https://github.com/apple/swift-evolution/blob/master/proposals/0089-rename-string-reflection-init.md (I'm not quite sure what's going

[swift-evolution] SE-0064 Property Selectors and KVO

Currently KVO requires hard-coding strings to check the keypath. Does SE-0064 cover returning a string when a string is required? For example: override func observeValueForKeyPath(keyPath: String?, ofObject object: AnyObject?,

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

> On Jun 3, 2016, at 9:30 PM, John McCall wrote: > >> 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 wrote: >>> On Jun 3,

Re: [swift-evolution] Add conversion String -> Bool

IMO, that is too idiosyncratic to be a standard language feature. You should extend Bool based on the specific needs of your application. Thats what the extensions are for. Best, t. > On 04 Jun 2016, at 15:10, Arsen Gasparyan via swift-evolution > wrote: > > Hello, > > It would be grea

Re: [swift-evolution] Add conversion String -> Bool

Agree about "1" and "0" because it's a valid XML boolean value. But I don't know where you can find "yes" / "no" value. http://www.w3schools.com/xml/schema_dtypes_misc.asp Note: Legal values for boolean are true, false, 1 (which indicates true), and 0 (which indicates false). On Sat, Jun 4, 2016

Re: [swift-evolution] [Pre-proposal] Forward/Reverse Only Indexing Methods

> Am 03.06.2016 um 21:20 schrieb Haravikk : > >> On 1 Jun 2016, at 05:51, Thorsten Seitz wrote: >> >> I like this idea. The problem is that it would require that we have an >> Index.NonNegativeDistance as argument to really make it statically safe. And >> we would have to have methods produci

Re: [swift-evolution] Add conversion String -> Bool

I think it would be interesting if it could also recognise "1" and "yes" too as it can be useful in some cases. Perhaps have an option for this converter to be customised. L -Original Message- From: "Arsen Gasparyan via swift-evolution" Sent: ‎04/‎06/‎2016 10:10 AM To: "swift-evolution

[swift-evolution] Add conversion String -> Bool

Hello, It would be great if we had `init?(_ text: String)` for Bool class. Because sometime when you're processing JSON/XML it can help you a lot. Examples: Bool("true") -> true Bool("false") -> false Bool("TrUE") -> true Bool(" true ") -> nil Bool("1") -> nil Bool("Y") -> nil Bool("whatever") -

Re: [swift-evolution] Ad hoc enums / options

Sent from my iPad > On Jun 3, 2016, at 10:27 PM, Félix Cloutier wrote: > > If there's any interest in going down that road, it seems to me that the only > viable option is to allow subsets to be convertible to their superset. Items > of (.foo | .bar) would be convertible to (.foo | .bar | .b

Re: [swift-evolution] [Proposal] Enum subsets

Sent from my iPad > On Jun 4, 2016, at 12:34 AM, Austin Zheng via swift-evolution > wrote: > > It seems like it would make sense to model enum subsets as a subtype > relationship. > > Is the core team planning on drawing up a structs/enums subtyping proposal > later this year? +1. Subtyp

Re: [swift-evolution] [Returned for Revision] SE-0095: Replace protocol syntax with Any

I like the decision of the core team to replace protocol<…> with something like & instead. This gives us room to rethink Any<…> or come up with even better mechanism for existentials. :) There are still a few things to consider: AnyObject and AnyClass: I’d prefer to drop the current AnyClass an

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0099: Restructuring Condition Clauses

The suitability of “where” as the keyword in these clauses is a completely separate issue. Frankly, it just comes down to English not having a good, single word to describe an if-and-only-if relationship. So “where" was chosen (some explanation from the original designers has been sorely