[swift-evolution] Fixed-sized arrays

[I’ve seen the WWDC 2016 Keynote and State of the Platforms videos. I haven’t seen any others so I don’t spoil myself before typing my ideas down. Apologies if this has already been covered.] Is there any problem to adding fixed-sized arrays? From what I glanced here, it’s more like no one

Re: [swift-evolution] Stdlib closure argument labels and parameter names

On Jun 25, 2016, at 4:25 PM, Dave Abrahams wrote: > on Wed Jun 22 2016, Erica Sadun wrote: > On Jun 20, 2016, at 3:25 PM, Dave Abrahams via swift-evolution > wrote: >> >> -func forEach(_ body: (S.Iterator.Element) -> ()) >> +func

Re: [swift-evolution] Stdlib closure argument labels and parameter names

Comments inline: Sent from my iPhone > On 26 Jun 2016, at 00:25, Dave Abrahams via swift-evolution > wrote: > > >> on Wed Jun 22 2016, Erica Sadun wrote: >> >>> On Jun 20, 2016, at 3:25 PM, Dave Abrahams via swift-evolution >>>

Re: [swift-evolution] Stdlib closure argument labels and parameter names

on Thu Jun 23 2016, Erica Sadun wrote: >> On Jun 23, 2016, at 12:39 AM, David Hart wrote: >>> - for test in removeFirstTests.filter({ $0.numberToRemove == 1 }) { >>> + for test in removeFirstTests.filter( >>> +suchThat: { $0.numberToRemove == 1 } >>> >>>

Re: [swift-evolution] Stdlib closure argument labels and parameter names

on Wed Jun 22 2016, David Hart wrote: > I did not pay a lot of attention to this renaming because I thought > the trailing closure syntax would shield me from labels. But I forgot > that in if/for/while statements, I’m going to be forced to use > them. In those cases, I’d prefer more succinct

Re: [swift-evolution] Stdlib closure argument labels and parameter names

on Wed Jun 22 2016, Erica Sadun wrote: > On Jun 20, 2016, at 3:25 PM, Dave Abrahams via swift-evolution > wrote: >> >> >> Hi All, >> >> A couple of weeks ago we started to notice that we had some poorly-named >> closure parameters and argument labels in the

Re: [swift-evolution] Stdlib closure argument labels and parameter names

on Wed Jun 22 2016, Xiaodi Wu wrote: > On Wed, Jun 22, 2016 at 8:12 PM, Sean Heber wrote: > >> How about: >> >> let results = possibilities.where(matching: closure) >> > > My understanding is that we're restricting the bikeshedding here to the > closure label. Renaming

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0089: Replace protocol<P1, P2> syntax with Any<P1, P2>

Regards (From mobile) > On Jun 25, 2016, at 8:48 PM, Thorsten Seitz wrote: > > >> Am 25.06.2016 um 19:09 schrieb L. Mihalkovic : >> >> >> >> Regards >> (From mobile) >> >>> On Jun 25, 2016, at 6:34 PM, Thorsten Seitz via swift-evolution

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

L. Mihalkovic via swift-evolution writes: > Don't you think that for no other reason than completeness it would make sense to document the metacircular > definition I suggested? Okay, okay, I will. ___ swift-evolution mailing

[swift-evolution] BigDecimal functionalities or modulus support for NSDecimalNumber

Hello all, i was working with huge int numbers (28 digits) due to the developing of an algorithm to check the validity of IBAN bank codes (source: https://en.wikipedia.org/wiki/International_Bank_Account_Number ) The algorithm

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

We don't seem to have a rounded() function either as part of FloatingPoint, we should probably have these methods in the end: func rounded() -> Self func rounded(withPrecision: Int) -> Self Along with the 4 other methods proposed below. > Le 25 juin 2016 à 11:55, Haravikk via swift-evolution

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

> On 25 Jun 2016, at 11:06, Karl via swift-evolution > wrote: > > floor() and ceil(), exactly like C. ceiling() is more descriptive and is a > mathematical term of art . > nextIntegralUp() and nextIntegralDown() are

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0089: Replace protocol<P1, P2> syntax with Any<P1, P2>

> Am 25.06.2016 um 19:09 schrieb L. Mihalkovic : > > > > Regards > (From mobile) > > On Jun 25, 2016, at 6:34 PM, Thorsten Seitz via swift-evolution > > wrote: > >> Sorry for the late reply — I had

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

Hi all, Thank you for all your comments and feedback! I've rewritten and expanded the proposal to address as many peoples' concerns as possible. Best, Austin > On Jun 24, 2016, at 10:50 PM, Austin Zheng wrote: > > Hello all, > > Per Chris Lattner's list of open Swift

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

Don't you think that for no other reason than completeness it would make sense to document the metacircular definition I suggested? > On Jun 25, 2016, at 7:57 PM, Anton Zhilin via swift-evolution > wrote: > > I replaced `precedencegroup` with `precedence` and added

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

I replaced `precedencegroup` with `precedence` and added `Precedence` suffix to all precedence group names. See: https://github.com/Anton3/swift-evolution/blob/fix-operator- precedence/proposals/0077-operator-precedence.md My feelings: 1. `precedencegroup` describes what it declares more

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

> On Jun 25, 2016, at 6:23 AM, Matthew Johnson wrote: > > Hi Austin, > > I’m sorry to say, but this proposal makes me really sad. I consider > associated type inference one of the more elegant aspects of Swift. It would > be very unfortunate to lose it. There are

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

Hi Dmitri, Thanks for bringing this up. I surmise this option involves a user optionally marking a specific requirement in a protocol as being "chosen" to bind one or more associated types, with other requirements being forced to defer to that @infers-marked requirement. I don't think there

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

+1 to the proposal On Sat, 25 Jun 2016 at 17:48 David Sweeris via swift-evolution < swift-evolution@swift.org> wrote: > > > > Sent from my iPhone > On Jun 25, 2016, at 05:06, Karl via swift-evolution < > swift-evolution@swift.org> wrote: > > Proposal:

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0089: Replace protocol<P1, P2> syntax with Any<P1, P2>

Regards (From mobile) > On Jun 25, 2016, at 6:34 PM, Thorsten Seitz via swift-evolution > wrote: > > Sorry for the late reply — I had hoped to be able to think more deeply about > various points, > but I’m going to delay that instead of delaying the reply even

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

Sent from my iPhone > On Jun 25, 2016, at 05:06, Karl via swift-evolution > wrote: > > Proposal: https://gist.github.com/karwa/273db66cd8a5fe2c388ccc7de9c4cf31 +1 The only thing I'm worried about is the situation where we have "x = N.M", and `x.ceiling` equals

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0089: Replace protocol<P1, P2> syntax with Any<P1, P2>

Sorry for the late reply — I had hoped to be able to think more deeply about various points, but I’m going to delay that instead of delaying the reply even more :-) > Am 17.06.2016 um 19:04 schrieb Dave Abrahams : > > > on Thu Jun 16 2016, Thorsten Seitz wrote: > >>>

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

Yes! On Sat, Jun 25, 2016 at 11:33 Anton Zhilin via swift-evolution < swift-evolution@swift.org> wrote: > Xiaodi Wu via swift-evolution writes: > > > I mean, we have `protocol IteratorProtocol`, so this is par for the > course! > > precedencegroup RangePrecedence { ... } > >

[swift-evolution] [Proposal] Disallow implicit conversion between function/closure with a list of parameters and with tuple parameter. Remove function type inconsistency.

I believe this should be done for Swift 3.0 release as this is a *source breaking change* and IMO it is very important to remove the inconsistency mentioned below. We removed tuple splatting on caller side and IMO we must complete this job to delete the implicit connection between tuple and

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

Hi Matthew, I really like this proposal (even outside of its goal to simplify the type inference engine). The two other motivations in the proposal make very good points which can not be easily dismissed (especially to me as it took me a while to understand associated types): It improves the

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

Xiaodi Wu via swift-evolution writes: > I mean, we have `protocol IteratorProtocol`, so this is par for the course! > precedencegroup RangePrecedence { ... } Brandon sent me a bright idea: we should rename precedencegroup to precedence. Compare: precedence

[swift-evolution] [Proposal] Remove force unwrapping in function signature.

So, its proposal is dead, or what we must to do to force it to swift-evolution repo on GitHub? > Hello, everyone! > > I wanna propose to you to remove force unwrapping in fuction signature for > swift code. That no sense in clear swift code. If we wanna use some optional > value as function

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

I mean, we have `protocol IteratorProtocol`, so this is par for the course! On Sat, Jun 25, 2016 at 09:46 Anton Zhilin via swift-evolution < swift-evolution@swift.org> wrote: > From the rationale follows that by default, we get the following > precedence group declarations: > > precedencegroup

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

Sometimes I get the sense that the pleasure of discussing takes precedence over the goal it serves, namely to create a language that will be the most attractive it can be within a given complexity budget (meaning a balance between the immediate reward of shiny new things and the long term

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

From the rationale follows that by default, we get the following precedence group declarations: precedencegroup RangePrecedence { ... } Everyone agrees? Any ideas on how to reduce redundancy without adding name conflicts? ___ swift-evolution mailing

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

Hi Austin, I’m sorry to say, but this proposal makes me really sad. I consider associated type inference one of the more elegant aspects of Swift. It would be very unfortunate to lose it. I am really pleased to see that Dmitri has offered an alternative that looks very reasonable. I’m

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

> * What is your evaluation of the proposal? This is a great proposal which was sorely needed, so I strongly support it in general. I have a few comments and suggestions to make. First of all, a bit of background to explain where I'm coming from: in the past weeks I have been working for

Re: [swift-evolution] Prohibit invisible characters in identifier names

> 25 June 2016 06:13 Charlie Monroe wrote: > >> >> On Jun 25, 2016, at 12:21 AM, Magnus Ahltorp wrote: >> >> As far as I can see, forcing the programmer to write identifiers in an >> only-ASCII language, and requiring that identifier names have to be

Re: [swift-evolution] SE-0105: Removing Where Clauses from For-In Loops

> On 24 Jun 2016, at 23:38, William Jon Shipley > wrote: > >> On Jun 24, 2016, at 3:00 PM, Haravikk via swift-evolution >> > wrote: >> for colinearSegment in remainingSegments where >>

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

Proposal: https://gist.github.com/karwa/273db66cd8a5fe2c388ccc7de9c4cf31 Introduction, Motivation The standard library lacks equivalents to the floor() and ceil() functions found in the standard libraries of most other languages.

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

[swift-evolution] [Proposal] Revising access modifiers on extensions

Originally I started this topic in a discussion thread but moved it now into its own proposal thread due the lack of feedback. This proposal contains a breaking change! You can read a formatted version here: https://gist.github.com/DevAndArtist/8f1113b6d5d0379ebf82bd227cf4a88d Feel free to

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

On Fri, Jun 24, 2016 at 10:50 PM, Austin Zheng via swift-evolution wrote: > Hello all, > > Per Chris Lattner's list of open Swift 3 design topics > (http://article.gmane.org/gmane.comp.lang.swift.evolution/21369), I've put > together a proposal for removing type

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0095: Replace `protocol<P1, P2>` syntax with `P1 & P2`

> On Jun 25, 2016, at 9:00 AM, L. Mihalkovic > wrote: > > Inline > Regards > (From mobile) > >> On Jun 25, 2016, at 1:00 AM, Joe Groff via swift-evolution >> wrote: >> >> >>> On Jun 23, 2016, at 8:55 PM, Jordan Rose via

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0095: Replace `protocol<P1, P2>` syntax with `P1 & P2`

Inline Regards (From mobile) > On Jun 25, 2016, at 1:00 AM, Joe Groff via swift-evolution > wrote: > > >> On Jun 23, 2016, at 8:55 PM, Jordan Rose via swift-evolution >> wrote: >> >> [Proposal: >>

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

Okay, well, I'm +1 on this. I like that we got rid of conversions from/to U/IntMax in favor of more general initializers and the bitshift enhancements. I think that most generic algorithms on integers will get simpler. I'm not overly concerned/competent with floating-point numbers, but I'm sure

Re: [swift-evolution] Partial list of open Swift 3 design topics

Would you be willing to elaborate a bit on "Removing argument labels from the type system"? The bulk of this went away when tuple splatting was removed, and values of function type already seem to ignore the labels of the functions they are assigned. Best, Austin > On Jun 22, 2016, at 6:07