Re: [swift-evolution] [Pitch] Allow trailing argument labels

To summarize, there's one ambiguous case we'd need to resolve: func foo(_ x: Int, reportingOverflow) func foo(_ x: Int, _ reportingOverflow: Bool) let reportingOverflow = true foo(5, reportingOverflow) // Ambiguous One solution is to make trailing argument labels syntactic sugar for a trailing

[swift-evolution] [Pitch] Allow trailing argument labels

I'd like to discuss allowing a trailing 'argument label' without an actual argument: func adding(_ other: Self, reportingOverflow) -> … // Actual case in SE-104 where this came up func tableView(_ tableView: UITableView, numberOfSections) -> Int // Referenced as tableView(_:numberOfSections) As

Re: [swift-evolution] Pitch: Compound name `foo(:)` for nullary functions

I'm personally in favor of foo(_), as the number of colons currently lines up directly with the number of arguments, and it'd be good to keep it that way. In general though I'm very in favor of requiring the parentheses, as the ambiguity between unparenthesized references to functions and

Re: [swift-evolution] Treating an Enum's Cases as Its Subtypes

Alternatively, we could still use the as? and is keywords. This would be slightly different from their normal usage, but arguably this is unlikely to lead to misunderstandings or confusion in this case - and they are nicer as keywords. On Wed, Feb 22, 2017 at 8:34 PM, Niels Andriesse via

Re: [swift-evolution] [swift-evolution-announce] [Re-Review] SE-0104: Protocol-oriented integers

Arbitrary sized signed -1 can have different popcount depending on the > underlying buffer length (if there is a buffer) even if it’s the same type > and the same value. Same with leading zeros, as the underlying > representation is unbounded on the more significant side. Sensible, why didn't I

Re: [swift-evolution] [Re-Review] SE-0104: Protocol-oriented integers

I've followed this for a long time and work a lot with number/big num related code, and I must say I'm really excited about the way this is turning out! *Popcount & leadingZeroBits* - *Placement:* What's the rationale behind placing popcount & clz on fixed width integer instead of BinaryInteger?

Re: [swift-evolution] Treating an Enum's Cases as Its Subtypes

Just to clarify, the proposal doesn't suggest to allow the associated value to be used as a subtype of the enum. enum Result { case .success(T), .error(Error) } func foo(_ x: Result) { /* ... */ } func bar(_ x: Result.success) { /* ... */ } // Not this: foo(5) bar(5) // But rather:

Re: [swift-evolution] Removing enumerated?

Note that zip(a.indices, a) requires advancing the index twice each iteration, which for non-array collections is not necessarily super trivial. Considering we're talking about such a low-level operation as iterating through a collection this might be worth considering. Personally I'm in favor of

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

I'm not very familiar with the runtime so forgive me – the protocols would only have to be added once right? And couldn't this usually be done at compile time, or does it happen when the module is linked at startup? On Thu, Aug 4, 2016 at 4:36 PM, Haravikk via swift-evolution <

Re: [swift-evolution] [Review] SE-0128: Change failable UnicodeScalar initializers to failable

+1 Makes sense, it's a basic failable conversion. On Fri, Jul 22, 2016 at 2:09 PM, 王 黎明 wrote: > +0. > > Maybe off topic. > > The problem is there’s no process for the validty of the parameter. > > The source of UnicodeScala: > > public init(_ v: UInt32) { > //

Re: [swift-evolution] [swift-dev] Endgame for Swift 3

> > Isn't half of this done, or something? I seem to remember seeing code > about it, and I think there may even be a hidden switch to enable what is > there. The parsing code seems to be in place, toggled by the flag Context.LangOpts. EnableProtocolTypealiases:

Re: [swift-evolution] Change subscripts to use colons

Good point. A subscript basically a parameterized property, not a function. I'm in favor. On Mon, Jul 11, 2016 at 9:18 AM, James Froggatt via swift-evolution < swift-evolution@swift.org> wrote: > Currently, the signature is: > subscript(_ example: Int) -> Element { > get { … } > set { …

Re: [swift-evolution] [Review] SE-0104: Protocol-oriented integers

> > > We might even be able to take the existing string-to-integer > > logic, which I believe is duplicated for each type through GYB, and > > share it in an extension so no Integer needs to write its own > > conversion. Is that something that should be added? > >

Re: [swift-evolution] [Draft] Apply -ed/-ing rule to core functional methods (e.g. filter => filtered)

> > Sure, but `mappingAndFlattening(to:)` would have brevity issues as well. My point was that if you want to transform sin() -> sine() you'd be pretty much forced to also do atanh() -> hyperbolicArcTangent(). However the proposed transformation is for flatMap() to flatMapped(), which doesn't

Re: [swift-evolution] [Draft] Apply -ed/-ing rule to core functional methods (e.g. filter => filtered)

the terms of art in all the senses that matter (i.e. all the >> benefits like recognition etc. still apply). >> >> On Fri, Jun 17, 2016 at 2:12 PM, Vladimir.S <sva...@gmail.com >> <mailto:sva...@gmail.com>> wrote: >> >> On 17.06.2016 8:02, Patrick Pi

Re: [swift-evolution] [Draft] Apply -ed/-ing rule to core functional methods (e.g. filter => filtered)

that the modified versions preserve the the terms of art in all the senses that matter (i.e. all the benefits like recognition etc. still apply). On Fri, Jun 17, 2016 at 2:12 PM, Vladimir.S <sva...@gmail.com> wrote: > On 17.06.2016 8:02, Patrick Pijnappel via swift-evolution wrote: >

Re: [swift-evolution] [Draft] Apply -ed/-ing rule to core functional methods (e.g. filter => filtered)

> > -1, for the same reasons stated on the thread. These are neither > guaranteed to be mutating or non-mutating until you get to Collection. > Changing map() to mapped() would be lying to the developer some of the > time about the mutability of the interface. > -DW Actually the -ed/-ing suffix

[swift-evolution] [Draft] Apply -ed/-ing rule to core functional methods (e.g. filter => filtered)

Due to considerably support on this thread , a draft proposal to revisit the core functional method exceptions to the -ed/-ing rule. Online version:

Re: [swift-evolution] API Guidelines: dropFirst?

Hmm, after some consideration I think we should reconsider renaming all of the exceptions (map => mapped, filter => filtered, etc). The main reason to use a term of art is such that people already familiar with the term will immediately understand it. However as Jonathan points out, since the

[swift-evolution] API Guidelines: dropFirst?

What is the rationale behind the name dropFirst()? Being a non-mutating method it should clearly be e.g. droppingFirst() according to the API Naming Guidelines. I can't seem to find the SE thread dealing with this. ___ swift-evolution mailing list

Re: [swift-evolution] [Pitch] Add toplevel keyword for protocols

m> wrote: > > On May 13, 2016, at 12:12 AM, Patrick Pijnappel via swift-evolution < > swift-evolution@swift.org> wrote: > > For some protocols we'd like to require top-level (free) functions, e.g. > for many math functions such as abs() or sin(). We already do this >

Re: [swift-evolution] [Pitch] Add toplevel keyword for protocols

nother > keyword. I would only add one requirement: that the first argument should > always be of type Self (and have it checked by the compiler). It ensures > the operator operates on that type and helps minimising conflicts with a > previously declared operator. > > - Leonardo &g

[swift-evolution] [Pitch] Add toplevel keyword for protocols

For some protocols we'd like to require top-level (free) functions, e.g. for many math functions such as abs() or sin(). We already do this implicitly for operators. *Proposal* Allow top-level function/property requirements in protocols, e.g.: public protocol AbsoluteValuable : SignedNumber {

Re: [swift-evolution] [Review] SE-0052: Change IteratorType post-nil guarantee

> > However, if there really is a 25% speedup on UTF-8 decoding for ASCII > input, that's a pretty significant point in favor of the change. I saw the > gist that was used to come up with this 25% number. But I do have to ask, > does the 25% increase still hold when talking about String.UTF8View,

Re: [swift-evolution] [Review #2] SE-0067: Enhanced Floating Point Protocols

Also, maximum() should probably return y if x == y to be consistent with max() , preserving stable ordering for (x, y) = (min(x, y), max(x, y)). I think IEEE 754 leaves the x == y case unspecified. Currently we have

Re: [swift-evolution] [Review] SE-0052: Change IteratorType post-nil guarantee

Thanks for the feedback! Some comments: 1. *Obscurity argument*: Both the existing precondition, and the proposed > convention are non-enforceable, non-testable, not well-known enough, and > generally too weak to be efficient in any way. People don't write custom > iterators often enough, and I

Re: [swift-evolution] [Review #2] SE-0067: Enhanced Floating Point Protocols

Am I correct in assuming that this would also eliminate the hidden associatedtype _BitsType currently preventing non-stdlib conformances? On Wed, Apr 27, 2016 at 2:04 AM, Xiaodi Wu via swift-evolution < swift-evolution@swift.org> wrote: > I thought you'd mentioned that AbsoluteValuable

Re: [swift-evolution] [Draft] Expanded min/max algorithms

I like the idea. A few notes on naming: – minIndex is somewhat confusing to me (it sounds like it's getting the minimum index, i.e. indices.minElement()). How about indexOfMin() or indexOfMinElement()? – minmax() also doesn't read very well to me, plus it should technically be minMax() which is

Re: [swift-evolution] ++ and --

Note that += 1 and -= 1 compile to the same assembly as ++ and -- respectively and therefore have identical performance. On Wed, Mar 23, 2016 at 9:44 PM, Biala via swift-evolution < swift-evolution@swift.org> wrote: > Hello, > > I would like to share my opinion on -- and ++ operators... > > I

Re: [swift-evolution] [Proposal] Factory Initializers

Definitely a +1 here on interest for this proposal, have run into this several times. On Tue, Mar 22, 2016 at 5:16 PM, Riley Testut via swift-evolution < swift-evolution@swift.org> wrote: > Hey all! > > Very sorry, restored my MacBook at the beginning of the calendar year, and > forgot to

[swift-evolution] [Draft] Change IteratorType post-nil guarantee

Proposal pull request: #213 Implementation pull request: #1702 Original pitch thread: [Proposal] Change guarantee for GeneratorType.next() to always return nil past end

[swift-evolution] [Pitch] Remove bit shift traps

Currently, bit shifting with an amount greater than or equal to the size of the type traps: func foo(x: Int32) { let y = x << 32 // Runtime trap (for any << or >> with amount >= 32) } I propose to make this not trap, and just end up with 0 (or ~0 in case of right-shifting a negative number):

Re: [swift-evolution] [Proposal] Change guarantee for GeneratorType.next() to always return nil past end

Proposal: https://github.com/apple/swift-evolution/pull/213 On Wed, Mar 9, 2016 at 1:29 PM, Kevin Ballard via swift-evolution < swift-evolution@swift.org> wrote: > One minor change to what I've been proposing: Instead of merely saying > that it's implementation-defined, we should expressly say

Re: [swift-evolution] [Review] SE-0047 Defaulting non-Void functions so they warn on unused results

+1 but: I'm somewhat hesistant about not marking the plausibly discarable ones @discardableResult. - I rarely use the result value of removeLast() and I don't see how requiring it here adds any safety. It is obvious this call has side-effects and doesn't just return the last element. - I would

Re: [swift-evolution] [Draft] Change IteratorType post-nil guarantee

Post-nil behavior being relevant is somewhat rare either way, but a comparison: *Current – post-nil unspecified* – Responsibility of the caller, needs to be aware of the API contract and needs to track a bool and branch when relying on post-nil. – Standard library currently has 3 occurrences of

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

; >> var foo: Int { mutating get { ... } } >> >> and not >> >> mutating(get) var foo: Int { get { ... } } >> >> On Tue, Mar 15, 2016 at 4:13 PM, Patrick Pijnappel < >> patrickpijnap...@gmail.com> wrote: >> >>> I like Shawn's propo

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

I think it just gets > too inconsistent with private(set: public) and private(set: private) (?!) > > On Tue, Mar 15, 2016 at 3:39 PM, Jonathan Hull via swift-evolution < > swift-evolution@swift.org> wrote: > >> *On Mar 14, 2016, at 8:36 PM, Patrick Pijnappel via swift-evoluti

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

, 2016 at 3:39 PM, Jonathan Hull via swift-evolution < swift-evolution@swift.org> wrote: > *On Mar 14, 2016, at 8:36 PM, Patrick Pijnappel via swift-evolution > <https://lists.swift.org/mailman/listinfo/swift-evolution>> wrote:* > > The only question is (as Sean m