Re: [swift-evolution] [Draft] Hasher & HashVisitable

>> On 2017. Mar 14., at 2:44, Xiaodi Wu via swift-evolution >> wrote: >> >> On Mon, Mar 13, 2017 at 8:30 PM, Tony Allevato via swift-evolution >> wrote: >> Adding the list back to this reply because I don't believe you meant to >> reply

Re: [swift-evolution] [Draft] Hasher & HashVisitable

I think standardizing on a “correct” way to combine multiple hashable components into a single hash is an important step toward automating it. Visitor-based hashing simplifies the implementation of Hashable by essentially making it into a simple decision about which components to include in the

Re: [swift-evolution] [Draft] Hasher & HashVisitable

Yes please! I’ve a package on GitHub to implement roughly the same thing. I’ve been happily using it for months now, and I wouldn’t ever write a hashValue implementation by hand again. https://github.com/lorentey/SipHash I think the fact that we’ve both

Re: [swift-evolution] Sort Descriptors

> On 2016-11-03, at 19:39, Chris Eidhof via swift-evolution > wrote: > I was wondering if there's any interest in adding Swift-like sort descriptors > to the language. Currently, we have `sort` and `sorted`, which take a > function of type `(A, A) -> Bool`.

Re: [swift-evolution] [Proposal Draft] Provide Custom Collections for Dictionary Keys and Values

I believe the implementation of efficient in-place mutation is very explicit in the code -- it is done by implementing DictionaryValue’s subscript using a special “mutableAddressWithNativeOwner” addressor instead of a normal setter.

Re: [swift-evolution] [Proposal Draft] Provide Custom Collections for Dictionary Keys and Values

outside stdlib; the same issues tend to come up in custom collections, too.) :-( > On 2016-10-12, at 17:58, Károly Lőrentey via swift-evolution > <swift-evolution@swift.org> wrote: > > I think this is a lovely approach to solving this API design problem. > > One thing I do

Re: [swift-evolution] [Proposal Draft] Provide Custom Collections for Dictionary Keys and Values

I think this is a lovely approach to solving this API design problem. One thing I don’t quite understand yet is how these kinds of mutable views interact with copy on write semantics. COW rules can be subtle, and these views seem to put an extra twist on top that seems hard to

Re: [swift-evolution] [Pitch] deprecating ManagedBufferPointer

+1 ManagedBuffer has been really useful a couple of times, but I never found a use for ManagedBufferPointer. I can’t even say I’m entirely sure what need it was originally designed to fulfill. > On 2016-10-11, at 00:12, Erik Eckstein via swift-evolution > wrote: >

Re: [swift-evolution] [Review #3] SE-0117: Allow distinguishing between public access and public overridability

<rjmcc...@apple.com> wrote: > >> >> On Jul 22, 2016, at 9:09 AM, Károly Lőrentey via swift-evolution >> <swift-evolution@swift.org> wrote: >> >> On 2016-07-21 15:33:37 +, Chris Lattner via swift-evolution said: >>> * What is your eval

Re: [swift-evolution] [Review #3] SE-0117: Allow distinguishing between public access and public overridability

On 2016-07-21 15:33:37 +, Chris Lattner via swift-evolution said: * What is your evaluation of the proposal? I gave enthusiastic thumbs up to the previous two proposals. I agree wholeheartedly with the underlying goal, and I love the new Motivation section. I'm OK with the idea of

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

> On 2016-07-20, at 19:34, John McCall wrote: > > I agree that having the concept of "visible publicly but only arbitrary > modifiable internally" adds complexity to the language. However, once we've > got non-open public classes — and as I understand it, you still

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

> On 2016-07-18, at 19:05, John McCall via swift-evolution > wrote: > The basic effect of Károly's counter-proposal is that every public member of > an open class has to be marked either "open" or "final". That's boilerplate. My primary point was that there is no

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

On 2016-07-19 11:35:03 +, Brent Royal-Gordon via swift-evolution said: On Jul 19, 2016, at 4:00 AM, Károly Lőrentey via swift-evolution <swift-evolution@swift.org> wrote: "dynamic final" is prohibited by the current version of compiler. Huh, I didn't know tha

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

On 2016-07-19 00:46:21 +, Brent Royal-Gordon via swift-evolution said: On Jul 18, 2016, at 12:06 PM, Károly Lőrentey via swift-evolution <swift-evolution@swift.org> wrote: Introducing "dynamic" or some other keyword to mark explicitly methods that should be overriden

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

On 2016-07-18 21:42:03 +, Leonardo Pessoa via swift-evolution said: On 18 July 2016 at 16:06, Károly Lőrentey wrote: If adding an extra qualifier turns out to be an onerous requirement, we can choose a default at any time later, without breaking existing code.

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

If people were generally happy with having public members of open classes overridable by default, then we certainly wouldn't need to have a separate qualifier for that. (Although as "internal" demonstrates, it's nice to have a formal name for such things.) However, (1) having a default would

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

On 2016-07-18 16:15:10 +, Leonardo Pessoa via swift-evolution said: I believe sealed by default applied to functions makes the behaviour consistent with classes and allows for the same behaviour we wanted with this proposal. It would allows us to create subclassable classes in which we

Re: [swift-evolution] [Review] SE-0121: Remove `Optional` Comparison Operators

> On 2016-07-12, at 20:26, Chris Lattner via swift-evolution > wrote: > The review of "SE-0121: Remove `Optional` Comparison Operators" begins now > and runs through July 19. The proposal is available here: > > >

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

On 2016-07-18 09:17:43 +, David Hart via swift-evolution said: On 18 Jul 2016, at 11:11, Xiaodi Wu via swift-evolution wrote: On Mon, Jul 18, 2016 at 3:27 AM, Brent Royal-Gordon via swift-evolution wrote: > On Jul 17, 2016, at 8:57

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

> On 2016-07-16, at 07:52, Chris Lattner via swift-evolution > wrote: > The second review of "SE-0117: Default classes to be non-subclassable > publicly" begins now and runs through July 22. The proposal is available here: > > >

Re: [swift-evolution] Fixing modules that contain a type with the same name

For what it’s worth, I renamed OrderedSet to SortedSet in the Swift 3 version of BTree, so the original instance of this issue is hopefully no more. Prohibiting modules from containing a symbol of the same name would require a mass renaming of many microframeworks. Besides BTree, I also have

Re: [swift-evolution] [swift-evolution-announce] [Returned for revision] SE-0117: Default classes to be non-subclassable publicly

> On 2016. Jul 16., at 16:45, Karl via swift-evolution > wrote: > Sorry to mail 3 times in a row, but as I finished I remembered a concrete > example of where sealed protocols would be helpful: > > UIKit has a UITextInput protocol, which is used by custom text object

Re: [swift-evolution] [Review] SE-0120: Revise 'partition' Method Signature

* What is your evaluation of the proposal? +1; I like the new design, and I think once in a blue moon I may actually use the new API. I remember looking up partition in the stdlib docs, sighing and moving on once or twice. It seemed easier to write an explicit loop than to hammer

Re: [swift-evolution] An Alternative for Extensibility Modifiers

> On 2016-07-12, at 13:29, Jonathan Hull wrote: >> Note that most popular OOP languages provide well-known patterns for >> creating sealed but public classes, where only the author is able to >> create subclasses. These patterns typically involve hiding class >> constructors

Re: [swift-evolution] An Alternative for Extensibility Modifiers

On 2016-07-12 09:12:36 +, Jonathan Hull via swift-evolution said: With all the controversy around proposal 0117, I thought I would take a stab at an alternative approach that attempts to balance the concerns of both sides of the argument. I don’t know that it would be everyone's first

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

> On 2016-07-12, at 01:54, Colin Cornaby wrote: > >> - Slippery Slope: SE-0117 adds yet another entry to the already huge list of >> things in Swift that subtly or openly discourage people from subclassing. >> How far are we from someone seriously proposing to outright

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

On 2016-07-09 22:01:38 +, Károly Lőrentey via swift-evolution said: On 2016. Jul 9., at 22:55, Goffredo Marocchi <pana...@gmail.com> wrote: Why have they not "fixed" this issue with Java 6/7/8 if it is bad to have the current setup by default? Why C++ x09/x11/x14 is

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

On 2016-07-09 04:39:01 +, Jordan Rose via swift-evolution said: I wanted to share a concrete use case that Daniel Dunbar relayed to me. He was working on a closed class hierarchy like the ones discussed here, where all of the subclasses are within a single module, but they are all public.

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

> On 2016. Jul 9., at 22:55, Goffredo Marocchi wrote: > > Why have they not "fixed" this issue with Java 6/7/8 if it is bad to have the > current setup by default? Why C++ x09/x11/x14 is also not making everything > sealed/unsubclassable by default? I'd wager a guess that

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

> On 2016. Jul 9., at 18:04, Tino Heth via swift-evolution > wrote: >> Of course it can be done either way. But there are significant ecosystem >> robustness advantages to making sealed the default and comparatively few >> downsides. Most libraries are open source

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

* What is your evaluation of the proposal? Strong +1. I believe supporting public inheritance is the single most complicated thing in modern API design; thus, allowing inheritance to happen without explicit approval of the API designer is clearly a bad idea. I'm OK with the

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

> On 2016-06-25, at 14:23, Nicola Salmoria via swift-evolution > wrote: > The first comment I have to make is that, as has already been noted by plx, > the Arithmetic protocol looks like a "bag of syntax" with loose semantics > attached. It will be used by signed

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

instruction, while doing it in code requires a lot of work: https://github.com/lorentey/BigInt/blob/swift3/Sources/BigDigit.swift#L119-L176 > On 2016-06-24, at 20:52, Haravikk <swift-evolut...@haravikk.me> wrote: > > >> On 24 Jun 2016, at 18:17, Károly Lőrentey via swift

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

> * What is your evaluation of the proposal? +1 in general > * 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, with some nitpicks detailed below. > * If you have used other languages

Re: [swift-evolution] [Pitch] Retiring `where` from for-in loops

On 2016-06-10 11:39:34 +, Leonardo Pessoa via swift-evolution said: I would vow to remove where clauses altogether. Most of the times I used it in ifs, fors and switches I ended up thinking it hardened readability of my code (perhaps because of placement, but I do not think alternatives

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

+1 ** 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, very much so. ** If you have you used other languages or libraries with a similar feature, how do you feel that this proposal