Re: [swift-evolution] [Accepted] SE-0168: Multi-Line String Literals

Hmm, I can see that Wux already replied to this question but let me give another more or less obvious answer which I believe has come up in a shape or another already: Brent Royal-Gordon via swift-evolution wrote: >> No, I am suggesting that whatever design is used

Re: [swift-evolution] [Discussion] Simplifying case syntax

I guess I should also include the example where the user actually wanted the oldValue to be "x": if case let .two(newValue, value) = example, value == oldValue { ... } No surprises there, even if another conditional is required. — Pyry > On 1 Mar 2017, at 22.53, Pyry Jahk

Re: [swift-evolution] [Discussion] Simplifying case syntax

Erica, Instead of going into all these lengths introducing new syntax, why not simply turn it into a warning when a `case let` binding shadows an existing variable with the exact same type (which supposedly also conforms to Equatable)? Examples, including how to silence the said warning:

Re: [swift-evolution] Reduce with inout

> Freak Show wrote: > > Am I the only one who finds this incredibly ugly and hard to read? > > This is more or less solved by inject:into: idiom. There is no reason for > inout for this particular problem. Yeah, the original signature seems more useful. If you go all `inout` like Gwendal

Re: [swift-evolution] [Pitch] Nil struct

If we start from this thought… > Adrian Zubarev wrote: > Shouldn’t it be just like this: > public protocol ExpressibleByNilLiteral { > > init(nilLiteral: Nil) > } Then why not just: public protocol ExpressibleByIntLiteral { static var `nil`: Self } …such that Foo.nil creates

Re: [swift-evolution] guard let x = x

As pleasing as it sounds*), the idea of type narrowing breaks down badly if: – the binding is implicit (without explicit extra syntax involved) and – what is bound happens to be mutable. An example being: // var message: String? if message != nil { // magic turns 'message' into a

Re: [swift-evolution] guard let x = x

> On 31 Oct 2016, Xiaodi Wu wrote: > > Don't we currently have "for x in y" and "for var x in y"? So, we could have > "unwrap x" and "unwrap var x". > > And since unwrap wouldn't allow arbitrary Boolean expressions at the front > like if and guard statements do, it could use the where clause

Re: [swift-evolution] guard let x = x

> On 31 Oct 2016, Xiaodi Wu wrote: > > An alternative that would seem to satisfy some objections is to have a > distinct "unwrap" statement--as in: "unwrap x else { ... }". True. The `let`, on the other hand, has the minor upside that it's naturally substituted with `var` where in-place

Re: [swift-evolution] guard let x = x

Going back to the originating message of this thread. This idea (or a variant thereof) has been mentioned in the list of Commonly Rejected Proposals (2nd last bullet under Control Flow, Closures, Optional Binding, and Error Handling

Re: [swift-evolution] [Pitch] Simpler interpretation of a reference to a generic type with no arguments

I was reminded of this proposal which seems like an obvious win in clarity. Still planning to submit it, Slava? — Pyry > On 28 Jun 2016, at 21:13, Dave Abrahams via swift-evolution > wrote: > > on Thu Jun 23 2016, Slava Pestov wrote: >

Re: [swift-evolution] [Pitch] Refactor Metatypes

; } > > let s1: Type = S.self > > dynamic(type: s1, is: Foo.self)//=> true > dynamic(type: s1, as: Foo.self)//=> an `Optional<AnyType>` > The type(of:) function could now stay, because now we’d only need to change > the return type. > > func type(

Re: [swift-evolution] [Pitch] Refactor Metatypes

> Goffredo Marocchi wrote: > > I think the names should be bikeshedded more still. From your examples they > seem to make sense when I mentally add Of like TypeOf<> and SubTypeOf<>, but > since you are not commenting on why that is wrong or right or misleading, or > at least I have missed

Re: [swift-evolution] [Last second] Precedence of nil-coalescing operator seems too low

Vladimir, I don't disagree with you about bitwise operations (please read my email again). I'm saying when it comes to `??`, we don't have the evidence necessary for proposing a breaking change. > On 08 Sep 2016, at 14:21, Vladimir.S wrote: > > Why do you need to see some

Re: [swift-evolution] [Review] SE-0140: Bridge Optional As Its Payload Or NSNull

I don't feel confident enough about the Swift–Obj-C interop to cast my own vote but I'd like to question this sentiment: > On 03 Sep 2016, at 03:17, Charles Srstka via swift-evolution > wrote: > > With the existing behavior, such mistakes are immediately obvious as

Re: [swift-evolution] Keyword for protocol conformance

Hi Xiaodi and Charles, > As I said, this discussion has already happened several times. I'm literally > just repeating what people said eight months ago, six months ago, and four > months ago. There's not a good answer to this and perhaps several other > issues, which is why I don't see a way

Re: [swift-evolution] [Idea] Add `bounds` function to standard library

> On 25 Aug 2016, at 12:05, Nicholas Maccharoli wrote: > > I personally see merit in adding a function to bound the value of a variable > within a range and think it would be simple to write with the existing > implementations of `min` and `max` with something like: > > public func

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

> On 16 Aug 2016, at 20:24, Justin Jia via swift-evolution > wrote: > > Thank you for the sharing how you solve this problem! It seems like the best > workaround so far. > > I wish $0 can be replaced by the actual name. (Maybe tuples?) > > let a = (x: x, y: y) >

Re: [swift-evolution] [Review] SE-0131: Add AnyHashable to the standard library

Dmitri Gribenko wrote: >> There's one very obscure gotcha with AnyHashable that subclass instances of >> a Hashable base class should be cast to the base type before wrapping into >> AnyHashable, otherwise such wrapped values may break the equivalence law of >> symmetry (`a == b` iff `b == a`). >

Re: [swift-evolution] [SHORT Review] SE-0132: Rationalizing Sequence end-operation names

> On 25 Jul 2016, at 09:10, Chris Lattner via swift-evolution > wrote: > > Hello Swift community, > > The review of "SE-0132: Rationalizing Sequence end-operation names" begins > now and runs through July 26. Apologies for the short review cycle, but > we’re

Re: [swift-evolution] [Review] SE-0131: Add AnyHashable to the standard library

> On 24 Jul 2016, at 01:26, Chris Lattner via swift-evolution > wrote: > > Hello Swift community, > > The review of "SE-0131: Add AnyHashable to the standard library" begins now > and runs through July 25. This proposal is a bit unusual, since it is a late >

Re: [swift-evolution] [Proposal] Formalized Ordering, take 2

> On 25 Jul 2016, at 21:23, Nevin Brackett-Rozinsky > wrote: > > My one question is, will I be able to write `someCollection.sort(.ascending)` > and get the expected result? (This could be an additive future direction.) To sort to ascending order, you'd

Re: [swift-evolution] [Proposal] Formalized Ordering, take 2

> On 25 Jul 2016, at 18:51, Björn Forster wrote: > > Could you please explain for someone as simple minded as me why there is (or > has to be) a difference in the implementation of <, <= and >, >=? > Sorry, but I don't get into my head why there is/has to be a

Re: [swift-evolution] [SHORT Review] SE-0133: Rename `flatten()` to `joined()`

> On 25 Jul 2016, at 09:10, Chris Lattner via swift-evolution > wrote: > > The review of "SE-0133: Rename `flatten()` to `joined()`" begins now and runs > through July 26. Apologies for the short review cycle, but we’re right up > against the end of source

Re: [swift-evolution] [Draft][Proposal] Formalized Ordering

> Dave Abrahams wrote: > > Asking whether zero appears in a sequence that happened to contain a NaN > would equally be a precondition violation. No, it wouldn't because Double would implement Equatable + Comparable by providing custom implementations of ==, <, >, <=, and >=, in addition to

Re: [swift-evolution] [Draft][Proposal] Formalized Ordering

Pyry Jahkola wrote: >> or even to ask whether >> someSequence.contains(.nan). IMO that's not really acceptable. > > Not correct. Algorithms like contains(_:) or firstIndex(of:) would use the == > operator which is part of the protocol and thus wouldn't call <=> on > FloatingPoint types which

Re: [swift-evolution] [Draft][Proposal] Formalized Ordering

Dave Abrahams wrote: >> Given all this, I propose a simpler model that makes `a <=> b` follow >> the expected behaviour of < and ==, with the tradeoff that `a <=> >> .nan` and `.nan <=> b` will abort with a precondition failure: > > This effectively makes it a precondition violation to

Re: [swift-evolution] [Draft][Proposal] Formalized Ordering

Given all this, I propose a simpler model that makes `a <=> b` follow the expected behaviour of < and ==, with the tradeoff that `a <=> .nan` and `.nan <=> b` will abort with a precondition failure: 1) We keep the current Interface of Equatable unchanged, with != defined in terms of ==. 2)

Re: [swift-evolution] [Draft][Proposal] Formalized Ordering

Xiaodi Wu wrote: > I just assumed that the core team's vision was that this would be addressed > by a domain-specific floating point `areSame(a: Self, b: Self) -> Bool { > return (a == 0 && b == 0) || (a <=> b) == .same }`. This is a valid > equivalence relation afaik. I guess so, but it's a

Re: [swift-evolution] [Draft][Proposal] Formalized Ordering

Dmitri Gribenko wrote: >> 7. What, in fact, is the proposed total order for the stdlib's >> floating-point types? > > The IEEE 754 definition. > > https://github.com/apple/swift/blob/f318fe853d7898246db24d501f1ddc03c9eb8651/stdlib/public/core/FloatingPoint.swift.gyb#L855 Cool. So if I'm

Re: [swift-evolution] [Draft][Proposal] Formalized Ordering

> On 22 Jul 2016, at 04:11, Robert Widmann via swift-evolution > wrote: > > Harlan Haskins, Jaden Geller, and I have been working on a proposal to clean > up the semantics of ordering relations in the standard library. We have a > draft that you can get as a gist.

Re: [swift-evolution] [Proposal][Discussion] Qualified Imports

I think we're getting somewhere. > On 21 Jul 2016, at 12:01, Robert Widmann wrote: > >>> (An excerpt about the hiding directive >>> )

Re: [swift-evolution] [Proposal][Discussion] Qualified Imports

Back to the pre-proposal itself, I support taking it forward and it being accepted in some form. However, I remain unconvinced that we'd ever want `hiding` imports in Swift. Here are a few specific comments on the text (8 in total): > Motivation > > The existing syntax for qualified imports

Re: [swift-evolution] [Proposal][Discussion] Qualified Imports

> On 21 Jul 2016, at 10:29, Robert Widmann wrote: > > This proposal is specifically source breaking because we're only trying to > deprecate and remove > > import {class|func|struct|...} Module.Entity > > -style imports (which not too many people seem to know

Re: [swift-evolution] [Proposal][Discussion] Qualified Imports

> On 21 Jul 2016, at 10:20, Robert Widmann wrote: > >> Simple! You don't need to hide the others if we enforce a rule that >> explicitly mentioning one in the current file imports that name as a >> fileprivate identifier which shadows the ones not explicitly

Re: [swift-evolution] [Proposal][Discussion] Qualified Imports

Oops, hit Send too soon… > Pyry Jahkola wrote: > > import A // ok, unqualified import keeps A as a second-class > identifier > import B as B // ok, qualified import makes B a first-class identifier in > file scope > > typealias A = Int // ok, shadows the module name A >

Re: [swift-evolution] [Proposal] Qualified Imports and Modules

> On 19 Jul 2016, at 00:09, Robert Widmann via swift-evolution > wrote: > > TJ Usiyan, Harlan Haskins, and I have been working on a proposal to rework > qualified imports and introduce an explicit module system to Swift that we’d > like to publish for your viewing

Re: [swift-evolution] [Review] SE-0122: Use colons for subscript declarations

> On 20 Jul 2016, Chris Lattner wrote: > > The review of "SE-0122: Use colons for subscript declarations " begins now > and runs through July 24. The proposal is available here: > > >

Re: [swift-evolution] [Review] SE-0117: Default classes to be non-subclassable publicly

> Chris Lattner wrote: > > The review of "SE-0117: Default classes to be non-subclassable publicly" > begins now and runs through July 11. The proposal is available here: > > > https://github.com/apple/swift-evolution/blob/master/proposals/0117-non-public-subclassable-by-default.md > >

Re: [swift-evolution] [Proposal] Variadics as Attribute

I agree that we should have a way to call a variadic function with an Array at hand, without needing to take its elements apart (`foo(x[0], x[1], x[2])`) — which indeed is only practical when we statically know its length. But I fear there's a shortcoming in this proposal that hasn't been

Re: [swift-evolution] [Accepted] SE-0111: Remove type system significance of function argument labels

> Charlie Monroe wrote: > > This hasn't occurred to me until now, but this will also elminate the > following (right?): > > public typealias XUURLRequestModifier = (request: NSMutableURLRequest) -> Void > > Which is really nice since when expanded by Xcode, this automatically offers > you

Re: [swift-evolution] [Accepted] SE-0113: Add integral rounding functions to FloatingPoint

I think one more thing needs clarification. Shouldn't the "defaulted" `rounded()` and `round()` be defined as protocol extension methods *without* the possibility to override the default rounding mode in a conforming type? Like so: public protocol FloatingPoint { ... func

Re: [swift-evolution] Fix or remove Swift.min and Swift.max?

+1, and bumping this topic. The background — which I'm sure Jens is aware of — is that IEEE-754 floating point numbers can't truly conform to Comparable. (The problematic case being that neither of `x < .nan`, `x == .nan`, or `x > .nan` can be `true`.) But given that the NaN-abolishing

Re: [swift-evolution] [Review] SE-0111: Remove type system significance of function argument labels

> On 30 Jun 2016, Chris Lattner wrote: > > The review of "SE-0111: Remove type system significance of function argument > labels" begins now and runs through July 4. The proposal is available here: > > >

Re: [swift-evolution] [Proposal] Add floor() and ceiling() functions to FloatingPoint

> David Sweeris wrote: > > I'm starting to come down from me earlier +1... Floor and ceiling are more > functions than properties of a number, aren't they? I agree with that. Having used various math libraries for decades now, I'd find it odd to find these as members of a floating-point type,

Re: [swift-evolution] [Pitch] Remove type inference for associated types

Hi Austin, I also think it's better to make associated types explicit in protocol conformance. But I'm not sure the requirement to use the `associatedtype` keyword on the conformance site is the right way to do so, especially since you haven't addressed how nested types could fulfill

Re: [swift-evolution] [Review] SE-0102: Remove @noreturn attribute and introduce an empty NoReturn type

> On 22 Jun 2016, at 14:47, Charlie Monroe via swift-evolution > wrote: > > I can live with Never. But the proposed NoReturn is a single-case solution > and would eventually require a code-breaking change anyway were the bottom > type implemented under a different

Re: [swift-evolution] [Draft] Tuple-Based Compound Optional Binding

> On 12 Jun 2016, at 14:46, Brent Royal-Gordon via swift-evolution > wrote: > > guard let (a, b, c) = (opt1, opt2, opt3) else { ... } You mention `guard case` in the motivation, but I think for the uninitiated reader it would be fair to point out that the following

Re: [swift-evolution] Remove nil and NilLiteralConvertible

I don't see a reason to rename or remove the `nil` literal. But I can come up with a concrete reason to deprecate NilLiteralConvertible: The language has made Optional a very specific thing with `if let` syntax, implicit wrapping, and optional chaining to name a few. But the second most common

Re: [swift-evolution] [proposal] Allow function argument type to be omitted when passing a default value from which it can be inferred

> On 07 Jun 2016, at 22:08, Sam Dods via swift-evolution > wrote: > > yes, exactly Doug... the properties at type level are part of the interface > and their types can be inferred, so i don't see the difference with function > argument types. > > i just find it

Re: [swift-evolution] [Draft] Change @noreturn to unconstructible return type

> On 06 Jun 2016, at 22:40, Michael Peternell via swift-evolution > wrote: > > E.g. with the proposal, the following function: > > @noreturn func error(msg: String = "") -> T { >fatalError("bottom: \(msg)") > } > > has to be written as > > func error(msg:

Re: [swift-evolution] [Draft] Change @noreturn to unconstructible return type

>>> I would prefer the type to be simple, and be implemented as a case-less >>> enum (not a bottom value, as in Haskell). >>> >>> None should be a usual enum, with no compiler magic except that functions >>> returning None are equivalent to current @noreturn. >> >> I think it would be more

Re: [swift-evolution] [Draft] Change @noreturn to unconstructible return type

> On 05 Jun 2016, at 21:26, Антон Жилин via swift-evolution > wrote: > > The following names were suggested: NoReturn, Bottom, None, Never. > I would pick None, because it looks like opposite to Any and fits nicely in > generic types. I would pick `Never` because

Re: [swift-evolution] [Pitch] Renaming sizeof, sizeofValue, strideof, strideofValue

> On 04 Jun 2016, Erica Sadun wrote: > > Discussion has more or less drawn down. Are there any further significant > requests / issues that need addressing? Both standalone functions (my > recommended approach) and the MemoryLayout struct approach (alternative, > with reasons why I think it's

Re: [swift-evolution] [Proposal] Protected Access Level

That's a cool hack! For a lighter way to distinguish overridable methods that one shouldn't ordinarily call, did anyone consider approximating "protected" (or as called in Objective-C speak, "private extension") methods with public class methods? public class UIView { public class

Re: [swift-evolution] [Review] SE-0091: Improving operator requirements in protocols

> On 25 May 2016, at 12:21, Brent Royal-Gordon wrote: > >> Brent, I think it's even slightly more complicated than that. Think e.g. how >> two subclass instances of NSArray should compare equal even if they've got >> different types. (I really dislike class inheritance

Re: [swift-evolution] [Review] SE-0091: Improving operator requirements in protocols

Brent, I think it's even slightly more complicated than that. Think e.g. how two subclass instances of NSArray should compare equal even if they've got different types. (I really dislike class inheritance for these reasons, but below is my take on how we could better live with the issue in

Re: [swift-evolution] Proposal SE-0009 Reconsideration

> On 22 May 2016, David Hart wrote: > > If the design team is very serious about not integrating optional warnings, > then I don’t think it is a huge bother to implement think in linters like > SwiftLint is doing. I'm fine with the way SE-0009 was decided but I think the review left one

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0041: Updating Protocol Naming Conventions for Conversions

> On 18 May 2016, Brent Royal-Gordon wrote: > > I don't think `Convertible` is clearer than `Initializable`, but I think it > rolls off the tongue better, is easier to spell, is more compatible with > non-initializer implementations, and in general wins on a lot of squishy, > subjective,

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

> On 16 May 2016, Thorsten Seitz wrote: > > Funny, for me reading a function is quite the other way around: > I prefer to first look at the function name and parameter list to give me an > idea of what the function will do (the parameter names help a lot). > Having instead first to memorize a

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

> On 16 May 2016, at 01:45, Brent Royal-Gordon via swift-evolution > wrote: > > I'm actually tempted to suggest that a conformance should be *mandatory* and > you should have to specify `Any` if you don't have anything more specific to > say about the generic

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

Tony & Haravikk, (Reformatting your quoted examples just a bit…) >> It enables things like: >> func someMethod(value: S) -> AnySequence >> where S.Generator.Element == T { ... } > > I'm not assuming that. Under the current syntax, I would format your example > as: > > func

Re: [swift-evolution] [Review] SE-0075: Adding a Build Configuration Import Test

> On 13 May 2016, Erica Sadun wrote: > >> As per Pyry’s feedback, you could add a version: >> >> #if import Frobnication(<1.7.3) // <- Only added version constraint here. >> extension Knob : Frobnicatable { ... } >> #endif > > I have no problem with this but would need to defer to the build and

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0041: Updating Protocol Naming Conventions for Conversions

Taking the suggested changes into account, here's my review. 1) +1, I think this is a reasonable way for naming this family of protocols. 2) The problem isn't huge, but I think it's worth fixing. So far, the naming of stdlib protocols has been somewhat inconsistent in this regard. 3) I've used

Re: [swift-evolution] [Review] SE-0075: Adding a Build Configuration Import Test

> Gwendal Roué wrote: > > `#if import Foo` can not deal with the fact that a single source file may > have to perform the importability test several times. This would be less of a problem if conditional imports like that worked locally in all scopes of code, so you could write just func

Re: [swift-evolution] [Review] SE-0075: Adding a Build Configuration Import Test

Patrick, I think you're making valuable points here. I also can't think of cases where you wouldn't also import a module in case it was found to be importable. So the use cases I can think of could as well be tackled by allowing expressions such as `import Foo.Bar` as compile-time checks

Re: [swift-evolution] [Review] SE-0075: Adding a Build Configuration Import Test

> The review of "SE-0075: Adding a Build Configuration Import Test" begins now > and runs through May 16. The proposal is available here: > > > https://github.com/apple/swift-evolution/blob/master/proposals/0075-import-test.md > > * What is your evaluation of the proposal? +1, I

Re: [swift-evolution] Making `.self` After `Type` Optional

> On 06 May 2016, at 10:19, Adrian Zubarev via swift-evolution > wrote: > > Wouldn’t this enforce enum cases and some static struct variables to be > lowercase? > > Is this really a welcome change? I mean I’d love to see the drop of `.self` > magic from types, but

Re: [swift-evolution] Making `.self` After `Type` Optional

> I understand why the alternative of changing the generic type parameter list > symbols was rejected, to be consistent with other C based languages, but I > don't understand why the following was rejected: > > making the UppercaseTypes, lowercaseValues convention a syntactic > requirement, as

Re: [swift-evolution] [Review] SE-0073: Marking closures as executing exactly once

Hi Gwendal, Nice writeup. So I see that you recognise how this extra specification will complicate (while also facilitate) things. And I also see that you're a co-author of the proposal. So I'm more than happy if you can squeeze this extra into it. However reading your example code, I had to

Re: [swift-evolution] [Review] SE-0073: Marking closures as executing exactly once

Here's my review of "SE-0073 : Marking closures as executing exactly once". > What is your evaluation of the proposal? +1. I think this is a good idea and should be accepted (without extending the proposed

Re: [swift-evolution] [Proposal] Improving operator requirements in protocols

FWIW, the problems with class inheritance and Equatable can be fixed by changing the definition of Equatable into using an associatedtype for the RHS: protocol Equatable { typealias EqualSelf = Self func == (lhs: Self, rhs: EqualSelf) -> Bool func != (lhs: Self, rhs: EqualSelf) ->

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0045: Add scan, prefix(while:), drop(while:), and iterate to the stdlib

> I would really like a different name for scan. While it’s the term of art for > Haskell and co, it really seems meaningless to regular programmers (why is > “scanning” the way you produce an array of intermediate reduces?), and it > would be better to follow the pattern already established

Re: [swift-evolution] [Review] SE-0066: Standardize function type argument syntax to require parentheses

> https://github.com/apple/swift-evolution/blob/master/proposals/0066-standardize-function-type-syntax.md > > > What is your evaluation of the proposal? -1, I'm mildly against but against.

Re: [swift-evolution] [Pitch] Richer function identifiers, simpler function types

> On 28 Apr 2016, at 14:37, Tino Heth <2...@gmx.de> wrote: > >> C1: Extend SE-0021 >> >> by adding the underscore-in-parentheses syntax `foo(_)` to refer to the >> zero-argument function #1. > I don't

Re: [swift-evolution] [Proposal] Add Binary Search functions to SequenceType

Bringing up this topic because it became relevant with Brent Royal-Gordon's "[Idea] Bringing the partial/total ordering distinction into Comparable ". If the `<=>` operator with a return type of a three-case `enum Order`, you can

Re: [swift-evolution] [Pitch] Richer function identifiers, simpler function types

Corrections, additions below… > Let's consider the following declarations: > > class Bar { > func baz() // #8 Method named 'Bar.baz(_)' with > type 'Bar -> () -> ()'. > func baz(x y: Int) // #9 Method named 'Bar.baz(x:)' with > type 'Bar -> Int

[swift-evolution] [Pitch] Richer function identifiers, simpler function types

This is another reaction to SE-0066 to which I'm mildly against. I'd like to propose the following language changes to simplify function types and clarify what a function's name is. What

Re: [swift-evolution] mutating/non-mutating suggestion from a Rubyist

> On 28 Apr 2016, at 10:59, Tyler Fleming Cloutier > wrote: > > Yup, that pretty much addresses all of my concerns. So count me amongst the > fans. By the way, I can be counted as +1 on reusing the keyword `mutating` here. However, for the reasons stated in my

Re: [swift-evolution] mutating/non-mutating suggestion from a Rubyist

Good that you brought the topic of "fluent" interfaces up. I don't see any problem with explicit value type mutation and method chaining because fluent interfaces are constrained to reference types by the language. Details below: > On 28 Apr 2016, at 03:44, Tyler Cloutier

Re: [swift-evolution] mutating/non-mutating suggestion from a Rubyist

I'd like to second James Campbell's suggestion of a `mutate` keyword. Clarifying comments inline below: > On 23 Apr 2016, at 00:24, Dave Abrahams via swift-evolution > wrote: > > This is not a new idea. Something almost identical to this has been > explored and

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

> On 11 Apr 2016, at 15:23, Luis Henrique B. Sousa via swift-evolution > wrote: > let a = [1,2,3] > let b = a[0..<5] > print(b) > In the swift-3-indexing-model branch ,

Re: [swift-evolution] [SR-933] Rename flatten to flattened

> On 08 Apr 2016, at 13:19, Haravikk via swift-evolution > wrote: > > I think it makes sense to just rename them; it’s not as though flattened or > mapped is somehow far removed from the original meaning as the actual action > is the same, it’s just changing tense.

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

> On 06 Apr 2016, at 23:17, Dave Abrahams via swift-evolution > wrote: > > I don't think you can fix counterintuitive behavior with guidance. > > (1..<199).striding(by: -2) is the first way I'd reach for to express > 197, 195, ..., 3, 1 I think a sensible

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

Joe, Just from your experience on this topic, is there any reason not to also move the primary constraints into the trailing `where` clause? So instead of what you wrote, we'd have it this way: func foo(x: T, y: U) -> Result where T: Foo, U: Bar, T.Foo == U.Bar /*, etc.

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

> The same would work for generic types too: > > public struct Dictionary > where Key : Hashable > { >... > } And I'm not sure if people feel the same as me, but I haven't been happy with the current way generic arguments (such as Key and Value above) magically appear in

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

> On 06 Apr 2016, at 21:30, Developer via swift-evolution > wrote: > > If you've ever gotten to the point where you have a sufficiently generic > interface to a thing and you need to constrain it, possibly in an extension, > maybe for a generic free function or

Re: [swift-evolution] [Pre-Draft] Nil-coalescing and errors

>>> Interesting, but I’m unsure if all of it is significantly better than just >>> using the guard that is effectively inside of the operator/func that is >>> being proposed: >>> >>> guard let value = Int("NotANumber") else { throw >>> InitializerError.invalidString } >> >> That is a pretty

Re: [swift-evolution] What's the best replacement if "Remove C-style for loops"?

> On 17 Mar 2016, at 14:48, nebulabox via swift-evolution > wrote: > > I have several codes like the following: > > for var i = 0; i < myarr.count; i += n { // the step is NOT 1 >// many codes > } > > (…) If no C-style for loop, what's the best replacement for

Re: [swift-evolution] Beef up Imports

> On 27 Dec 2015, at 07:12, Developer via swift-evolution > wrote: > > Therefore, I propose the introduction of 3 agda-esque operations for imports > to replace the usual `import {func|typealias|struct|class|enum|etc.}` syntax: > > • import Foo using (bar,