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

I’ve assembled a gist to summarise the main proposals of this thread. https://gist.github.com/johnno1962/5c325a16838ad3c73e0f109a514298bf At the moment there seem to be four proposals for multi-line strings: 1) Bent’s proposal for continuation quotes where if a conventional string does not close

Re: [swift-evolution] [Review] SE-0085: Package Manager Command Names

I agree with the review feedback so far, it's a good proposal. But just as David mentioned, I think a `spm` command, which would just be an alias for `swift package` would work really well. `spm build`, `spm test` all feel very in line with existing tools like gem, npm, pod etc. I think those ~3 le

Re: [swift-evolution] NSRange and Range

> On May 9, 2016, at 11:23 PM, David Hart wrote: > > Why wouldn't it completely eliminate NSRange? Because NSRange has a different representation than Range (start+length vs. start/end), a pointer-to-NSRange has to come in as Unsafe(Mutable)Pointer rather than Unsafe(Mutable)Pointer>. It’s t

Re: [swift-evolution] NSRange and Range

Why wouldn't it completely eliminate NSRange? Are you thinking of NSNotFound? Could we migrate those APIs to return an Optional Range? > On 10 May 2016, at 05:49, Douglas Gregor wrote: > > >> On May 8, 2016, at 2:10 PM, David Hart via swift-evolution >> wrote: >> >> Hello Swift-Evolution, >

Re: [swift-evolution] [Review] SE-0085: Package Manager Command Names

>* What is your evaluation of the proposal? +1 This proposal makes the package manager a first-class tool, instead of a set of command options. >* Is the problem being addressed significant enough to warrant a change to > Swift? It should be addressed before it goes public. >* Do

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

> On May 9, 2016, at 4:07 PM, Matthew Johnson wrote: > > I’m also interested in your feedback on whether a proposal around indirect is > something worth pursuing right now or whether that is something that should > wait until after Swift 3. I’m not prepared to champion this for Swift 3, I thi

Re: [swift-evolution] [Proposal] More lenient subscript methods over Collections

Yes, I feel like 'within' is much better than 'bounded'. How about such changes in proposal: a[bounded: -1 ..< 5] --> a[within: -1 ..< 5] (or a[inside: -1 ..< 5] ) a[optional: 0 ..< 5] --> a[checking: 0 ..< 5] a[optional: 5]--> a[checking: 5] ? On 10.05.2016 6:27, Patrick Smith

Re: [swift-evolution] [Proposal] More lenient subscript methods over Collections

Sounds good for me. How about: a[bounded: -1 ..< 5] --> a[within: -1 ..< 5] (or a[inside: -1 ..< 5] ) a[optional: 0 ..< 5] --> a[checking: 0 ..< 5] a[optional: 5]--> a[checking: 5] ? On 10.05.2016 4:29, Brent Royal-Gordon wrote: lenient -> keep "lenient:" ? "requested:" ? "opti

Re: [swift-evolution] Move where clause to end of declaration

> On May 2, 2016, at 12:16 AM, David Hart via swift-evolution > wrote: > > Hello swift-evolution, > > I took the pitch originally from Developer to move the where clause out of > the generic parameter list, with improvements brought up by Pyry Jahkola, and > wrote a proposal for it. I opened

Re: [swift-evolution] NSRange and Range

> On May 8, 2016, at 2:10 PM, David Hart via swift-evolution > wrote: > > 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 betwee

Re: [swift-evolution] [Review] SE-0085: Package Manager Command Names

* What is your evaluation of the proposal? These sound great! +1. Subcommands, even nested ones like `swift package init`, are more solid and easier to remember. * Is the problem being addressed significant enough to warrant a change to Swift? Yes, I think establishing a clear system is importan

Re: [swift-evolution] [Proposal] More lenient subscript methods over Collections (was: [Proposal] Safer half-open range operator)

I like the idea of the of the bounded subscript, however the optional one I feel could be used for clumsy code. .first and .last have value, but once you start stepping several arbitrary indices in, then that code is likely fragile? I can think of ‘within’, ‘inside’ and ‘intersecting’ as alter

Re: [swift-evolution] [Review] SE-0074: Implementation of Binary Search functions

> On May 9, 2016, at 9:48 PM, Joe Groff via swift-evolution > wrote: > >> >> On May 9, 2016, at 6:23 PM, Brent Royal-Gordon via swift-evolution >> wrote: >> >>> * Operations that depend on sorted-ness and use binary predicates should >>> not be available on all Collections; they're too easy

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0086: Drop NS Prefix in Swift Foundation

Got it. In that case, count me in as +1 for most of the proposal but -1 on AttributedString and its ilk. I agree with you and others that types which are slated to receive the URL/NSURL treatment shouldn't go through an interim renaming dance. On Mon, May 9, 2016 at 20:53 Brent Royal-Gordon wrote

Re: [swift-evolution] [Review] SE-0074: Implementation of Binary Search functions

> On May 9, 2016, at 6:23 PM, Brent Royal-Gordon via swift-evolution > wrote: > >> * Operations that depend on sorted-ness and use binary predicates should >> not be available on all Collections; they're too easy to misuse, >> they're hard to name well, and as Nicola Salmoria has noted, they >>

Re: [swift-evolution] [Review] SE-0086: Drop NS Prefix in Swift Foundation

On May 9, 2016, at 7:38 PM, Rod Brown via swift-evolution wrote: > > I am uncertain about the NSCoding proposition as it is not a generic concept > that is platform agnostic. It is a baked in, Objective-C, Apple-only paradigm > that seems to me should retain it’s NS prefix. Plus, NSCoding has

Re: [swift-evolution] [Review] SE-0074: Implementation of Binary Search functions

>> Proposal: >> >> >> https://github.com/apple/swift-evolution/blob/master/proposals/0074-binary-search.md >> >> > On May 6, 2016, at 5:16 PM, Dave Abrahams via swift-evolution > wrote: > > I am posti

Re: [swift-evolution] [Pitch] Reducing the bridging magic in dynamic casts

> On May 9, 2016, at 2:28 PM, Adrian Zubarev via swift-evolution > wrote: > > >> Right, you'd need to do NSString(string) as AnyObject to explicitly bridge. > > Okay great I'm fine with that. :) > >> The @objc-ness of AnyObject is more or less an implementation detail. On >> Darwin platfor

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0086: Drop NS Prefix in Swift Foundation

> Unless I'm mistaken, NSURL is not among the types being renamed in this > proposal? It is not, because it's already receiving a value-type equivalent. But types like `NSAttributedString`, which the Foundation team eventually intends to provide value-type equivalents for, *are* in the proposal

Re: [swift-evolution] [Proposal] More lenient subscript methods over Collections (was: [Proposal] Safer half-open range operator)

> lenient -> keep "lenient:" ? "requested:" ? "optional:"? `checking:`, to indicate that the index will be checked before it's used? -- Brent Royal-Gordon Architechies ___ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/

Re: [swift-evolution] [Review] SE-0074: Implementation of Binary Search functions

> * Operations that depend on sorted-ness and use binary predicates should > not be available on all Collections; they're too easy to misuse, > they're hard to name well, and as Nicola Salmoria has noted, they > would not make any sense at all for a Set. > > * They should be scoped to a kind of

Re: [swift-evolution] [Review] SE-0086: Drop NS Prefix in Swift Foundation

> Proposal link: > > https://github.com/apple/swift-evolution/blob/master/proposals/0086-drop-foundation-ns.md > > > Reply text > >> What is your evaluation of the proposal? > +1 to all except renaming

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0086: Drop NS Prefix in Swift Foundation

Unless I'm mistaken, NSURL is not among the types being renamed in this proposal? On Mon, May 9, 2016 at 19:06 Charles Srstka via swift-evolution < swift-evolution@swift.org> wrote: > I’m afraid I generally have to agree with this criticism. For types like > NSURL which would make sense to become

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0086: Drop NS Prefix in Swift Foundation

I’m afraid I generally have to agree with this criticism. For types like NSURL which would make sense to become value types in the future, dropping the prefix does seem as if it would put constraints on future growth. I do think the enum hoisting is great, though, and if it were in a separate p

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0086: Drop NS Prefix in Swift Foundation

> • What is your evaluation of the proposal? I support the enum hoisting and case renaming, but not the dropping of the "NS" prefix quite this widely, for several reasons: 1. I agree with the critique that "NSCoder" and its ilk should retain their "NS" prefix because they represent someth

Re: [swift-evolution] Modify optional method semantics for swift

Sent from my iPad > On May 9, 2016, at 5:53 PM, Rod Brown wrote: > > Response inline > > >> On 10 May 2016, at 8:28 AM, Matthew Johnson wrote: >> >> >>> On May 9, 2016, at 5:13 PM, Rod Brown via swift-evolution >>> wrote: >>> >>> The problem then becomes how do we model such optimizati

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

> On May 9, 2016, at 1:03 PM, Andrew Trick wrote: > > >> On May 9, 2016, at 8:34 AM, Matthew Johnson > > wrote: >> >>> I would prefer to wait until indirect structs and improved CoW support have >>> had more discussion. >> >> I've been thinking a lot about Dave

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

> On May 8, 2016, at 1:51 AM, Dave Abrahams wrote: > > > 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 n

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

> On May 8, 2016, at 1:19 AM, Dave Abrahams wrote: > > > 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

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

> On May 8, 2016, at 12:51 AM, Dave Abrahams wrote: > > > on Sat May 07 2016, Matthew Johnson > wrote: > >>> On May 7, 2016, at 3:03 PM, Dave Abrahams wrote: >>> >>> >>> on Sat May 07 2016, Matthew Johnson wrote: >>> This depends on the type. For t

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

> On May 8, 2016, at 1:02 AM, Dave Abrahams wrote: > > > 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 >> f

Re: [swift-evolution] Modify optional method semantics for swift

Response inline > On 10 May 2016, at 8:28 AM, Matthew Johnson wrote: > > >> On May 9, 2016, at 5:13 PM, Rod Brown via swift-evolution >> wrote: >> >> The problem then becomes how do we model such optimizations in Swift. >> Default methods, while useful for plenty of cases, don't work with

Re: [swift-evolution] [Review] SE-0086: Drop NS Prefix in Swift Foundation

> What is your evaluation of the proposal? +1 I already gave my opinion in the original discussion but I’ll summarise it here. I understand the fears that this proposal may inhibit us in the future from making the modifications that Foundation needs to make it feel more Swifty. But I think that

Re: [swift-evolution] Modify optional method semantics for swift

> On May 9, 2016, at 5:13 PM, Rod Brown via swift-evolution > wrote: > > This issue I see here, and one that people seem to often forget in > discussions on Swift a Evolution, is that optional methods aren't just used > to change a default value. Their existence often actually changes behavio

[swift-evolution] [Review] SE-0086: Drop NS Prefix in Swift Foundation

Hello Swift community, The review of SE-0086 "Drop NS Prefix in Swift Foundation" begins now and runs through May 16, 2016. The proposal is available here: https://github.com/apple/swift-evolution/blob/master/proposals/0086-drop-foundation-ns.md Reviews are an important part of the Swift evoluti

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

> On May 9, 2016, at 12:26 PM, Tony Parker wrote: > > Hi Matthew (and others), > >> On May 9, 2016, at 9:03 AM, Matthew Johnson via swift-evolution >> mailto:swift-evolution@swift.org>> wrote: >> >> >> >> Sent from my iPad >> >>> On May 9, 2016, at 10:49 AM, Zach Waldowski via swift-evolut

Re: [swift-evolution] Modify optional method semantics for swift

This issue I see here, and one that people seem to often forget in discussions on Swift a Evolution, is that optional methods aren't just used to change a default value. Their existence often actually changes behavior completely. Take for example UITableViewDelegate and its method "tableView:he

[swift-evolution] [Review] SE-0085: Package Manager Command Names

Hello Swift community, The review of "SE-0085: Package Manager Command Names" begins now and runs through May 12. The proposal is available here: https://github.com/apple/swift-evolution/blob/master/proposals/0085-package-manager-command-name.md Reviews are an important part of the Swi

Re: [swift-evolution] [RFC] UnsafeBytePointer API for In-Memory Layout

> Am 09.05.2016 um 23:04 schrieb Andrew Trick : > > >> On May 9, 2016, at 12:38 PM, Geordie Jay > > wrote: >> >> I read this proposal and I'm a bit unsure what its purpose would be: >> >> Basically you want to prevent UnsafePointer(UnsafePointer) >> conversions and/or

Re: [swift-evolution] [Pitch] Reducing the bridging magic in dynamic casts

> Right, you'd need to do NSString(string) as AnyObject to explicitly bridge. Okay great I'm fine with that. :) > The @objc-ness of AnyObject is more or less an implementation detail. On > Darwin platforms at least, AnyObject still has the magic ability to dispatch > to all @objc methods,

Re: [swift-evolution] [RFC] UnsafeBytePointer API for In-Memory Layout

> On May 9, 2016, at 1:16 PM, Joe Groff wrote: > > Andy, I think it's worth clarifying the primary purpose of this proposal. Our > main goal here is to provide a legal means for "type-punning" memory access. > Like C and C++, it's technically undefined behavior in Swift to cast an > UnsafePoi

Re: [swift-evolution] [RFC] UnsafeBytePointer API for In-Memory Layout

> On May 9, 2016, at 2:18 PM, Andrew Trick wrote: > >> >> On May 9, 2016, at 1:20 PM, Joe Groff wrote: >> >> Regarding the UnsafeBytePointer API: >> >>> struct UnsafeBytePointer : Hashable >>> , _Pointer { >>> >>> >>> let _rawValue: Builtin. >>> RawPointer >>> >>> >>> var hashValue:

Re: [swift-evolution] [RFC] UnsafeBytePointer API for In-Memory Layout

> On May 9, 2016, at 1:23 PM, Xiaodi Wu wrote: > > Along similar lines, with the indexing model change, isn't the following > outdated? Yes. Thanks. I’m working on updating both the proposal and implementation. -Andy > > ``` > extension UnsafeBytePointer : RandomAccessIndex { > typealias D

Re: [swift-evolution] [RFC] UnsafeBytePointer API for In-Memory Layout

> On May 9, 2016, at 1:20 PM, Joe Groff wrote: > > Regarding the UnsafeBytePointer API: > >> struct UnsafeBytePointer : Hashable, _Pointer { >> >> let _rawValue: Builtin.RawPointer >> >> var hashValue: Int {...} >> >> init(_ : UnsafePointer) >> init(_ : UnsafeMutablePointer) >> ini

Re: [swift-evolution] [RFC] UnsafeBytePointer API for In-Memory Layout

> On May 9, 2016, at 12:38 PM, Geordie Jay wrote: > > I read this proposal and I'm a bit unsure what its purpose would be: > > Basically you want to prevent UnsafePointer(UnsafePointer) > conversions and/or vice-versa? And you'd achieve this by replacing > UnsafePointer with UnsafeBytePointer

Re: [swift-evolution] [RFC] UnsafeBytePointer API for In-Memory Layout

Thanks for your patient clarification Joe. My understanding was that type punning == your example with T* -> Void* -> T* -> T. Assuming it's not, I now imagine you're talking about reinterpreting the layout of C structs and the like for some horrifically beautiful optimisation or low-level trick p

Re: [swift-evolution] [RFC] UnsafeBytePointer API for In-Memory Layout

> On May 9, 2016, at 1:25 PM, Geordie Jay wrote: > > So what's in it for us as Swift devs? > > It may be technically undefined behaviour (by that I think you mean there's > no real knowing what could happen), but it seems to be rampant throughout > pretty much all the C code I've come in cont

Re: [swift-evolution] [RFC] UnsafeBytePointer API for In-Memory Layout

So what's in it for us as Swift devs? It may be technically undefined behaviour (by that I think you mean there's no real knowing what could happen), but it seems to be rampant throughout pretty much all the C code I've come in contact with (I'm less familiar with C++). If we lose type informatio

Re: [swift-evolution] [RFC] UnsafeBytePointer API for In-Memory Layout

Along similar lines, with the indexing model change, isn't the following outdated? ``` extension UnsafeBytePointer : RandomAccessIndex { typealias Distance = Int func successor() -> UnsafeBytePointer func predecessor() -> UnsafeBytePointer func distance(to : UnsafeBytePointer) -> Int f

Re: [swift-evolution] [RFC] UnsafeBytePointer API for In-Memory Layout

Regarding the UnsafeBytePointer API: > struct UnsafeBytePointer : Hashable, _Pointer { > > let _rawValue: Builtin.RawPointer > > var hashValue: Int {...} > > init(_ : UnsafePointer) > init(_ : UnsafeMutablePointer) > init?(_ : UnsafePointer?) > init?(_ : UnsafeMutablePointer?) > >

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

Sorry--I'm not at all saying that I think there's a problem. As you asked, I attempted to supply a contrived use case for a typealias declared in a protocol having a more restricted scope than the protocol itself. I was asking if it would be supported as part of your proposal. On Mon, May 9, 2016

Re: [swift-evolution] [RFC] UnsafeBytePointer API for In-Memory Layout

> On May 9, 2016, at 12:38 PM, Geordie Jay via swift-evolution > wrote: > > I read this proposal and I'm a bit unsure what its purpose would be: > > Basically you want to prevent UnsafePointer(UnsafePointer) > conversions and/or vice-versa? And you'd achieve this by replacing > UnsafePointer

Re: [swift-evolution] [Pitch] Reducing the bridging magic in dynamic casts

> On May 6, 2016, at 2:04 AM, Adrian Zubarev via swift-evolution > wrote: > > The ugly NSError pattern could be rewritten and migrated to: > > do { >try something() > } catch let error { >handle(error `bridge` NSError) > } > > Is such a change complicated, what do you think? I’ve made

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

I don’t see a problem with your example. Because the typealias is fileprivate, it doesn’t exist as far as MyUsefulType is concerned. The same way the following works: ``` class Base { private typealias Foo = Int func foo() -> Int { return Foo() } } ``` Other file: ``` class

Re: [swift-evolution] [RFC] UnsafeBytePointer API for In-Memory Layout

I’m sympathetic to the elimination of UnsafePointer as general shorthand for an arbitrary pointer, but I lose the plot of this very long proposal. It seems to me that this increases API surface, yet everything I could do before, I could still do; it just involves more typing. What exactly does t

Re: [swift-evolution] [RFC] UnsafeBytePointer API for In-Memory Layout

I read this proposal and I'm a bit unsure what its purpose would be: Basically you want to prevent UnsafePointer(UnsafePointer) conversions and/or vice-versa? And you'd achieve this by replacing UnsafePointer with UnsafeBytePointer that has no bound pointer type? In one sense the change seems fin

Re: [swift-evolution] [Pitch] Reducing the bridging magic in dynamic casts

> On May 6, 2016, at 12:04 AM, Adrian Zubarev via swift-evolution > wrote: > > Definitely a welcome change from me (+1). But this proposal makes me curious > about the impact on the `AnyObject` protocol? > > let string = "foo" > let nsString = string as AnyObject > nsString.dynamicType // _NS

Re: [swift-evolution] [Pitch] Consistent bridging for NSErrors at the language boundary

I would support this - but I don’t feel like I have the experience yet to vet the proposal. I agree that the error handling is still something I feel like isn’t as smooth as it should be yet. I’ll try to take a longer look at this today. Thanks for the reminder. Best, Josh On May 9, 2016, at 1

Re: [swift-evolution] [Pitch] Consistent bridging for NSErrors at the language boundary

Anyone have any thoughts, opinions, etc. on this? I find it kind of strange that I’ve received off-list feedback from within Apple, but so far it’s been generally ignored publicly on the list. Surely I’m not the only one who cares about the lack of parity between NSError and ErrorProtocol. Char

Re: [swift-evolution] [Pitch] Requiring proactive overrides for default protocol implementations.

The pitch was not warmly received. If you want to pick it up and run with it, go ahead. https://gist.github.com/erica/fc66e6f6335750d737e5512797e8284a I have a running list of dead or deferred ideas here: https://gist.github.com/

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

> On May 9, 2016, at 8:34 AM, Matthew Johnson wrote: > >> I would prefer to wait until indirect structs and improved CoW support have >> had more discussion. > > I've been thinking a lot about Dave's desire to "mandate" that value semantic > types must be value types and allowing us to use re

Re: [swift-evolution] Feature proposal: Range operator with step

> Am 03.05.2016 um 13:42 schrieb Hans Huck via swift-evolution > : > > Thorsten Seitz via swift-evolution writes: >> >> -1 >> >> I don't see the need for special syntax where a method can be easily used > and is more general. >> >> -Thorsten >> > > That, dear Thorsten, is a non-argument.

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

On 5/9/16 14:01, Joe Groff via swift-evolution wrote: > >> On May 8, 2016, at 10:30 PM, Morten Bek Ditlevsen wrote: >> >> This would be an excellent solution to the issue. >> Do you know if there are any existing plans for something like the >> DecimalLiteralConvertible? > > Not that I know of.

Re: [swift-evolution] [Pitch] Requiring proactive overrides for default protocol implementations.

Hi Erica, could you clarify, what is state of this proposal and your plans regarding it? I believe we certainly should make Swift more explicit regarding what methods in type are required by the conformed protocol and what methods are required(and which are 'optional') in protocol extensions.

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

Hi Matthew (and others), > On May 9, 2016, at 9:03 AM, Matthew Johnson via swift-evolution > wrote: > > > > Sent from my iPad > >> On May 9, 2016, at 10:49 AM, Zach Waldowski via swift-evolution >> wrote: >> >> This is exactly the way I see it, too. Many people are coming to Swift >> and

Re: [swift-evolution] [Accepted] SE-0072: Fully eliminate implicit bridging conversions from Swift

> On May 9, 2016, at 10:12 AM, Jacob Bandes-Storch wrote: > > Maybe I made a mistake when testing, but I thought I was able to convert a > negative Int to a large UInt by going through NSNumber (it didn't return nil > from the as? cast). It's less bad if you're able to do this explicitly. It

Re: [swift-evolution] [Accepted] SE-0072: Fully eliminate implicit bridging conversions from Swift

Maybe I made a mistake when testing, but I thought I was able to convert a negative Int to a large UInt by going through NSNumber (it didn't return nil from the as? cast). On Mon, May 9, 2016 at 10:11 AM Joe Groff via swift-evolution < swift-evolution@swift.org> wrote: > > > On May 7, 2016, at 1:2

Re: [swift-evolution] [Accepted] SE-0072: Fully eliminate implicit bridging conversions from Swift

> On May 7, 2016, at 1:23 PM, Zach Waldowski via swift-evolution > wrote: > > On Fri, May 6, 2016, at 11:20 PM, Charles Srstka via swift-evolution wrote: >> let int = num as? Int // 5 >> let float = num as? Float // 5 >> let int32 = num as? Int32 // nil! > That specific behavior with Int32 seem

Re: [swift-evolution] [Accepted] SE-0072: Fully eliminate implicit bridging conversions from Swift

> On May 6, 2016, at 8:20 PM, Charles Srstka wrote: > >> On May 6, 2016, at 3:15 PM, Joe Groff via swift-evolution >> wrote: >> >>> On May 6, 2016, at 12:21 PM, Jacob Bandes-Storch via swift-evolution >>> wrote: >>> >>> Does this affect the ability to use "x as? Int" (and similar) when x i

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

> On May 8, 2016, at 10:30 PM, Morten Bek Ditlevsen wrote: > > This would be an excellent solution to the issue. > Do you know if there are any existing plans for something like the > DecimalLiteralConvertible? Not that I know of. Someone would have to submit a proposal. > > Another thought:

Re: [swift-evolution] Modify optional method semantics for swift

That’s a very interesting approach. My approach was intended to facilitate the transition from @objc optionals. However, your proposal is good for me too. > El 9 may 2016, a las 18:54, Vladimir.S escribió: > > IMO if a class conforms to some protocol, this *should* means that methods of > the

Re: [swift-evolution] Modify optional method semantics for swift

IMO if a class conforms to some protocol, this *should* means that methods of the protocol is implemented exactly inside that class(or in superclasses). In your suggestion, *optional* methods will be implemented "somewhere" outside of conformed class. IMO protocol should not depend on any defau

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

In addition to the points that have been raised, it's my opinion that some of the stuff in Foundation should really be implemented in the stdlib in the future (for example, collections that weakly reference their items, and a native binary data blob type). The fact that the delineation between what

Re: [swift-evolution] [Pitch] Reducing the bridging magic in dynamic casts

> On May 6, 2016, at 7:24 PM, Jose Cheyo Jimenez wrote: > > Hi Joe, > > Would I still be able to cast an AnyObject to a String or Array etc? You would do so via constructors rather than using `as?`, something like String(bridging: object). -Joe > I am thinking about working with JSON files

Re: [swift-evolution] Modify optional method semantics for swift

Rationale: As a everybody knows, “optional” keyword is present in swift solely to maintain compatibility with objective-c protocols. Optional methods in protocols are neither a swift capability, nor a wanted one. In fact, proposal [0070] intends to begin the transition to an optionals-free lang

Re: [swift-evolution] unums in Swift?

Sent from my iPad > On May 9, 2016, at 10:44 AM, Stephen Canon wrote: > > What do you find interesting about them? As an app developer I'm not even remotely a numerics expert so my understanding is probably superficial. The link I posted gave me the impression that they would avoid the err

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

Sent from my iPad > On May 9, 2016, at 10:49 AM, Zach Waldowski via swift-evolution > wrote: > > This is exactly the way I see it, too. Many people are coming to Swift > and immediately decrying the language because it doesn't have built-in > support for regex, date parsing, collections beyon

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

This is exactly the way I see it, too. Many people are coming to Swift and immediately decrying the language because it doesn't have built-in support for regex, date parsing, collections beyond the built-in 3, etc., when it in fact has a rich tapestry of things from Foundation. While I agree with

Re: [swift-evolution] unums in Swift?

What do you find interesting about them? I haven’t spent more than a few hours reading about them (and the definition of “unum” seems to be a moving target, so I’m not sure that it would have been useful to study them further), but my rough thoughts are: - SORN are a cute alternative to interva

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

Sent from my iPad > On May 9, 2016, at 3:01 AM, Andrew Trick wrote: > > >>> On May 7, 2016, at 11:51 PM, Dave Abrahams wrote: >>> >>> Does Array have value semantics then only if T also has value >>> semantics? >> >> This is a great question; I had to rewrite my response four times. >> >>

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

Sent from my iPad > On May 9, 2016, at 3:01 AM, Andrew Trick wrote: > > >>> On May 7, 2016, at 11:51 PM, Dave Abrahams wrote: >>> >>> Does Array have value semantics then only if T also has value >>> semantics? >> >> This is a great question; I had to rewrite my response four times. >> >>

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

If I am coming to Swift as a new user (possibly as a first language, even) without any prior Objective-C experience and very little knowledge of the long history of Foundation, the NS prefix, etc, this is going to feel worse than a little out of place - it will feel downright wrong, broken, and

Re: [swift-evolution] [Pitch] Require tuple conversions to be explicit when labels don't match

Hmm. I'm also having second thoughts about that Fix-It. I wonder if the "fix" that's automatically provided is little more than "press here to make the red thingy go away and do nothing else." The way I see it, if the error is restricted to mismatched labels, then the presumption is that someone g

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

I have mixed feelings about this; while I agree that prefixing names isn’t a good fit for Swift, at the same time that’s kind of the appeal of it. Assuming that Foundation will eventually be replaced by a more Swift-like alternative, or will be incrementally reworked, I think it makes sense for

Re: [swift-evolution] [Pitch] Require tuple conversions to be explicit when labels don't match

Two more points to be made: First, there are types where current behavior allowing implicit erasure and affixing of labels is a definite win. Consider: ``` typealias CartesianCoordinate = (x: Int, y: Int) let c: CartesianCoordinate = (0, 1) print(c.x) typealias PolarCoordinate = (r: Double, thet

Re: [swift-evolution] [Pitch] Require tuple conversions to be explicit when labels don't match

Also--I didn't read this carefully enough in your initial example--I disagree that either (left: Int, right: Int) to (Int, Int) or vice versa should require explicit casting, and I think previous conversations on the topic showed that at least some on the list felt the same way. Mismatched labels,

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

On Mon, May 9, 2016 at 2:31 AM, David Hart wrote: > > On 09 May 2016, at 09:16, Xiaodi Wu wrote: > > One more thought here: > > It goes a long way to say "typealiases in protocols are to have the same > semantics as aliases outside protocols." I'm inclined to agree on that, but > I haven't thoug

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

On Mon, May 9, 2016 at 2:33 AM, David Hart wrote: > > On 09 May 2016, at 09:30, Xiaodi Wu wrote: > > Great, I hope this proposal finds much success with the community. > > One more thing: your title makes mention of protocol extensions, but > protocol extensions are mentioned nowhere else. Pleas

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

On Mon, May 9, 2016 at 2:47 AM, Patrick Smith wrote: > My point isn’t about what Swift 4 could be, but a timeline for something > new to be made. Swift 3 is almost here. Personally I think Foundation, > while venerable for its time, is a poor fit for the new world of Swift. > Anyway, I’ll let the

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

> On May 7, 2016, at 11:51 PM, Dave Abrahams wrote: > >> Does Array have value semantics then only if T also has value >> semantics? > > This is a great question; I had to rewrite my response four times. > > In my world, an Array always has value semantics if you respect the > boundaries of el

Re: [swift-evolution] [Pitch] Require tuple conversions to be explicit when labels don't match

Hmm, not as sure about that one. To my mind it's a clear expression of intent there. You're saying you know what the labels are and you're choosing not to repeat them. I think it should be on you if you express that intent and you're just plain wrong. On Mon, May 9, 2016 at 2:32 AM, Jacob Bandes-

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

My point isn’t about what Swift 4 could be, but a timeline for something new to be made. Swift 3 is almost here. Personally I think Foundation, while venerable for its time, is a poor fit for the new world of Swift. Anyway, I’ll let the others speak as they had valid arguments. > On 9 May 2016,

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

> On 09 May 2016, at 09:30, Xiaodi Wu wrote: > > Great, I hope this proposal finds much success with the community. > > One more thing: your title makes mention of protocol extensions, but protocol > extensions are mentioned nowhere else. Please include details on typealiases > in protocol ex

Re: [swift-evolution] [Pitch] Require tuple conversions to be explicit when labels don't match

... and one might also want to require labels when passing values *to* a labeled tuple: func foo() -> (left: Int, right: Int) { return (3, 4) // error: conversion between tuple types '(Int, Int)' and '(left: Int, right: Int)' requires explicit 'as' operator } I've personally been

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

> On 09 May 2016, at 09:16, Xiaodi Wu wrote: > > One more thought here: > > It goes a long way to say "typealiases in protocols are to have the same > semantics as aliases outside protocols." I'm inclined to agree on that, but I > haven't thought it totally through. > > Now, I can have priva

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

Great, I hope this proposal finds much success with the community. One more thing: your title makes mention of protocol extensions, but protocol extensions are mentioned nowhere else. Please include details on typealiases in protocol extensions within the text or remove it altogether from the prop

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

> On 09 May 2016, at 08:53, Xiaodi Wu wrote: > > And to clarify, FWIW, I think it'd be wonderful to implement this feature, > and I share your sense that sometimes conversations on this list get a little > sidetracked. My comments are not meant to suggest that this is not a good > feature; ra

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

Btw, in c# we have @ to drop escapes: @"c:\Docs\Source\a.txt" // rather than "c:\\Docs\\Source\\a.txt" @"""Ahoy!"" cried the captain." // "Ahoy!" cried the captain. and(!) also as 'marker' that allows to use keywords as identifiers: class @class { public static void @static(bool @bool) {..} .

Re: [swift-evolution] [Pitch] Require tuple conversions to be explicit when labels don't match

A sensible solution, IMO. Error with Fix-It when attempting to convert implicitly between tuples with mismatched labels. On Mon, May 9, 2016 at 01:47 Jacob Bandes-Storch via swift-evolution < swift-evolution@swift.org> wrote: > There was some previous discussion under "[Discussion] Enforce argume

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

One more thought here: It goes a long way to say "typealiases in protocols are to have the same semantics as aliases outside protocols." I'm inclined to agree on that, but I haven't thought it totally through. Now, I can have private typealiases outside protocols. Could I have private typealiases

  1   2   >