Re: [swift-evolution] Which functionality should be covered by a native Swift math/numerics library that ships with the standard lib?

ble fixed-size arrays. > > Félix > > Le 5 août 2016 à 04:53:20, Taras Zakharko via > > swift-evolution<swift-evolution@swift.org(mailto:swift-evolution@swift.org)>a > > écrit : > > > > > > > A few things immediately spring to mind: > >

Re: [swift-evolution] Which functionality should be covered by a native Swift math/numerics library that ships with the standard lib?

> A few things immediately spring to mind: > • Fixed-size arrays > • An optimized Matrix type > • Swifty syntax for Fourier transforms > • A numerical integrator (or diff-eq solver!) > • BigInt capabilities > > The first of these (fixed-size arrays) will probably require compiler support.

Re: [swift-evolution] [Accepted with Revision] SE-0177: Allow distinguishing between public access and public overridability

Great news! Given that this was probably the most polarising proposal ever, I am very impressed with the patience and professionalism the core team has shown in handling the situation and ultimately converging on an elegant solution — all that under oppressive deadline! A barrel of whiskey

Re: [swift-evolution] [Revision] [Pitch] Rename `T.Type`

> On 22 Jul 2016, at 12:11, L. Mihalkovic <laurent.mihalko...@gmail.com> wrote: > > > > Regards > (From mobile) > > On Jul 22, 2016, at 9:22 AM, Taras Zakharko via swift-evolution > <swift-evolution@swift.org <mailto:swift-evolution@swift.org>>

Re: [swift-evolution] [Revision] [Pitch] Rename `T.Type`

To be honest, I have difficulty with the terminology here. Why use the term ‚metatype‘ in the first place? Why not just ‚Type'? Or ‚TypeDescriptor‘ (in analogy to ObjectIdentifier)? What do we actually gain by the technical distinction between a type and a type of a type? I would understand it

Re: [swift-evolution] Extending declaration scope to condition for `repeat { } while ()`

This is definitively something very useful but it also introduces a strong asymmetry into Swift statements. In all control-flow statements, the condition is part of the outer scope. Or, to be more precise, its part of an intermediate scope between the outer and the inner scope (as you can

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

> On 18 Jul 2016, at 18:31, Xiaodi Wu wrote: > > At the same time, your solution results in a lot of unnecessary boilerplate. > > It's an exaggeration to say that it's *a lot* of boilerplate. It's one line > or two in the base class. > Sure, it might be rare with

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

> On 18 Jul 2016, at 14:07, Károly Lőrentey via swift-evolution > wrote: > > > I see no drawback to this pattern; it is quite clear and simple. Therefore, > in the interest of keeping the language free of needless complexity, I > suggest we change the proposal to

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

> On 16 Jul 2016, at 18:05, Jose Cheyo Jimenez via swift-evolution > wrote: > > I agree with Kevin Ballard on being open by default for methods/ properties > http://article.gmane.org/gmane.comp.lang.swift.evolution/23467/ >

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

> * What is your evaluation of the proposal? +1. Looks much better than the previous version and makes a lot of sense to me. A quick clarification question (I didn’t find any mention of this in the proposal, but I might have missed it): what happens if a class is declared open, but does

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

I have deliberately kept away from the discussion on this topic, as I didn’t feel like I can contribute in any meaningful way. In all honesty, I have barely used ‚traditional’ OOP paradigms in the last few years at all. While OOP is a useful tool and its great for modelling certain relationship

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

Great! This cleanly separates between the type and the name/signature! Simple and consistent. Thank you! A clarification question: do i understand correctly that steps 2 and 3 will not be included in Swift 3 due time constraints? — T > On 14 Jul 2016, at 06:47, Chris Lattner via

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

> * What is your evaluation of the proposal? +1. Fully support this change. ‚Optional' comparison operators hide the fact that the value is boxes which can lead to confusing behavior and difficult to find bugs. Personally, I always unbox my optionals before doing any kind of comparisons.

Re: [swift-evolution] [Pitch] Introduce continue to switch statements

There is some truth in every joke ;) I do like goto though. It makes my C code cleaner and easier to maintain. But given that Swift already has a very reasonable restricted goto mechanism with labels, I am as happy as it gets :) — T > On 12 Jul 2016, at 18:21, Douglas Gregor

Re: [swift-evolution] [Pitch] Introduce continue to switch statements

I’d love to see goto in Swift, but on the other hand, do {} with labels have so far been sufficient for any practical problem I encountered so far. Goto is much more useful in languages like C, which lack nested functions and other abstraction mechanisms. Of course, I wouldn’t try to write a

Re: [swift-evolution] [Pitch] Introduce continue to switch statements

There is possible impact on existing code: a switch statement inside a loop, that contains a continue. — Taras > On 11 Jul 2016, at 04:27, Erica Sadun via swift-evolution > wrote: > > A quick pitch to introduce `continue` to switch statements. This would be >

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

> On 09 Jul 2016, at 15:25, Goffredo Marocchi wrote: > > > Sent from my iPhone > > On 9 Jul 2016, at 11:31, Taras Zakharko > wrote: > >> Well, now that function type and function signature are officially separate >>

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

Well, now that function type and function signature are officially separate things, we need means to treat them as separate things. In particular, we need a way to force signatures on closure parameters (and maybe on some variables) while leaving function variables generally signature-agnostic.

Re: [swift-evolution] [Review] SE-0118: Closure Parameter Names and Labels

> * What is your evaluation of the proposal? In general +1, except maybe the change of to isOrderedBefore: by: in sort-related functions. I fear that the new label makes it less clear that the ordering relation is that of strict precedence. It can be particularly confusing for people

Re: [swift-evolution] [Idea] Wrap switch cases in curly braces

I always wrap my case blocks in curly braces. Personally, I agree with G.B. that the switch syntax seems inconsistent at best. While there are labels and limited form of goto in Swift, case labels don’t act anything like that. I’d prefer symmetry with if by having obligatory braces. — Taras

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

The designers of Swift have adopted a pragmatic approach to things: get a language that can be useful practically quickly, then improve it as things go. Its very Apple-like and I think it makes a lot of sense. We have a lot of useful changes in Swift 3.0, but the language is still far from

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

I would also be interested in a clarification on this point from Chris or someone else from the core team. The accepted proposal states that labels are illegal in function types (that is also what I was arguing for towards the end of the review discussion) but at the same time Cris mentions

Re: [swift-evolution] Bit arrays

> On 04 Jul 2016, at 00:44, Chris Lattner via swift-evolution > wrote: > > >> On Jul 3, 2016, at 2:42 PM, Daryle Walker via swift-evolution >> wrote: >> >> Since objects aren't addressable by default, there wouldn't be the problems >>

Re: [swift-evolution] Random ideas: goto, loop, multiple dispatch, explicit aliasing

Swift already has a very useful goto operator that avoids the usual problems associated with arbitrary control flow. With labels and continue/break you can implement very complex control flow schemas, but still maintain structured code. I have used it at multiple occasions and this is something

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

> > The goal of the review process is to improve the proposal under review > through constructive criticism and contribute to the direction of Swift. When > writing your review, here are some questions you might want to answer in your > review: > > * What is your evaluation of the

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

atural languages are really not a good source of inspiration in this regard. Best, Taras > On 01 Jul 2016, at 05:33, Jordan Rose <jordan_r...@apple.com> wrote: > >> >> On Jun 30, 2016, at 13:36, Taras Zakharko via swift-evolution >> <swift-evolution@swif

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

IMO, this is the most mathematically meaningful and semantically transparent solution. Floor and ceiling might be the popular terms but roundedUp/Down is much cleaner. > On 25 Jun 2016, at 20:55, Haravikk via swift-evolution > wrote: > > >> On 25 Jun 2016, at

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

> But again, this touches on some deep design decisions for the language, so I > — as an amateur — don’t feel in my plate discussing this here. I believe that > there currently might be some inconsistencies in the language design that > should be sealed with (but maybe they are no inconsi

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

> * What is your evaluation of the proposal? +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 > * If you have used other languages or libraries with

Re: [swift-evolution] [Review] SE-0109: Remove the Boolean protocol

> On 29 Jun 2016, at 15:47, Matthew Johnson via swift-evolution > wrote: > > > IIRC Optional conformed to this protocol early on and that conformance was > removed. In practice the idea of a protocol for "truthiness" to which > non-Boolean types conform caused

Re: [swift-evolution] [Review] SE-0109: Remove the Boolean protocol

Just a quick clarification: I was under impression that the utility of Boolean was that one could extend any type to behave as a boolean type and thus be used in control flow constructions etc. Not something that has to do often, but nice to have nevertheless. I would be sad if this

Re: [swift-evolution] [Accepted with Revision] SE-0099 Restructuring Condition Clauses

> On 09 Jun 2016, at 18:53, Ethan Eberle via swift-evolution > wrote: > > That said, the one process improvement I have is that proposals should > ideally only be “Accepted” by the core team as it is originally written (or > with relatively minor changes) or

Re: [swift-evolution] [Accepted with Revision] SE-0099 Restructuring Condition Clauses

A concern that I have with this is that comma seems to get inconsistent treatment in the language. In conditionals, commas clearly represent conjunctive clauses. However, the core team has also argued (review of SE-0095) that usage of comma implies disjunction and proposes that ‚&‘ is used for

Re: [swift-evolution] Add conversion String -> Bool

IMO, that is too idiosyncratic to be a standard language feature. You should extend Bool based on the specific needs of your application. Thats what the extensions are for. Best, t. > On 04 Jun 2016, at 15:10, Arsen Gasparyan via swift-evolution > wrote: > >

Re: [swift-evolution] [Returned for Revision] SE-0095: Replace protocol<P1, P2> syntax with Any<P1, P2>

I never had any problems with commas, as I always read them as conjunctive clauses, but I understand that an explicit conjunction may be less confusing. Personally, I’d prefer if there was no special syntax (aka Any<>) for existential types, whether generalised or not. I fail to see a principal

Re: [swift-evolution] Enhanced existential types proposal discussion

This looks very nice! Two questions/comments 1. I would prefer to write simpler existential types without Any, e.g.: let a: Sequence where Sequence.Iterator.Element == Int Is there a reason why we need Any<> at all, aside as a parsing aid? 2. If this proposal gets accepted, does it

Re: [swift-evolution] Change `repeat` to loop indefinitely if no while clause is present

When I need a loop with complex control flow that does not fit into the classical while {} or repeat {} while structure, I use this: do_stuff: do { … continue do_stuff } This pattern explicit and allows very complex control flow patterns without the drawbacks of the unrestricted goto

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

Hi Nate, I think this is a very useful addition! I also had a related proposal few days ago: https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160411/014665.html I feel like min/max

Re: [swift-evolution] [pitch] Eliminate the "T1 -> T2" syntax, require "(T1) -> T2"

+1 Makes language cleaner and more consistent. > On 15 Apr 2016, at 06:57, Chris Lattner via swift-evolution > wrote: > > We currently accept function type syntax without parentheses, like: > > Int -> Float > String -> () > > etc. The original rationale aligned

Re: [swift-evolution] [Pitch] Rename `x.dynamicType` to `x.Self`

True, that makes sense. I was simply trying to explore different possibilities of how these things could be represented in the syntax. What about #type(d) for static (declaration) type and type(v) for dynamic (value/instance) type? Or would that be potentially confusing as well? The reason

Re: [swift-evolution] What about a VBA style with Statement?

We had this kind of proposal earlier, didn’t seem to be very well received. I still think it would be a useful thing, but I’d do it as a statement (extension of do) that introduces new lexical scope (similar to self) — Taras > On 13 Apr 2016, at 16:25, Sean Heber via swift-evolution >

Re: [swift-evolution] [Proposal] Add .order() family of methods to Collection

Hi, I think it depends on how expensive the indexed access is on the collection. I use it primarily on arrays, where self[i] essentially boils down to a pointer dereference, so I expect the generated code to be very efficient. Your version might be faster for collection with expensive element

Re: [swift-evolution] [Review] SE-0065 A New Model for Collections and Indices

> * What is your evaluation of the proposal? +1. I think it makes the collection model more simple and more flexible at the same time. By coupling index to a specific collection, rather then treating it as a separate, independent entity, we can more easily implement alternative

Re: [swift-evolution] [Proposal] Allow optional binding of instance variables in constructors

ne runs into the problem that these variables can be accessed from outside. This is why I am suggesting to restrict guard to constructors only and fail the object construction if the guard fails. — Taras > > Jacob > > On Mon, Apr 11, 2016 at 12:31 AM, Taras Zakharko via sw

[swift-evolution] [Proposal] Add .order() family of methods to Collection

Swift standard library already offers a useful set of sort() functions. However, it is also often useful to know how the collection should be rearranged in order to become sorted. For example, R defines the order() function which returns a permutation of collection indexes which rearrange the

[swift-evolution] [Proposal] Allow optional binding of instance variables in constructors

One place where I find myself using the guard statement a lot is state initialisation. E.g. in init() guard let device = MTLCreateSystemDefaultDevice(), library = device.newDefaultLibrary() else { fatalError(“Could not initiallize Metal, aborting”) } Here, the two

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

At first, I was opposed to this idea but after working with many heterogeneous implementations of the same protocol, where instance creation needs to be dynamically dispatched to based on the properties of the data, I think that factory initialisers might be a nice idea. However, it would IMO

Re: [swift-evolution] [Draft]: Introducing a striding(by:) method on 3.0 ranges

I am agnostic on a .striding() method, but I am strongly agains any suggestions of removing/replacing the global stride() function. The stride function does not pollute the global namespace as it is a universally useful construct (among others, for implementing classical iterating for loops),

Re: [swift-evolution] [Review] SE-0059: Update API Naming Guidelines and Rewrite Set APIs Accordingly

replaceWith* is also my favourite here (same for *InPlace). Sure, it might be verbose, but the semantics is very clear and seems apply to a wide range of relevant situations. In the end, there are hundreds if not more messages in this (and related) threads and i am sure that you guys spent even

Re: [swift-evolution] [Review] SE-0036: Requiring Leading Dot Prefixes for Enum Instance Member Implementations

How would this work with OptionSetType? It also uses leading dot prefixes for initialisers, but implementations are usually structs. If I understand correctly, leading dot can be used in any case where the type can be inferred by the compiler. Changing the rules for enums seems strange to me.

Re: [swift-evolution] [Suggestion] Case-based dispatch for enum methods

rror along the lines of ‘missing implementation for func() for case A, B, C' > > TJ > > On Tue, Apr 5, 2016 at 1:57 AM, Taras Zakharko via swift-evolution > <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: > Is the lack of comments due

Re: [swift-evolution] [Suggestion] Case-based dispatch for enum methods

Is the lack of comments due to general disinterest in such a thing or did my mail go amiss somehow? ;) Best, Taras > On 31 Mar 2016, at 14:39, Taras Zakharko wrote: > > Recently, I have been working on implementing some non-trivial data > structures in Swift (its

Re: [swift-evolution] [Proposal] Custom operators

I think this is a great suggestion! One potential problem I can see (if I understood this correctly) is that modules are allowed to set up their own precedence rules for operators defined elsewhere. I think this might lead to some difficult to debug errors if a developer of one module (who is

Re: [swift-evolution] [Idea] Find alternatives to `switch self`

This is what happens if you don’t follow the swift-evolution list for a while… I have send a very similar suggestion to the list today (but mine focuses more on methods). Didn’t mean to plagiarise your idea, sorry! Maybe we should bring the two of them together. Best, Taras > On 23 Mar

Re: [swift-evolution] Thoughts regarding readable INTENT of Loop keywords

I do not see how this is more readable. The current for loop is perfectly readable and conveys the intent very well IMO: it executes a code block FOR every ELEMENT that is IN a SEQUENCE. In contrast, I find your proposal rather confusing: it combines a number of different constructions with

Re: [swift-evolution] A (better) Swift Equivalent For The Classical For-Loop With Numeric Scalars

> On 21 Mar 2016, at 17:05, ted van gaalen wrote: > > Hello Taras > Please take a look here: > https://en.m.wikipedia.org/wiki/For_loop > > > More than 30 ! programming languages since 1957 until now, have their >

Re: [swift-evolution] A (better) Swift Equivalent For The Classical For-Loop With Numeric Scalars

To be honest, I have difficulty understanding the premise of this discussion. I have always found the C-style for(;;) loop an awkward construct, because it is essentially just an alternative form of writing a general-purpose while loop. It is perfectly reasonable to restrict the for construct

Re: [swift-evolution] [Proposal] Lexical scope statement (with .. do)

gt;>>>> >>>>> let obj = MyClass() >>>>> do with obj { >>>>> prop1 = v1 >>>>> setup2() >>>>> } >>>>> >>>>> a combined assignment form such as >>>>> >>>&g

Re: [swift-evolution] [Proposal] Lexical scope statement (with .. do)

a great idea! > > Kind regards, > Radek > > > On 27 Dec 2015, at 21:10, Taras Zakharko via swift-evolution > > <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: > > > > Quite often, one needs to perform a number of operations on a s

Re: [swift-evolution] [Proposal] Lexical scope statement (with .. do)

gt;>>>> >>>>> let obj = MyClass() >>>>> do with obj { >>>>> prop1 = v1 >>>>> setup2() >>>>> } >>>>> >>>>> a combined assignment form such as >>>>> >>>&g

Re: [swift-evolution] [Proposal] Lexical scope statement (with .. do)

) >>>> do with obj { >>>> prop1 = v1 >>>> setup2() >>>> } >>>> >>>> a combined assignment form such as >>>> >>>> do with let obj = MyClass() { >>>> prop1 = v1 >>>> setu