Re: [swift-evolution] [Review] SE-0191: Eliminate IndexDistance from Collection

> On Nov 27, 2017, at 18:34, Douglas Gregor via swift-evolution > wrote: > > Hello Swift community, > > The review of SE-0191 "Eliminate IndexDistance from Collection" begins now > and runs through December 3, 2017. [snip] > • What is your evaluation of the

Re: [swift-evolution] Adding Result to the Standard Library

> On Nov 14, 2017, at 19:57, Hooman Mehr wrote: > > You can support all styles with enum as well. My point is precisely that perhaps we should not. While the switch-over-result style is neither better nor worse than the try-catch style, having both in one body of code isn’t

Re: [swift-evolution] Adding Result to the Standard Library

I’m late to this particular party, but having just caught up with the thread I’m surprised that no one substantially addressed the stylistic duality that a `public enum Result` would bring. In short, I’d rather Result be a struct than an enum. I too implemented a Result, for obvious reasons. I

Re: [swift-evolution] Implicit truncation

> On May 23, 2017, at 20:34, Xiaodi Wu <xiaodi...@gmail.com> wrote: > > On Tue, May 23, 2017 at 5:27 PM, Guillaume Lessard via swift-evolution > <swift-evolution@swift.org> wrote: > > > Is there another lossy initializer for Int or BinaryInteger that do

Re: [swift-evolution] Implicit truncation

> On May 23, 2017, at 19:55, Xiaodi Wu <xiaodi...@gmail.com> wrote: > > On Tue, May 23, 2017 at 5:27 PM, Guillaume Lessard via swift-evolution > <swift-evolution@swift.org> wrote: > > /// Truncating the fractional part of `source` is equivalent to rounding > //

Re: [swift-evolution] Implicit truncation

> On May 23, 2017, at 13:25, Xiaodi Wu wrote: > > The doc comments in the proposal text were meant as explanation for readers > of the proposal; they undergo editing for accuracy during implementation. > That wording is, notably, not found in the implemented protocol.

Re: [swift-evolution] Implicit truncation

I completely agree with Haravikk. This is not C, we have type inference, and this behaviour is different from other non-failable lossy conversions in Swift. Regarding uses of ‘truncating’, Xiaodi is wrong. The documentation of BinaryInteger.init(_ source: T) in the accepted proposal

Re: [swift-evolution] [Pitch] Don't require & for UnsafeRawPointer

> On May 17, 2017, at 15:28, Jordan Rose wrote: > > This can come up even without &. It is illegal to use > UnsafeMutablePointer.init(mutating:) on something that was not a mutable > pointer to begin with, and the program is not guaranteed to do anything > sensible if

Re: [swift-evolution] [Pitch] Don't require & for UnsafeRawPointer

Back to the initial example, here’s a variant that shows a “non-mutable” pointer lying; try it in a playground. ``` func get(_ pointer: UnsafePointer, at index: Int) -> Int { let mutator = UnsafeMutablePointer(mutating: pointer) mutator[index] += 1 return pointer[index] } let

Re: [swift-evolution] [Pitch] Don't require & for UnsafeRawPointer

How would you deal with the existence of: UnsafeMutablePointer.init(mutating other: UnsafePointer) No unsafe pointer can guarantee that it won’t be used to mutate its pointee. Requiring a mutable variable seems like truth in advertising. Sincerely, Guillaume Lessard

Re: [swift-evolution] [pitch] Character.unicodeScalars

> On May 11, 2017, at 13:56, Ben Cohen via swift-evolution > wrote: > > You can use flatMap with a function (Element)->T, and it has the same effect > as map because the function is implicitly converted to (Element)->T? and then > the elements are unwrapped again

Re: [swift-evolution] SE-0171: Reduce with inout

> https://github.com/apple/swift-evolution/blob/master/proposals/0171-reduce-with-inout.md > > • What is your evaluation of the proposal? I support this proposal. It is easy to inadvertently write inefficient algorithms with reduce, and this provides a built-in solution. The parameter label is

Re: [swift-evolution] SE-0171: Reduce with inout

The mutating version would have a parameter label to differentiate it: let a = [1, 2, 3, 4, 5] let b = a.reduce(into: []) { (result, element) in result.append(element * 2) } -- GL ___ swift-evolution mailing list swift-evolution@swift.org

Re: [swift-evolution] [pitch] Comparison Reform

> On Apr 13, 2017, at 18:18, Xiaodi Wu via swift-evolution > wrote: > > `compare(_:)` does not merit a term-of-art exception when the Swift name is > clearly `compared(to:)`. No; in full grammatical pedanticity it should be compared(with:). “compare to” is for

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

> On Apr 10, 2017, at 13:30, Kevin Nattinger via swift-evolution > wrote: > > array.remove(where: { $0 > 3 }) > array.remove { $0 > 3 } `where` is the best label for this. `filter` doesn’t have an overload for Comparable, this doesn’t need one either. Cheers,

Re: [swift-evolution] [Pitch] Introducing `Unwrappable` protocol

> On Mar 7, 2017, at 4:30 PM, Erica Sadun wrote: > > I deliberately moved it out of proposal format for that reason, so it could > be discussed first. I see now. >> - The `case let .some(foo)` vs. `case .some(let foo)` issue could be a >> targeted proposal. >> (I

Re: [swift-evolution] [Pitch] Introducing `Unwrappable` protocol

I like some of this, but as a single proposal, it does too many things at once. - The `case let .some(foo)` vs. `case .some(let foo)` issue could be a targeted proposal. (I really like this) - The Unwrappable protocol (and keyword) is interesting; it can probably be its own discussion. (feels

[swift-evolution] [pitch] Atomics

There is no clean way to use atomic operations in Swift at the moment, even less so after most of OSAtomic.h was deprecated in Sierra. Of course, the OSAtomic calls were never available in Linux, so there are no atomics at all on that side. It's technically possible to wrap clang’s C11 atomics

Re: [swift-evolution] Sequence/Collection Enhancements

A question that comes up often and has also led to a few syntax suggestions revolves around Optionals of Collections or Sequences. Since they can easily arise through optional chaining, making optional sequences easier to use would be useful. Much could be accomplished post-SE-0143 by adding a

Re: [swift-evolution] [swift-users] for in? optionalCollection {

This could come for almost free after SE-0143 is implemented: an Optional of a Sequence could itself be made to conform to Sequence. It would cost no new syntax. extension Optional: Sequence where Wrapped: Sequence { func makeIterator() -> AnyIterator { switch self { case .some(let

Re: [swift-evolution] Reduce with inout

> On 18 janv. 2017, at 10:21, Joe Groff via swift-evolution > wrote: > >> On Jan 18, 2017, at 2:11 AM, Chris Eidhof via swift-evolution >> wrote: >> >> If stressing the type-checker is the only problem, then maybe we should >> improve

Re: [swift-evolution] Consolidate Code for Each Case in Enum

> On 9 janv. 2017, at 10:54, Tim Shadel via swift-evolution > wrote: > > Enums get large, and they get complicated because the code for each case gets > sliced up and scattered across many functions. It becomes a "one of these > things is not like the other"

Re: [swift-evolution] Move placement of 'throws' statement

> On 28 déc. 2016, at 10:52, Dave Abrahams via swift-evolution > wrote: > > on Tue Dec 27 2016, Chris Lattner wrote: > >> it would be ambiguous to move the ‘throws’ keyword to the end of the >> function type, because you'd get: >> >> let x : (_ a : Int) -> (_

Re: [swift-evolution] What about renaming Optional.map to Optional.mapMe ?

No. I would like to point out that, as used in functional programming, “map” matches the following dictionary definitions: Map (verb): • associate (a group of elements or qualities) with an equivalent group, according to a particular formula or model: the transformational rules map deep

[swift-evolution] asyncAfter(deadline: ...)

Hello, The newer version of the libdispatch overlay (as of 8ac413a) looks good: thanks for your work Matt! It replaced async(when: ) with asyncAfter(deadline: ); however dictionaries say: deadline |ˈdedˌlīn| noun 1 the latest time or date by which something should be completed

Re: [swift-evolution] Change Request: Make myString.hasPrefix("") and myString.hasSuffix("") return true

> On 20 juil. 2016, at 14:21, Xiaodi Wu wrote: > > Doesn't your second argument undermine your first? If it's a trivial solution > and one rarely ever considers empty strings when invoking `hasPrefix`, then > returning the technically correct result must be a trivial

Re: [swift-evolution] Change Request: Make myString.hasPrefix("") and myString.hasSuffix("") return true

> On 20 juil. 2016, at 12:42, Michael Peternell via swift-evolution > wrote: > > +1 > this should be a bugfix. First, NSString’s prefix function returns false for empty string parameters, and this would be a significant departure in behaviour. Second, while an

Re: [swift-evolution] [Review] SE-0110: Distinguish between single-tuple and multiple-argument function types

> * What is your evaluation of the proposal? Positive. I thought this was a bug, post SE-0029. > * Is the problem being addressed significant enough to warrant a change to > Swift? Yes. > * Does this proposal fit well with the feel and direction of Swift? Yes. > * If you have used other

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0107: UnsafeRawPointer API

>> * What is your evaluation of the proposal? This is an excellent proposal, and a step forward in balancing safety and un-safety in an understandable way. I have no issues about the substance, but two documentation issues: - the compiler’s strict aliasing rules: not clearly defined in this

Re: [swift-evolution] [Draft] Rationalizing Sequence end-operation names

I like this draft. Quickly: - “removing” sounds more destructive than “skipping”, so I’d lean towards using “skipping”. I would be happy with either, though. - there are two different labels for predicates (where and while). “where” is probably the better label. (some previous discussion had

Re: [swift-evolution] [Returned for revision] SE-0077: Improved operator declarations

> On 23 juin 2016, at 09:32, Anton Zhilin via swift-evolution > wrote: > > Ross O'Brien via swift-evolution writes: > >> The naming suggestion: why not simply 'precedes' and 'succeeds'? This > avoids the conjoined words problem. Then you're

[swift-evolution] libdispatch renaming feedback

Here’s some feedback after translating some Dispatch-heavy code for the new Dispatch module. 1. I like the result. Thanks for the effort! 2. Omissions - Can't initialize a new queue or obtain a global queue using a DispatchQoS instance. [SR-1770] One thing I have previously done was the

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

> On 18 mai 2016, at 15:09, Xiaodi Wu via swift-evolution > wrote: > > > Yeah, also good points. Can I propose maybe another approach? > > ``` > T.operator(+, a, b) > T.operator(prefix: ++, a) > T.operator(postfix: ++, a) > ``` I like that this applies the

Re: [swift-evolution] [Review] SE-0088: Modernize libdispatch for Swift 3 naming conventions

> * What is your evaluation of the proposal? I like it; with the fixes already mentioned by Matt, I have some extra comments and questions: - It would be nicer to use the Dispatch namespace, rather than prefix everything. - It seems unfortunate to have 11 DispatchSourceSUBTYPE protocols at top

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

Re: [swift-evolution] [Review] SE-0076: Add overrides taking an UnsafePointer source to non-destructive copying methods on UnsafeMutablePointer

> * What is your evaluation of the proposal? It makes sense to have `assignFrom` and `initializeFrom` defined for `UnsafePointer` sources. I would much rather see them defined simply with `UnsafePointer` rather than having overloads. The ability to use UnsafeMutablePointer with UnsafePointer

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

Thanks Brent -- I completely agree with your assessment. I was failing to come up with the proper argument for just about the same idea! Guillaume Lessard > On 8 avr. 2016, at 18:32, Brent Royal-Gordon via swift-evolution > wrote: > >> The 'flatten()' method didn't

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

I agree. The related types (currently FlattenCollection, FlattenSequence) should get renamed as well. Cheers, Guillaume Lessard ___ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution

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

A different direction would be to add a non-autoclosure variant to ?? that explicitly takes a closure. public func ??(optional: T?, defaultValue: () throws -> T) rethrows -> T { switch optional { case .Some(let wrapped): return wrapped case .None: return try defaultValue() } } Then, the

Re: [swift-evolution] [Proposal] Make optional protocol methods first class citizens

> On 31 mars 2016, at 22:01, Chris Lattner via swift-evolution > wrote: > > Protocol requirements with default (no-op) implementations already satisfy > that design goal, no? They do, but that is not clear for everyone. And after protocol extensions appeared with

Re: [swift-evolution] [SE-0011] Re-considering the replacement keyword for "typealias"

> On 21 déc. 2015, at 17:57, Jordan Rose via swift-evolution > wrote: > > When you're actually implementing a generic function, the generic parameter > is [snip] Here's a word with meaning: parameter. Everything else I've seen sounds vague or approximate. Using

Re: [swift-evolution] [Review] Tuple comparison operators (was: Add a Lazy flatMap for Sequences of Optionals)

I wholeheartedly support the Equatable (==) portion of this proposal. I’m quite negative about the Comparable portion; it doesn’t really make sense. The justification for making Tuples comparable pretty much consists of hand-waving. Why should (0,3,4) be smaller than (0,5,0)? Beats me. Why would

Re: [swift-evolution] [SE-0011] Re-considering the replacement keyword for "typealias"

> On 22 déc. 2015, at 19:01, Douglas Gregor via swift-evolution > wrote: > > >> On Dec 22, 2015, at 11:05 AM, Matt Whiteside via swift-evolution >> wrote: >> >> “parameter” is a good thought. On it’s own it seems like it’s missing >>

Re: [swift-evolution] [Proposal Draft] Flexible memberwise initialization

> On 22 déc. 2015, at 12:02, Matthew Johnson wrote: > > This is not an attempt to subvert `let` properties. The `= 1` in the > declaration can very reasonably be viewed as a default value that should be > used if the member is not otherwise initialized. I see it as a

Re: [swift-evolution] [Proposal Draft] Flexible memberwise initialization

(adding on) > On 22 déc. 2015, at 12:02, Matthew Johnson wrote: > > Why would you have an immutable instance member that is always going to have > a constant value of 1? That’s obviously a toy example. You can also use function calls, and that’s useful: public struct

Re: [swift-evolution] [Review] Tuple comparison operators (was: Add a Lazy flatMap for Sequences of Optionals)

> On 22 déc. 2015, at 14:03, Kevin Ballard via swift-evolution > <swift-evolution@swift.org> wrote: > > On Tue, Dec 22, 2015, at 10:39 AM, Guillaume Lessard via swift-evolution > wrote: >> >> The justification for making Tuples comparable pretty much consists

Re: [swift-evolution] [Review] Tuple comparison operators (was: Add a Lazy flatMap for Sequences of Optionals)

> On 22 déc. 2015, at 19:40, Dave Abrahams wrote: > > It’s very convenient for “<“ to correspond to the standard strict-weak > ordering for a type where possible. Convenient maybe. Is it advisable for a standard library feature? Doubtful. This is about the definition