Re: [swift-evolution] [Pitch][stdlib] Command Line Option Parsing & Help

> On Aug 17, 2016, at 9:41 AM, Will Field-Thompson via swift-evolution > wrote: > > I think it would be great to have something like this (at least the > "Arguments" component) as part of the standard distribution — maybe as a > corelib rather than as part of the standard library. Seeing as t

Re: [swift-evolution] [Pitch][stdlib] Command Line Option Parsing & Help

If we introduce a new API to parse command-line arguments now, we're committing to support it for a very long time. It seems to me that this is the kind of thing that could evolve with the language, so I'm not really in favor of fixing an implementation now. Imagine this hypothetical scenario:

[swift-evolution] try? shouldn't work on non-method-call

Hi all, Yesterday I tried this code: func couldFailButWillNot() throws -> Any { return 42 } if let a = try? couldFailButWillNot() as? Int { print(a) } And was surprised that the output was Optional(42) on both Swift 2 and Swift 3. I always have the impression that when a variable is re

Re: [swift-evolution] InternalString class for easy String manipulation

> In Félix’s case, I would expect to have to ask for a mail-friendly > representation of his name, just like you have to ask for a > filesystem-friendly representation of a filename regardless of what the > internal representation is. Just because you are using UTF-8 as the internal > format, i

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

While I am a big fan of union types, I think an enum based solution for your problem is not too bad. Just use the enums only for the intersection results, i.e. enum Intersection1d { case point(Point) case line(Line) } Same for Intersection2d, but adding case plane(Plane) and so on for h

Re: [swift-evolution] Swift Package Manager 3.0 Project Status

Our stated plans here, and there hasn't been any change, is to leave building for iOS to Xcode. We have (very) limited support for doing that from SwiftPM via generated projects, and it would be nice to see that support deepen. However, there are a lot of limits to that approach and for somethin

Re: [swift-evolution] Calling a Specific Implementation

> On 18 Aug 2016, at 02:57, John McCall wrote: > > Being able to bypass another class's overrides and jump to a specific > superclass implementation on an arbitrary method call is badly > encapsulation-breaking, and I can't think of any OO language with first-class > support for it besides C++

Re: [swift-evolution] Calling a Specific Implementation

> On Aug 17, 2016, at 5:46 PM, Jonathan Hull via swift-evolution > wrote: > > I believe this affects the ABI (especially the second part), but if not, let > me know and we can talk about it in phase 2... > > There are times where you would like to call a specific implementation of a > method.

Re: [swift-evolution] Allow trailing comma in guard, if-let, et al

> On 18 Aug 2016, at 00:13, Rick Mann wrote: > > Is there any reason Swift can't allow a trailing comma in constructs like > this: > > guard >let a = ..., >let b = ..., >let c = ..., > else > { > } > > doing so makes it a bit easier to rearrange lines, and is similar to the > trai

Re: [swift-evolution] Swift Package Manager 3.0 Project Status

It sounds like we may not get any heads up about any work on that level of integration: https://twitter.com/jckarter/status/766072626624073729 Which I guess also brings up the question of whether or not it will be done in public (which might also be unanswerable). -- Keith Smiley On 08/17, T.J.

[swift-evolution] Calling a Specific Implementation

I believe this affects the ABI (especially the second part), but if not, let me know and we can talk about it in phase 2... There are times where you would like to call a specific implementation of a method. One of the most common is calling super from a subclass, but you may want to do simila

Re: [swift-evolution] Swift Package Manager 3.0 Project Status

What are the near term plans–if there are any–for supporting iOS? I made the mistake of assuming support was a couple months away at most when the package manager was announced. I plan to port my iOS/Mac frameworks over as soon as I can. TJ On Wed, Aug 17, 2016 at 6:44 PM, Daniel Dunbar via swift

[swift-evolution] Allow trailing comma in guard, if-let, et al

Is there any reason Swift can't allow a trailing comma in constructs like this: guard let a = ..., let b = ..., let c = ..., else { } doing so makes it a bit easier to rearrange lines, and is similar to the trailing comma allowed inside array and dictionary definitions: let a = [ 1,

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

These are a couple comments from Chris Lattner that come to mind "FWIW, this has been discussed before on swift-evolution. Adding them isn’t out of the question, but it is a lot more complicated than it looks for the type checker." "Here is my concern: Swift enums should be good enough that we

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

> On 11 Aug 2016, at 07:18, Chris Lattner via swift-evolution > wrote: > > >> On Aug 10, 2016, at 8:15 PM, Xiaodi Wu via swift-evolution >> mailto:swift-evolution@swift.org>> wrote: >> >> I don't know if the core team feels differently now with respect to Swift 4, >> but union types are lis

[swift-evolution] Swift Package Manager 3.0 Project Status

Hi everyone, The package manager was a brand new project released with open source Swift, and we have made significant progress as part of Swift 3.0. Starting from that humble beginning we now estimate there are around 3,500 Swift Packages on GitHub (*), with more and more showing up every day.

Re: [swift-evolution] InternalString class for easy String manipulation

On Wed, Aug 17, 2016 at 5:03 PM, Kenny Leung via swift-evolution < swift-evolution@swift.org> wrote: > > > On Aug 17, 2016, at 1:57 PM, William Sumner > wrote: > > > You may be interested in this article by Mike Ash, which gives a > rationale for the String API, including why indexes aren't simpl

Re: [swift-evolution] InternalString class for easy String manipulation

> On Aug 17, 2016, at 1:57 PM, William Sumner wrote: > You may be interested in this article by Mike Ash, which gives a rationale > for the String API, including why indexes aren't simple integers: > https://www.mikeash.com/pyblog/friday-qa-2015-11-06-why-is-swifts-string-api-so-hard.html Tha

Re: [swift-evolution] PITCH: New :== operator for generic constraints

Inline On 17.08.2016 21:36, Charles Srstka wrote: On Aug 17, 2016, at 12:02 PM, Vladimir.S via swift-evolution mailto:swift-evolution@swift.org>> wrote: On 17.08.2016 13:00, Boris Wang via swift-evolution wrote: The problem is that: protocol should not be a type, but it is a type sometime and

Re: [swift-evolution] [Swift4][Pitch] Control struct layout with @layout, @offset, @order

> On Aug 17, 2016, at 11:37 AM, Mark Lacey via swift-evolution > wrote: > > >> On Aug 17, 2016, at 11:28 AM, Russ Bishop via swift-evolution >> mailto:swift-evolution@swift.org>> wrote: >> >> I wanted to gauge the interest in supporting explicit struct layout and >> alignment. >> >> The ge

Re: [swift-evolution] InternalString class for easy String manipulation

Looking at the String reference again, I see that Swift.String is subscriptable. Also, I was able to write my “split” function without using subscripting at all: public extension String { public func split(_ pattern :String) -> [String] { var results = [String]() var remainin

Re: [swift-evolution] InternalString class for easy String manipulation

> On Aug 17, 2016, at 2:34 PM, Kenny Leung via swift-evolution > wrote: > > >> William Sumner says: >> Can you be more specific about the improvements you’d like to see? Based on >> an earlier message, you want to be able to use subscripting on strings to >> retrieve visual glyphs, but you c

Re: [swift-evolution] PITCH: New :== operator for generic constraints

> On Aug 17, 2016, at 3:25 PM, Slava Pestov wrote: > > I’m not the Word of God, nor am I on the core team, I just work here and > stating my opinions on the matter ;-) Working at Apple is close enough. ;-) Charles___ swift-evolution mailing list swif

Re: [swift-evolution] InternalString class for easy String manipulation

> William Sumner says: > Can you be more specific about the improvements you’d like to see? Based on > an earlier message, you want to be able to use subscripting on strings to > retrieve visual glyphs, but you can do this now via the .characters property, > which presents a view of the string’

Re: [swift-evolution] PITCH: New :== operator for generic constraints

> On Aug 17, 2016, at 11:36 AM, Charles Srstka via swift-evolution > wrote: > >> On Aug 17, 2016, at 12:02 PM, Vladimir.S via swift-evolution >> mailto:swift-evolution@swift.org>> wrote: >> >> On 17.08.2016 13:00, Boris Wang via swift-evolution wrote: >>> The problem is that: >>> protocol sho

Re: [swift-evolution] PITCH: Return a subclass for a protocol method without the need for an associatedtype

> On Aug 17, 2016, at 10:18 AM, Vladimir.S via swift-evolution > wrote: > But yes, strictly speaking 'make()->Circle?' conforms to protocol requirement > 'make()->Shape?', it does returns 'Shape?', so I believe this should be > treated as conformance to MyShapeProtocol protocol. I agree this

Re: [swift-evolution] [Swift4][Pitch] Control struct layout with @layout, @offset, @order

Hi Russ, Keep in mind you can control layout of structs by defining them in C (using __attribute__((packed)) and so on), and using them as imported types in Swift. As Mark mentioned, we can add this later if we need it, so it’s probably out of scope for now. Slava > On Aug 17, 2016, at 11:28

Re: [swift-evolution] InternalString class for easy String manipulation

I would also like to understand the perceived problem for first time programmers. To me first time programmers would be working with string literals ("hello world"), string literals with values in them ("Hello /(name)"), doing basic string concat, using higher level API of string to do and find thi

Re: [swift-evolution] InternalString class for easy String manipulation

> On Aug 17, 2016, at 10:40 AM, Kenny Leung via swift-evolution > wrote: > > I understand that the most friendly approach may not be the most efficient, > but that’s not what I’m pushing for. I’m pushing for "does the thing people > would most commonly expect”. Take a first-time programmer wh

Re: [swift-evolution] InternalString class for easy String manipulation

I like a "view" based system when looking at a Unicode string. It lets you pick the view of string - defining how it is indexed - based on your needs. A view could be indexed by a human facing glyph, a particular Unicode encoding style, a decompose style, etc. I think that is powerful, useful, and

Re: [swift-evolution] InternalString class for easy String manipulation

> > On Aug 17, 2016, at 12:20 PM, Shawn Erickson wrote: > > As stated earlier it is 2016 I don’t like the tone attached to this statement. > I think the baseline should be robust Unicode support I don’t understand how anything I have pushed for would compromise robust Unicode support. > and

Re: [swift-evolution] InternalString class for easy String manipulation

I’m not sure what the current year of the Gregorian calendar has to do with strings. :P l8r Sean > On Aug 17, 2016, at 2:20 PM, Shawn Erickson via swift-evolution > wrote: > > As stated earlier it is 2016, I think the baseline should be robust Unicode > support and what we have in Swift is

Re: [swift-evolution] InternalString class for easy String manipulation

As stated earlier it is 2016, I think the baseline should be robust Unicode support and what we have in Swift is actually a fairly good way of dealing with it IMHO. I think new to development folks should have this as their baseline as well... not that we shouldn't make it as easy to work with as p

Re: [swift-evolution] InternalString class for easy String manipulation

It seems to me that UTF-8 is the best choice to encode strings in English and English-like character sets for storage, but it’s not clear that it is the most useful or performant internal representation for working with strings. In my opinion, conflating the preferred storage format and the best

Re: [swift-evolution] InternalString class for easy String manipulation

It's 2016, "the thing people would most commonly expect" impossible-to-screw-up Unicode support that's performance. Optimizing developer experience for beginning developers is just going to lead to software that screws up in situations the developer doesn't anticipate, as F+¬lix notes above. Zacha

Re: [swift-evolution] PITCH: New :== operator for generic constraints

> On Aug 17, 2016, at 12:02 PM, Vladimir.S via swift-evolution > wrote: > > On 17.08.2016 13:00, Boris Wang via swift-evolution wrote: >> The problem is that: >> protocol should not be a type, but it is a type sometime and not type >> sometime now. >> >> for exam: >> P.Type not same as T.Type >

Re: [swift-evolution] [Swift4][Pitch] Control struct layout with @layout, @offset, @order

> On Aug 17, 2016, at 11:28 AM, Russ Bishop via swift-evolution > wrote: > > I wanted to gauge the interest in supporting explicit struct layout and > alignment. > > The general idea would be to support attributes to create packed structs and > set alignment. It will be critical for certain

[swift-evolution] [Swift4][Pitch] Control struct layout with @layout, @offset, @order

I wanted to gauge the interest in supporting explicit struct layout and alignment. The general idea would be to support attributes to create packed structs and set alignment. It will be critical for certain kinds of interop and systems programming in pure Swift. I don’t know about you but I wan

Re: [swift-evolution] [Idea] Use optionals for non-optional parameters

> On Aug 17, 2016, at 11:59 PM, Tino Heth <2...@gmx.de> wrote: > > >> Let’s discuss something else. Actually there is an easy fix: make all >> functions accept optionals. I think this is a really bad idea > Indeed. > I don't think there is a good motivation to change the status quo: > You can'

Re: [swift-evolution] PITCH: Return a subclass for a protocol method without the need for an associatedtype

Although I see your point, and probably support, nothing prevents you from actually return Circle from make() but have return type defined as Shape. Actually you can even have both Shape and Circle returning make() if you fill this will be handy for you: class Shape {} // The protocol protoc

Re: [swift-evolution] PITCH: New :== operator for generic constraints

On 17.08.2016 13:00, Boris Wang via swift-evolution wrote: The problem is that: protocol should not be a type, but it is a type sometime and not type sometime now. for exam: P.Type not same as T.Type But you can declare a variable of type P. Protocol should be a contract only, no instances of

Re: [swift-evolution] [Pitch][stdlib] Command Line Option Parsing & Help

I think it would be great to have something like this (at least the "Arguments" component) as part of the standard distribution — maybe as a corelib rather than as part of the standard library. Seeing as this is certainly not in scope for phase 1 of Swift 4, maybe it would be better to start this a

Re: [swift-evolution] InternalString class for easy String manipulation

I understand that the most friendly approach may not be the most efficient, but that’s not what I’m pushing for. I’m pushing for "does the thing people would most commonly expect”. Take a first-time programmer who reads any (human) language, and that is what they would expect. Why couldn’t Stri

Re: [swift-evolution] InternalString class for easy String manipulation

I'd just like to leave it here that Microsoft called me "F+¬lix" in corporate communications this morning. I've never seen that variation before. If Microsoft used Swift, I would like this to be borderline impossible for them to screw up. :) Félix > Le 16 août 2016 à 21:27:54, Xiaodi Wu via sw

Re: [swift-evolution] Allow use of ; in anonymous closures

`in` is syntactic fluff to disambiguate the end of a parameter list and the start of the closure's body, not a statement. In that regard it needs no additional delimiters like semicolons. ~Robert Widmann 2016/08/17 8:38、Braeden Profile via swift-evolution のメッセージ: > Okay, I currently love cl

Re: [swift-evolution] [Idea] Use optionals for non-optional parameters

> Let’s discuss something else. Actually there is an easy fix: make all > functions accept optionals. I think this is a really bad idea Indeed. I don't think there is a good motivation to change the status quo: You can't "sugar away" everything; sometimes, you just have to write a line of code t

[swift-evolution] Allow use of ; in anonymous closures

Okay, I currently love closure syntax, but something doesn’t sit right with me. Why can’t I write… [6,5].map { n in; n+1 } …where there’s a semicolon after the parameter list? I think it looks better, and should at least be allowed (not required). _

[swift-evolution] PITCH: Return a subclass for a protocol method without the need for an associatedtype

Hi, I raised this issue a few months back and discussion has died out since. I’m raising this again to see if there are any objections before I submit a proposal. I have a class that conforms to a protocol which declares a method with a specific return type. In case I want to return a subclas

Re: [swift-evolution] [Discussion] Sortable Attribute

I think a first class sort descriptor style would robustly solve most complex sorting needs. It can deal with multiple sort dimensions, etc. which an attribute wouldn't really solve without language complexity. On Wed, Aug 17, 2016 at 1:12 AM David Rönnqvist wrote: > Haskell also has a `comparin

Re: [swift-evolution] Required Callback

Most of the cases I can think of for @required are for clean up mechanisms triggered by the closure and as such would only need to be called once. So in theory @once may be able to cover this case, in a sense I guess you could argue @once is just a subset of @required it would check it is exactly

Re: [swift-evolution] Required Callback

In this case the @required callback is something *all* implementations should use for the mentioned reasons (memory leaks etc) just to clarify :). *___* *James⎥Lead Hustler* *ja...@supmenow.com ⎥supmenow.com * *Sup* *Runway East * *10 Finsb

Re: [swift-evolution] [Idea] Use optionals for non-optional parameters

Thanks. Typed sentences can’t carry emotions. We all need to be extra careful ;) Let’s discuss something else. Actually there is an easy fix: make all functions accept optionals. I think this is a really bad idea because sometimes functions are designed to accept non-optionals. e.g. ``` func

Re: [swift-evolution] Required Callback

> On Aug 16, 2016, at 12:44 PM, James Campbell via swift-evolution > wrote: > > That sounds fair, the closure that function returns could trigger a runtime > warning when it detects the closure has be deallocated without being > triggered (or even mutliple times but ofc not the focus for this

Re: [swift-evolution] [Idea] Use optionals for non-optional parameters

Hi, I'd just like to voice my opinion similar to Xiaodi's that the short-circuit is going to create very confusing code. This is the kind of sugar I can see be forbidden by linters that want to reduce surprises. David. Sent from my iPhone > On 16 Aug 2016, at 23:47, Maximilian Hünenberger via

Re: [swift-evolution] Required Callback

> On 17 Aug 2016, at 02:49, Boris Wang via swift-evolution > wrote: > > Why the callback is special ? > > The compiler should has a warning for unused parameters of function. > > I think this is enough. More works should be leaved for a lint tool. Actually I think that that kind of warning s

Re: [swift-evolution] PITCH: New :== operator for generic constraints

The problem is that: protocol should not be a type, but it is a type sometime and not type sometime now. for exam: P.Type not same as T.Type But you can declare a variable of type P. Protocol should be a contract only, no instances of it. Charles Srstka via swift-evolution 于2016年8月17日 周三14:11写

Re: [swift-evolution] Required Callback

​Thats true, my only concern with that is if the user disables that warning.​ *___* *James⎥Lead Hustler* *ja...@supmenow.com ⎥supmenow.com * *Sup* *Runway East * *10 Finsbury Square* *London* * EC2A 1AF * On 17 August 2016 at 02:49, Bori

[swift-evolution] [Pitch][stdlib] Command Line Option Parsing & Help

I want to pitch a command line parsing addition to the standard library and get feedback before I polish up a full proposal. Swift is being positioned to fill numerous functions, including as a local scripting language. I think that’s great but having tried to use it for that purpose there are

Re: [swift-evolution] [Discussion] Sortable Attribute

Haskell also has a `comparing` function comparing :: (Ord a) => (b -> a) -> b -> b -> Ordering which applies a function on both the left hand side and the right hand side to get two values that can be compared/ordered. This makes the call site look something like this: sortBy (comparin