Re: [swift-evolution] [Proposal] Sealed classes by default

I for one would very much like this discussion to start again. Yes it was discussed. Unfortunately, it was discussed in a summer time when in my country at least, many of us are off the grid for vacation. This is not a criticism of the process of course, just an indication that not everyone may

Re: [swift-evolution] [Proposal] Sealed classes by default

This is a detail of implementation and doesn't have to be. You might even imagine the compiler emitting two versions of the code, one assuming the class will not be subclassed, the other not assuming that, and a smart linker linking the right version depending on the case. So for me, in the

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

> > * What is your evaluation of the proposal? > I am strongly opposed to that proposal. I am mostly a lurker on this list, the volume of which I cannot cope with. However, I feel this proposal is important enough that I decided to invest more time than usual. So I have read carefully the

Re: [swift-evolution] Seriously! Freeze Swift For Two Years After Release 3.0 !

Ted, I basically disagree 100% with everything you wrote. I will not got into much details, but for me, technology that doesn’t evolve is dead technology. Moreover, your main argument about large code bases, is not a good one: we now have migration tools that work quite well. They could be

Re: [swift-evolution] pattern matching on variable-sized data type

The recursive call should obviously read return 〘 a-b 〙 ⋙ listOfDifferenceOfListElements(tail) Jean-Denis > On 06 Sep 2016, at 16:48, Jean-Denis Muys wrote: > > Hello, > > I would like to suggest an additive evolution to Swift that might be in scope > of phase 1 of

[swift-evolution] pattern matching on variable-sized data type

Hello, I would like to suggest an additive evolution to Swift that might be in scope of phase 1 of Swift 4 (because it might have an impact on the ABI). The idea is to extend the pattern matching abilities of Swift to enable a recursive programming style that’s very common in languages such as

[swift-evolution] pattern matching on variable-sized data type

Hello, I would like to suggest an additive evolution to Swift that might be in scope of phase 1 of Swift 4 (because it might have an impact on the ABI). The idea is to extend the pattern matching abilities of Swift to enable a recursive programming style that’s very common in languages such as

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

I watched this thread with a lot of attention, starting neutral. You must say that Karl won me over. His proposal would make Swift more expressive, and less error prone in cases of protocol conformance with name collisions. I am at this point +1 Jean-Denis Sent from my iPhone > On 22 Sep

Re: [swift-evolution] [Proposal] Refining Identifier and Operator Symbology

Before and above anything else, if I read the proposal correctly, we will not be able any more to use math operator signs as operators, beyond the paltry half dozen or so in the ASCII character set??? I strongly oppose such a restriction. Maths symbols (including ∪) are widely recognised in

Re: [swift-evolution] [pitch] "import" declaration, support for comma-separated modules

I don't agree with the line of reasoning that goes something like that: "Event though you have , I want to forbid every one from using additive feature X because I don't like it, given " I also don't understand why this would impede qualified import syntax. What is wrong with: import func

Re: [swift-evolution] [Review] SE-0144: Allow Single Dollar Sign as a Valid Identifier

While I already tersely supported this proposal, following all the negative reactions, I feel compelled to revisit my position. The main reason is that it strikes me that most points of view so far, including mine, were really culturally short sighted, and far too much US-centric. I totally agree

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

A clear win for me. +1 > On 11 Oct 2016, at 23:28, Nate Cook via swift-evolution > wrote: > > Introduction > > This proposal addresses significant unexpected performance gaps when using > dictionaries. It introduces type-specific collections for a Dictionary >