Re: [swift-evolution] Dropping NS Prefix in Foundation

I'm +1 for this proposal. It is, IMO, a sensible way to evolve the current situation to provide for a nicer experience. As far as I can tell, arguments against the proposal argue for the elimination of Foundation and a totally new set of Swift-native facilities, which unless I'm mistaken is not

Re: [swift-evolution] Allow FloatLiteralType in FloatLiteralConvertible to be aliased to String

This would be an excellent solution to the issue. Do you know if there are any existing plans for something like the DecimalLiteralConvertible? Another thought: Would it make sense to have the compiler warn about float literal precision issues? Initialization of two different variables with the

Re: [swift-evolution] Typealiases in protocols and protocol extensions

If the protocol Sequence has typealias Element, does that mean I also have MyConformingSequence.Element? If so, I think there is a potential impact on existing code not mentioned. Suppose MyConformingSequence already (unwisely) declares typealias Element. Now, what happens when I try to migrate

Re: [swift-evolution] Dropping NS Prefix in Foundation

But if the NS- prefix is removed now, then it will make it more painful to have breaking changes down the road. I’d prefer to see breaking changes happen and the introduction of new completely modern APIs. Even just protocols that the NS- Foundation can implement. Say for example, a

[swift-evolution] Typealiases in protocols and protocol extensions

Hello, I’ve come again with another proposal directly from the Generics Manifesto. Please let me know if it needs any modifications before sending the pull request. Typealiases in protocols and protocol extensions Proposal: SE-

Re: [swift-evolution] [Manifesto] Completing Generics

> On 09 May 2016, at 00:38, Austin Zheng wrote: > > Is the plan to eventually support "multiple" forms of concrete same-type > requirement syntax - the existing "where Element == SomeConcreteType" and the > generic parameterized extensions described elsewhere? If not,

Re: [swift-evolution] [Manifesto] Completing Generics

Is the plan to eventually support "multiple" forms of concrete same-type requirement syntax - the existing "where Element == SomeConcreteType" and the generic parameterized extensions described elsewhere? If not, the syntax should probably be discussed as part of a pre-proposal thread before

Re: [swift-evolution] multi-line string literals.

> By the way has the backtick or triple backtick been considered? Backticks already have a meaning—they "quote" an identifier which would otherwise be taken as a keyword. -- Brent Royal-Gordon Sent from my iPhone > On May 8, 2016, at 2:58 PM, Ricardo Parada wrote: > > The

Re: [swift-evolution] [Opinion] Thoughts about the SE-0025 (Scoped Access Level) proposal

When you say you missed all the discussions and threads... you missed probably the longest bikeshedding discussion we've had on Swift Evolution so far. First: no-one's ruled out a 'protected' access level yet. Equally, as far as I recall, it hasn't been presented for review yet. It's neither

Re: [swift-evolution] [Manifesto] Completing Generics

Sorry, I misunderstood that you meant that the version of Concrete same-type requirement that does not introduce new syntax could be sent through as a bug request. It’s now done: [SR-1447] Concrete same-type requirements > On 08 May 2016, at 23:17,

Re: [swift-evolution] Should we rename "class" when referring to protocol conformance?

> On May 7, 2016, at 6:43 PM, Matthew Johnson via swift-evolution > wrote: > > If I read Andrew’s post correctly it sounds like it may also be of use to the > optimizer in some cases. I’ll just requote Dave’s example, which made perfect sense to me (so I’m not

[swift-evolution] NSRange and Range

Hello Swift-Evolution, I spent some time coding on Linux with Swift 3 (latest developement snapshot) and corelibs-foundation and I’ve hit one major hurdle: passing and converting NSRange and Range around between the different stdlib and Foundation APIs - specifically in regards to String. Is

Re: [swift-evolution] [swift-corelibs-dev] Change in String.CharacterView.Index?

Hey Joe, The collection index model changed: https://github.com/apple/swift-evolution/blob/master/proposals/0065-collections-move-indices.md You now need to ask the collection for the next index: let a = “Hello, World" let secondIndex = a.characters.index(after: a.characters.startIndex)

[swift-evolution] [Idea] Represent a point in time as a Swift immutable scalar type TimePoint

Proposal Represent a point in time as a Swift immutable scalar type TimePoint Motivation The representation of time and calculations involving time are fundamental to the correct functioning of all computer systems. If the language can express and manipulate points in time in a consistent

Re: [swift-evolution] [Proposal/Pitch] Function decorators

> On 4 May 2016, at 00:46, Aleksandar Petrovic via swift-evolution > wrote: > > Hi swift-evolution, > > I want to apologize in advance for my clumsy English. It's (obviously) not my > first language. > > Recent discussion about property behaviours reminded me of

Re: [swift-evolution] [Pitch] Tuple Destructuring in Parameter Lists

Comments below > Am 05.05.2016 um 20:22 schrieb Dennis Weissmann via swift-evolution > : > > Following a short discussion with positive feedback on > [swift-users](http://thread.gmane.org/gmane.comp.lang.swift.user/1812 >

Re: [swift-evolution] Idea: Allow/require "let" in property setter name declarations

Comments below > Am 06.05.2016 um 13:48 schrieb Haravikk via swift-evolution > : > > Actually a setter has more in common with a function, in which case the let > implicit, the difference is that a setters type is also implicit. In fact, > you don’t even need to

Re: [swift-evolution] Dropping NS Prefix in Foundation

David has articulated what I couldn't quite put my finger on, and I agree. This also comes around to something I probably missed elsewhere in the discussion- but is the proposal to make NS classes just look like thus don't have NS in Swift? Or is it to write Swift versions of those classes that

Re: [swift-evolution] Should we rename "class" when referring to protocol conformance?

>>The primary reasons I can think of for creating reference types with >>value >>semantics are avoiding copying everything all the time or using >>inheritance. (I >>could also list pre-existing types here but am not as concerned with >>those) >> >>

Re: [swift-evolution] [Pitch] alternative multiline string literals

Added details about the prototype. // This code sample and prototype implementation (implemented in patch against the 3.0 // branch of the swift compiler) explores a possible syntax based on ideas discussed in // the swift-evolution mailing list at //

Re: [swift-evolution] Should we rename "class" when referring to protocol conformance?

> On May 7, 2016, at 10:39 PM, Dave Abrahams wrote: > > > on Sat May 07 2016, Tyler Fleming Cloutier > wrote: > >>> On May 7, 2016, at 12:52 PM, Dave Abrahams wrote: >>> >>> >>> on Fri May 06 2016, Tyler Fleming

Re: [swift-evolution] Dropping NS Prefix in Foundation

> It’s not a goal to rewrite Foundation from scratch in Swift. All Swift apps > that are running out there today are in fact using a combination of Swift, > Objective-C, C, C++, various flavors of assembly, and more. The goal is to > present the existing API of Foundation in a way that fits in

Re: [swift-evolution] Should we rename "class" when referring to protocol conformance?

on Sat May 07 2016, Andrew Trick wrote: > On May 7, 2016, at 2:04 PM, Dave Abrahams wrote: > > 2. Value types are not "pure" values if any part of the aggregate > contains a > reference whose type does not have value semantics. > > Then

Re: [swift-evolution] Should we rename "class" when referring to protocol conformance?

on Sat May 07 2016, Matthew Johnson wrote: > On May 7, 2016, at 4:04 PM, Dave Abrahams wrote: > > on Sat May 07 2016, Matthew Johnson wrote: > > I've been thinking about this further and can now state my position > more > clearly > and

Re: [swift-evolution] Should we rename "class" when referring to protocol conformance?

on Sat May 07 2016, Matthew Johnson wrote: >> >> You haven't answered this question. How would you use this protocol? > > I think the best example was given by Andy when discussing pure > functions. Maybe I want to write a generic function and ensure it is > pure. I can only do this if I