Re: [swift-evolution] [pitch] Adding in-place removeAll to the std lib

How about this: array.removeEvery(3) array.removeEvery{ $0 > 3 } I think it preserves the meaning while it reads nicely. However "every" has no precedent in other functions, as far as I know. > Am 10.04.2017 um 04:32 schrieb Ben Cohen via swift-evolution > :

Re: [swift-evolution] [Proposal] Enums with stored properties

I think your second point is quite interesting! We should consider expanding this so that we can get any associated value: // from the Swift book enum Barcode { case upc(Int, Int, Int, Int) case qrCode(String) } let code = Barcode.upc(9,2,3,4) if let upcCode = code.upc { // upcCode:

Re: [swift-evolution] Mark protocol methods with their protocol

> Am 23.09.2016 um 12:47 schrieb Vladimir.S : > >> On 23.09.2016 11:05, Maximilian Hünenberger wrote: >> I'd also say that one or two keywords are superior than the protocol naming >> approach in terms of implementation simplicity (for the core team). >> >> My suggestions: >>

Re: [swift-evolution] Mark protocol methods with their protocol

I'd also say that one or two keywords are superior than the protocol naming approach in terms of implementation simplicity (for the core team). My suggestions: Either "conform" or "implement" should be a required keyword for all properties/functions which implement a protocol (also in protocol

Re: [swift-evolution] [Swift 4.0] Conditional conformances via protocol extensions

> Am 12.08.2016 um 04:39 schrieb Douglas Gregor via swift-evolution > : > > > > Sent from my iPhone > >> On Aug 4, 2016, at 2:36 AM, Haravikk via swift-evolution >> wrote: >> >> On 4 Aug 2016, at 03:19, Brent Royal-Gordon via

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

1d { >case point(Point) >case line(Line) > } > > Same for Intersection2d, but adding case plane(Plane) and so on for higher > dimensions. > > This way the purpose of these types is clear which was not the case for a > more general GeometryValue. > > -Thorsten >

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

Hi Justin, First of all I like your idea! Second, I understand the concerns of Xiaodi but I don't think the short-circuit problem is that big. Functions which have a non Void return type mostly have no side effects (at least in my code base). Furthermore the less explicit control flow (only

Re: [swift-evolution] Passing an optional first argument to sequence(first:next:)

Ok, I see. However this could be a potential source of bugs/performance issues where you don't consider the nil case and you do some unnecessary work. By prohibiting to pass nil you have to manually unwrap and you immediately see the "optionality". > Am 15.08.2016 um 22:36 schrieb Tim

Re: [swift-evolution] Passing an optional first argument to sequence(first:next:)

Probably I didn't understand your proposal. What do you want to change exactly? I thought: public func sequence(first: T, next: @escaping (T) -> T?) -> UnfoldFirstSequence { ... } To: public func sequence(first: T?, next: @escaping (T) -> T?) -> UnfoldFirstSequence { ... } > Am 15.08.2016 um

Re: [swift-evolution] Passing an optional first argument to sequence(first:next:)

Hi Tim, If you pass "nil" to "first" isn't this an empty sequence? So it would be redundant. Best regards Maximilian > Am 15.08.2016 um 01:27 schrieb Tim Vermeulen via swift-evolution > : > > sequence(first:next:) takes a non-optional first argument. Is there a

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

think using a protocol is the more Swifty approach to > this problem. If I end up not having any common properties or functions that > apply to that one umbrella protocol, then I consider that a signal that I’m > modeling my solution incorrectly. > > l8r > Sean > &

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

Hi Cao, I would be in favor until I find another approach to this problem: Consider you have a geometry framework and two types: Point and Line An intersection between two lines can be either none, a point or a line (if both are identical). The return type would probably be (Point | Line)?

Re: [swift-evolution] Which functionality should be covered by a native Swift math/numerics library that ships with the standard lib?

I think this is a great idea! As Chris said we should use GitHub or something else to start such a project. Does someone already has a Math library where we can discuss and commit? I'll soon push a small Math library to my GitHub repo and let you know. Best regards Maximilian > Am 03.08.2016

Re: [swift-evolution] [Accepted with Revision] SE-0099 Restructuring Condition Clauses

From the original thread: > Am 01.06.2016 um 03:47 schrieb Xiaodi Wu via swift-evolution > : > > > > It does occur to me that there is one more option. I don't know that I like > it, but it's an option no one has put forward before: recite the opening > keyword

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

> Am 01.06.2016 um 03:47 schrieb Xiaodi Wu via swift-evolution > : > > > > It does occur to me that there is one more option. I don't know that I like > it, but it's an option no one has put forward before: recite the opening > keyword when beginning a new boolean

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

;>> Exactly, the idea is to return an empty array just like other languages do. >>> (e.g. python) >>> >>> - Luis >>> >>>> On Sun, May 15, 2016 at 10:13 AM, Vladimir.S via swift-evolution >>>> <swift-evolution@swift.or

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

er languages do. > (e.g. python) > > - Luis > >> On Sun, May 15, 2016 at 10:13 AM, Vladimir.S via swift-evolution >> <swift-evolution@swift.org> wrote: >>> On 15.05.2016 0:09, Maximilian Hünenberger via swift-evolution wrote: >>> One point which sho

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

One point which should be discussed is the following behaviour: let array = [0] // ranges are completely out of bounds and produce an error array[clamping: 1...2] // error array[clamping: -2...-1] // error Should a range which has no intersection with the indices of the collection produce an

Re: [swift-evolution] [Pitch] Moving where Clauses Out Of Parameter Lists

+1 I almost fully agree with all your points. However I disagree with your first point: What do you mean by: "I think it's more natural to restrict generic type parameters to the immediate local scope" To me it feels like an "associated type" so it should be almost equally exposed in

Re: [swift-evolution] [Proposal] mapValues

I like the idea of having a mapping method which maps back to the actual type. What about a more general approach? consider: mappedSelf(transform: T -> U) -> Self filteredSelf(includeElement: T -> Bool) -> Self Which can be added to other collections like Set and sequences like a lazy number

Re: [swift-evolution] [Proposal] Safer half-open range operator

Should this new operator form a new range? How can this range know about the array's indices? A while ago there was a proposal (unfortunately it was not discussed enough) which introduced safe array indexing: array[safe: 3] // returns nil if index out of bounds So another way to

Re: [swift-evolution] [Completing Generics] Arbitrary requirements in protocols

Hi Jacob, I really like the idea of constraining associated types. However I think there could be a much more general solution to this problem by introducing "Partially constrained protocols". I've already created a (almost finished) proposal for another thread which hasn't continued. It

Re: [swift-evolution] [Proposal] Custom operators

> Am 10.04.2016 um 11:48 schrieb Антон Жилин : > >> 2016-04-10 2:27 GMT+03:00 Maximilian Hünenberger : > > [...] > >> The only minor syntax issue I have is that it is not immediately clear which >> operators belong to a precedence group. The

Re: [swift-evolution] [Proposal] Custom operators

> Am 09.04.2016 um 19:43 schrieb Антон Жилин : > [...] > Now, I see only 1 large question/problem risen by David Waite: > Should precedence relationships be defined inside or outside of precedence > groups? > That is: should we be able to add arbitrary relationships

Re: [swift-evolution] [Proposal] Custom operators

Inline > Am 04.04.2016 um 08:06 schrieb Антон Жилин : > > Thank you for a helpful answer! > I like the idea of overriding precedence from another module. We won't need > to introduce additional keywords or visibility for operators. I will add it > to the proposal. > >

Re: [swift-evolution] [Proposal] Custom operators

See inline > Am 03.04.2016 um 13:26 schrieb Ross O'Brien via swift-evolution > : > > There is a problem here of duplicated operators or custom precedence, and how > that gets passed between modules. > Assume there are three modules, A, B and C. B defines a custom

Re: [swift-evolution] Question about heterogeneous collections

See inline > Am 31.03.2016 um 20:14 schrieb Dave Abrahams via swift-evolution > : > > >> on Tue Mar 29 2016, Jason Sadler wrote: >> >> Hi folks, >> >> I have an issue with using a heterogeneous array of objects conforming >> to a

Re: [swift-evolution] allowing to specify optionality with type inference

Only to be complete: let str1 = String?() // nil let str2 = String?("") // "" Kind regards - Maximilian > Am 24.03.2016 um 11:57 schrieb Hugues Bernet-Rollande via swift-evolution > : > > Hey All, > > I think Andrew already nailed my proposal. > > Thank you all. >

Re: [swift-evolution] idea: immutable setters for structs and tuples?

> Am 24.03.2016 um 22:40 schrieb Erica Sadun via swift-evolution > : > > >> On Mar 24, 2016, at 3:39 PM, Brent Royal-Gordon >> wrote: >> I think this is better modeled in Swift as something like: let john =

Re: [swift-evolution] SE-0025: Scoped Access Level, next steps

I like the idea of protected (against extensions). However this raises the question whether extensions are also extensions of scope. Can "private(scope)" properties/functions be accessed from extensions? In your case: Is "protected" exactly like local? So it doesn't hide properties from

Re: [swift-evolution] [Idea] Find alternatives to `switch self`

I don't think that removing "switch(self)" would remove much boilerplate. I rather see the returns and cases as such. It is true your second approach is much more maintainable if you want to add or remove a case. However I think it suffers from readability and you cannot group related logic

Re: [swift-evolution] [Proposal] Allow static protocol extension methods to be called directly on the protocol

Wouldn't it be easier (syntax wise) to extend the meta type directly? : protocol P {} extension P.Type { static func a() {} } Kind regards - Maximilian > Am 28.02.2016 um 02:05 schrieb Joe Groff via swift-evolution > : > > Rasmus Kjeldsen via swift-evolution

Re: [swift-evolution] Idea: Extend "guard" to try-statements, with a catch block

eturn } In contrast to: guard let x = try? throwingFunction(y) catch { // handle error return } - Maximilian > Am 14.03.2016 um 18:00 schrieb Erica Sadun <er...@ericasadun.com>: > >> On Mar 14, 2016, at 10:20 AM, Maximilian Hünenberger via swift-evolution

Re: [swift-evolution] [Idea] Find alternatives to `switch self`

Hi Brent, First of all, I like your suggestions however there was already a proposal about "Pattern matching partial functions" which could address this and many other issues (See pull request #111; unfortunately the discussion doesn't went on... Hopefully this time). This proposal addresses

Re: [swift-evolution] A (better) Swift Equivalent For The Classical For-Loop With Numeric Scalars

I totally agree with you that the for loop shouldn't be overloaded with keywords. Although a "while" condition could be a reasonable addition since the "breaking" condition is at the top of the for loop not at the bottom. One can benefit from this if the condition is more complex. But this

Re: [swift-evolution] idea: immutable setters for structs and tuples?

I cannot remember any use of such a feature but instead of a language feature there is also a reasonable library solution: // inspired by the lens idea (of Joe Groff I think) // there is probably a better name func lens(value: T, lensClosure: inout T -> ()) -> T { var value = value