Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0159: Fix Private Access Levels

This and the reasons Drew laid out, are why I'm -1. > On Mar 23, 2017, at 19:48, Charles Srstka via swift-evolution > wrote: > >> On Mar 23, 2017, at 8:35 PM, Matthew Johnson via swift-evolution >> wrote: >> >> On Mar 23, 2017, at 8:27 PM, Drew Crawford wrote: >> >>> >>> >>> >>> Sent fr

Re: [swift-evolution] Disallowing many expressions with unused result (@error_unused_result?)

> On Mar 24, 2017, at 3:57 PM, Peter Dillinger via swift-evolution > wrote: > > I recently criticized Swift 3 for allowing many expressions with no side > effects as statements, in this blog post: > https://blogs.synopsys.com/software-integrity/2017/03/24/swift-programming-language-design-par

Re: [swift-evolution] [Review] SE-0159: Fix Private Access Levels

> On Mar 26, 2017, at 08:50, David James via swift-evolution > wrote: > > • What is your evaluation of the proposal? > -1 as written (see below) > > • Is the problem being addressed significant enough to warrant a change to > Swift? > Not as written > > • Does this proposal fit well with the

Re: [swift-evolution] [Pitch] Allow closures/default params to satisfy protocol requirements

> On Mar 26, 2017, at 11:12, Karl Wagner via swift-evolution > wrote: > > I’d like to pitch the following two language changes. Both of them are > technically possible today if you manually write thunks for the relevant > protocol requirements, but it would be nice if we allowed them to be wr

Re: [swift-evolution] [swift-build-dev] [Draft] Package Manager Custom Targets Layout

Agreed Sent from my iPhone > On Mar 26, 2017, at 22:27, Brent Royal-Gordon via swift-build-dev > wrote: > >> On Mar 24, 2017, at 1:26 PM, Ankit Aggarwal via swift-evolution >> wrote: >> >> sources: This property defines the source files to be included in the >> target, relative to the targ

Re: [swift-evolution] Disallowing unreachable code

> On Mar 27, 2017, at 11:27 AM, Peter Dillinger via swift-evolution > wrote: > >> -1, for all the reasons others have already explained. This unnecessarily >> complicates the debugging process. If you ship code with warnings still in >> it, that’s your own fault. > > All the obsolete/unfound

Re: [swift-evolution] Disallowing unreachable code

On Mar 28, 2017, at 21:55, Peter Dillinger via swift-evolution wrote: On Mar 28, 2017, at 9:40 PM, Peter Dillinger wrote: Agreed, we have the right design here. The go community has shown the result of taking a hard line on this, and it really hurts refactoring and

Re: [swift-evolution] [swift-build-dev] [Draft] Package Manager Custom Targets Layout

On Mar 29, 2017, at 10:19, Ankit Aggarwal via swift-build-dev wrote: > The proposal is updated with this change. What do we think about adding convenience inits that take a single parameter in place of the []s, for when we're only passing one value? The down side is that it makes it more com

Re: [swift-evolution] [swift-build-dev] [Draft] Package Manager Custom Targets Layout

> On Mar 29, 2017, at 10:56, Ankit Aggarwal wrote: > > We discussed variadic overloads during the manifest redesign proposal but > ultimately rejected it. We could add an overload for a singular source file > (instead of variadic) but I think its simpler to just have one option, and it > is a

Re: [swift-evolution] [Discussion] Arbitrary precision integer and float literal protocols

Sent from my iPhone > On Mar 30, 2017, at 14:56, David Hart via swift-evolution > wrote: > > Hello swift-evolution, > > I’m working on a proposal for arbitrary precision integer and float literal > protocols to complement ExpressibleByIntegerLiteral and > ExpressibleByFloatLiteral. I’m loo

Re: [swift-evolution] [Pitch] Remove type-inference for stored property

> On Apr 7, 2017, at 22:40, Pranshu Goyal via swift-evolution > wrote: > > I agree with the sentiment of the proposal, it does add value to overall > efficiency of swift and make things simpler for the swift team, but as > Matthew said a blanket ban will add noise to the code. Also this parti

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

> On Apr 8, 2017, at 12:03, Ben Cohen via swift-evolution > wrote: > > > > Hi swift-evolution, > > Another short proposal related to the Collection algorithms theme, this time > for removing elements in-place from a collection. > > Online copy here: > https://github.com/airspeedswift/swif

Re: [swift-evolution] [Pitch] Adding safety to arrays

> On Apr 13, 2017, at 3:56 AM, Andrew Hart via swift-evolution > wrote: > > Recently I’ve been considering the lack of safety around array indexes. Swift > is designed with safety in mind, so this example would not compile: > > var myString: String? = “hello” > myString.append(“ world!”) > >

Re: [swift-evolution] [Pitch] Adding safety to arrays

Sent from my iPhone > On Apr 13, 2017, at 07:34, Jeff Kelley wrote: > > Apologies if this has been suggested before, but going off of Andrew’s > message, a simple syntax could be to use our existing Optional syntax: > > let array = ["foo", "bar", "baz"] > > let first = array[0] // type is `

Re: [swift-evolution] [Pitch] Adding safety to arrays

> On Apr 13, 2017, at 08:53, Josh Parmenter wrote: > > This seems inconsistent to me. 2 is 2... 2 itself is not optional. You > wouldn't expect 2 to be unwrapped. Correct. I think the idea was that "2?" would get converted to an `Optional`, which would then call a subscript that took an `Inde

Re: [swift-evolution] [Review] SE-0168: Multi-Line String Literals

On Apr 12, 2017, at 07:52, Thorsten Seitz via swift-evolution wrote: >> Am 12.04.2017 um 15:40 schrieb Brent Royal-Gordon via swift-evolution >> : >> >> Hey folks, >> >> >> We've revised the proposal again. The main difference: You no longer need an >> initial newline to enable indentation

Re: [swift-evolution] [Review] SE-0168: Multi-Line String Literals

> On Apr 13, 2017, at 10:41, Adrian Zubarev > wrote: > > Was the / intended or did you meant to write \? > > Personally I don’t think we’d need that behavior and can fallback to the > natural way using a blank lines or explicit way using the \n character to > solve that issue at the top or b

Re: [swift-evolution] [Review] SE-0168: Multi-Line String Literals

> On Apr 13, 2017, at 10:52, Adrian Zubarev > wrote: > > I don’t think it’s a good idea to add optionally character before the closing > delimiter, because it could confuse the reader of the code on how exactly the > actual string lines above will be stripped. > > My personal vision remains

Re: [swift-evolution] [pitch] One-sided Ranges

> On Apr 12, 2017, at 20:31, Félix Cloutier via swift-evolution > wrote: > > I don't have a strong opinion; are we sure enough that this is what we want > the postfix operator … to be for? For instance, C++ uses it a lot with > variadic templates. I don't think the two usages conflict... may

Re: [swift-evolution] [Pitch] Adding safety to arrays

> On Apr 13, 2017, at 15:01, Tony Allevato wrote: > > My 2 cents: Giving users checked subscripts for arrays will do more harm than > good for novice programmers—they're going to do the wrong thing with them. I'm torn... On the one hand, I see the logic in this. On the other hand, I suspect m

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

> On Apr 13, 2017, at 17:51, Jonathan Hull via swift-evolution > wrote: > > I think “vastly” is vastly overstating it, especially since they are not > customization points… merely aliases. There is nothing else those operators > could do without causing confusion. Swift favors clarity, and

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

> On Apr 14, 2017, at 15:33, Matthew Johnson via swift-evolution > wrote: > > >>• What is your evaluation of the proposal? > > +0.5 because this is a half solution. I would also like to see a variant > which accepts an inout argument for the reduction to accumulate into. Out of curiosi

Re: [swift-evolution] [Review] SE-0166: Swift Archival & Serialization

> On Apr 15, 2017, at 9:40 AM, Karl Wagner via swift-evolution > wrote: > >> On 13 Apr 2017, at 06:20, Brent Royal-Gordon via swift-evolution >> mailto:swift-evolution@swift.org>> wrote: >> >>> On Apr 12, 2017, at 2:12 PM, Zach Waldowski via swift-evolution >>> mailto:swift-evolution@swift.o

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

> On Apr 16, 2017, at 09:56, Nevin Brackett-Rozinsky via swift-evolution > wrote: > > Another option is to make a new type, not sure what to call it but I’ll use > “Num” for now, that is essentially the same as Double except it does not > represent NaN. After all, why should a numeric type ev

Re: [swift-evolution] [Pitch] Swift needs fixed-size array

> On Apr 17, 2017, at 10:52 AM, Anders Kierulf via swift-evolution > wrote: > > Swift needs a datatype that contains a fixed number of a given type; > basically a simple fixed-size array. > > Motivation: I’ve been porting code for Monte Carlo Tree Search in my > Go-playing program from C++ t

Re: [swift-evolution] [Accepted] SE-0169: Improve Interaction Between `private` Declarations and Extensions

> On Apr 17, 2017, at 18:53, Nevin Brackett-Rozinsky via swift-evolution > wrote: > > At a meta-level, since mistakes like SE–0025 will be much more costly in the > source-stable future, we ought to consider adding a step to the Swift > Evolution process whereby accepted proposals are impleme

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

> On Apr 18, 2017, at 8:40 AM, Ben Cohen via swift-evolution > wrote: > >> >> On Apr 17, 2017, at 9:40 PM, Chris Lattner via swift-evolution >> mailto:swift-evolution@swift.org>> wrote: >> >> >>> On Apr 17, 2017, at 9:07 AM, Joe Groff via swift-evolution >>> mailto:swift-evolution@swift.or

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

Maybe we should make Float/Double conform to "IEEE754Comparable"/"IEEE754Equatable" instead of "Comparable"/"Equatable". Then it's all a moot point since floating point types wouldn't end up in the same generic functions as other comparable types. (Not sure if I'm serious) - Dave Sweeris > On

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

> On Apr 22, 2017, at 4:14 PM, Dave Abrahams wrote: > > > on Sat Apr 22 2017, David Sweeris wrote: > >> Maybe we should make Float/Double conform to >> "IEEE754Comparable"/"IEEE754Equatable" instead of >> "Comparable"/"Equatable". Then it's all a moot point since floating >> point types would

Re: [swift-evolution] Memoization for functions without parameters in enums

Sent from my iPhone > On Apr 25, 2017, at 06:44, Tierry Hörmann via swift-evolution > wrote: > > Hi all > > I discovered that memoization is currently a pain to implement when using > functional programming. > E.g. when implementing a lazy linked list, one obviously uses an enum to > repre

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

> On Apr 26, 2017, at 4:23 PM, Michel Fortin via swift-evolution > wrote: > >> Le 26 avr. 2017 à 18:33, Xiaodi Wu > > a écrit : >> >> On Wed, Apr 26, 2017 at 2:14 PM, Michel Fortin via swift-evolution >> mailto:swift-evolution@swift.org>> wrote: >> Just throwing a

Re: [swift-evolution] [Pitch] Revamp Optional and Throws

> On Apr 30, 2017, at 15:13, Gor Gyolchanyan wrote: > > So, what you’re saying is essentially equivalent to replacing Optional struct > with an Optional protocol with a default AnyOptional struct implementation, > right? I suppose something semantically identical could be implemented that way,

Re: [swift-evolution] [swift-build-dev] [Pitch] Swift run Command

> On May 15, 2017, at 11:49 AM, Daniel Dunbar via swift-build-dev > wrote: > > Huge +1 from me, and for having it build by default. Building should be > efficient & transparent to the user IMHO. Agreed. - Dave Sweeris ___ swift-evolution mailing li

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0179: Swift `run` Command

> On May 15, 2017, at 5:09 PM, Daniel Dunbar wrote: > > Hello Swift community, > > The review of SE-0179: Swift `run` Command begins now and runs through May > 25th, 2017. > > The proposal is available here: > > > https://github.com/apple/swift-evolution/blob/master/proposals/0179-swift-r

Re: [swift-evolution] [Review] SE-0176: Enforce Exclusive Access to Memory

> On May 12, 2017, at 19:29, Ben Cohen via swift-evolution > wrote: > > Hello Swift community, > > The review of revisions to SE-0176: Enforce Exclusive Access to Memory begins > now and runs through May 17, 2017. > > Most of this proposal was previously accepted. An implementation issue ha

[swift-evolution] Pitch: Allow generic functions to fulfill non-generic protocol requirements

So, I’m working on a type, and would like to make it conform to `ExpressibleByArrayLiteral`. The thing is, I don’t actually care what type `Element` is as long as it conforms to `FixedWidthInteger` and `UnsignedInteger`. I tried writing this: public init (arrayLiteral elements: U...) { … } B

Re: [swift-evolution] Pitch: Allow generic functions to fulfill non-generic protocol requirements

> On May 24, 2017, at 5:11 PM, Xiaodi Wu wrote: > > On Wed, May 24, 2017 at 3:32 PM, David Sweeris via swift-evolution > mailto:swift-evolution@swift.org>> wrote: > So, I’m working on a type, and would like to make it conform to > `ExpressibleByArrayLiteral`. The th

Re: [swift-evolution] Pitch: Allow generic functions to fulfill non-generic protocol requirements

> On May 24, 2017, at 5:52 PM, Xiaodi Wu wrote: > > On Wed, May 24, 2017 at 7:21 PM, David Sweeris <mailto:daveswee...@mac.com>> wrote: > >> On May 24, 2017, at 5:11 PM, Xiaodi Wu > <mailto:xiaodi...@gmail.com>> wrote: >> >> On Wed, May 24,

Re: [swift-evolution] Revisiting SE-0110

> On May 26, 2017, at 08:14, Robert Bennett via swift-evolution > wrote: > > Alternatively, for maximum consistency we could make "{ arg in ..." illegal > as well, requiring parentheses around "arg". This would mirror the > parentheses necessary in e.g., "let f: (Int) -> Int", and there would

Re: [swift-evolution] Yet another fixed-size array spitball session

> On May 29, 2017, at 01:12, Tino Heth via swift-evolution > wrote: > > I agree strongly that the syntax looks awkward — imho > var v: Vector > would be a much better fit than > var v array 3 of Int > > As much as I want to have "real" arrays, I don't think we should add new > keywords for th

Re: [swift-evolution] Yet another fixed-size array spitball session

> On May 29, 2017, at 2:39 PM, Nicolas Fezans wrote: > > There are many aspects in the initial proposal that certainly need a more > expert eye than mine. I have one question though. It seems to me that the > constant expressions as known as constexpr in C++11 would be allowed as well. > Is t

Re: [swift-evolution] Yet another fixed-size array spitball session

> On May 29, 2017, at 22:03, Pavol Vaskovic via swift-evolution > wrote: > > I'm sorry if I'm misunderstanding your proposal, but I think Swift already > has "array types whose size is fixed at compile time" called Tuple. Tuples don't support subscripting or protocol conformance. Or an easy s

Re: [swift-evolution] Yet another fixed-size array spitball session

> On May 30, 2017, at 03:25, Pavol Vaskovic wrote: > >> On Tue, May 30, 2017 at 7:51 AM, David Sweeris wrote: >> >> `(Int, Int, Int, Int)` isn't *that* horrible compared to "[Int x 4]", but >> would you want to replace "[Int8 x 1]" with the multipage-long tuple >> equivalent? > > 😳 > It

Re: [swift-evolution] Yet another fixed-size array spitball session

> On May 31, 2017, at 10:38 AM, Tino Heth via swift-evolution > wrote: > > I don't want to write things like "Vector3D" and "Vector4D" to wrap a static > array just to ensure that it has the right size, and I don't want to have > runtime-checks which would decrease the performance-benefit. +

Re: [swift-evolution] Can functions/methods be overloaded on mutability of parameters?

> On Jun 2, 2017, at 22:29, Daryle Walker via swift-evolution > wrote: > > Can I make two overloads such that one can take an argument from a “let”-mode > object or a regular function parameter and return an UnsafePointer and then > have the other take a “var”-mode object or inout function pa

Re: [swift-evolution] [Meta] WWDC week

+1, feels like it matches swift's direction Sent from my iPhone On Jun 5, 2017, at 20:53, Brent Royal-Gordon wrote: >> On May 30, 2017, at 10:26 PM, Brent Royal-Gordon >> wrote: >> >> I'm going to be in San Jose during WWDC next week, and I'm assuming I won't >> be the only one. Are there a

Re: [swift-evolution] Yet another fixed-size array spitball session

On Jun 6, 2017, at 10:55, Brent Royal-Gordon via swift-evolution mailto:swift-evolution@swift.org>> wrote: > >> On Jun 4, 2017, at 6:56 AM, Daryle Walker via swift-evolution >> mailto:swift-evolution@swift.org>> wrote: >> >> in which at least one is dubious in value (#2, since a lot of times th

Re: [swift-evolution] [Proposal] Uniform Initialization Syntax

> On Jun 8, 2017, at 05:09, Gor Gyolchanyan via swift-evolution > wrote: > > Disclaimer: I do realize that any of the following ideas may have been > discussed before and/or there might be a good reason for their lack of > implementation, so please go easy in me. 🙂 > > 1. Arbitrary `self` As

Re: [swift-evolution] History and future of Swift's parentheses

> On Jun 9, 2017, at 8:12 AM, Gor Gyolchanyan via swift-evolution > wrote: > >> >> So I wonder if any of you have had any thoughts about what Swift's >> parentheses-related future (or evolutionary baggage) will be? >> > > I really wish swift used the concept of tuples **exclusively** for al

Re: [swift-evolution] Pitch: Limit typealias extensions to the typealias

> On Jun 9, 2017, at 16:38, Daryle Walker via swift-evolution > wrote: > > >> On Jun 9, 2017, at 12:14 AM, Yvo van Beek via swift-evolution >> wrote: >> >> Typealiases can greatly reduce the complexity of code. But I think one >> change in how the compiler handles them could make them even

Re: [swift-evolution] Swift phases and mis-timed proposals

> On Jun 11, 2017, at 14:41, Haravikk via swift-evolution > wrote: > > Thing is; people are going to have ideas when they have them, and want to > discuss them right away. I've been caught out numerous times with proposals > that are almost immediately rejected as out of scope, and still have

Re: [swift-evolution] [Proposal] Change Void meaning

> On Jun 12, 2017, at 10:44, Jérémie Girault via swift-evolution > wrote: > > Void was the empty tuple because arguments were tuples. So no arguments meant > empty tuple. > > If we consider the empty tuple to be an argument, then the type for the type > of empty tuple should be `Unit` > > V

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

> On Jun 12, 2017, at 5:13 PM, Pavol Vaskovic via swift-evolution > wrote: > > On Sun, Jun 11, 2017 at 1:52 AM, Haravikk via swift-evolution > mailto:swift-evolution@swift.org>> wrote: > > With the ability to specify throwaway variables more easily, I'm sticking > with my using syntax here:

Re: [swift-evolution] [Proposal] Change Void meaning

> On Jun 12, 2017, at 10:45 PM, Gwendal Roué via swift-evolution > wrote: > > "Discussing" with Xiaodi is a special experience, isn't it? > > He will bite and misrepresent you and your ideas until you get tired and your > idea has been exhausted to death and diluted in dozens of useless messa

Re: [swift-evolution] Swift phases and mis-timed proposals

> On Jun 13, 2017, at 12:18 AM, John McCall via swift-evolution > wrote: > >> On Jun 13, 2017, at 1:08 AM, Jacob Bandes-Storch via swift-evolution >> mailto:swift-evolution@swift.org>> wrote: >> On Mon, Jun 12, 2017 at 9:31 PM, Paul Cantrell via swift-evolution >> mailto:swift-evolution@swift

Re: [swift-evolution] Swift phases and mis-timed proposals

> On Jun 13, 2017, at 12:34 AM, John McCall wrote: > >> On Jun 13, 2017, at 3:22 AM, David Sweeris > > wrote: >>> On Jun 13, 2017, at 12:18 AM, John McCall via swift-evolution >>> mailto:swift-evolution@swift.org>> wrote: >>> On Jun 13, 2017, at 1:08 AM, Jacob

Re: [swift-evolution] Swift phases and mis-timed proposals

> On Jun 13, 2017, at 11:46 AM, Erica Sadun via swift-evolution > wrote: > > I imagine that recent discussions like mapped keypaths, ordered sets, > `count(where:)`, etc. could have a home for discussion and exploration > without getting blocked by "out of scope" if there were a separate > "

Re: [swift-evolution] Swift phases and mis-timed proposals

> On Jun 12, 2017, at 7:16 PM, Jonathan Hull via swift-evolution > wrote: > >> On Jun 12, 2017, at 5:12 PM, Ted Kremenek via swift-evolution >> mailto:swift-evolution@swift.org>> wrote: >> >>> On Jun 12, 2017, at 12:47 PM, Paul Cantrell wrote: >>> >>> Concern #2 is that it’s hard to know wh

Re: [swift-evolution] floating point numbers implicit conversion

> On Jun 17, 2017, at 16:16, Xiaodi Wu via swift-evolution > wrote: > >> On Sat, Jun 17, 2017 at 3:21 PM, Ted F.A. van Gaalen >> wrote: >> >> As you know, Swift currently does not facilitate implicit conversion >> (coercion), >> which implies that current code (which of course does not cont

Re: [swift-evolution] floating point numbers implicit conversion

> On Jun 17, 2017, at 20:43, Xiaodi Wu wrote: > > In Swift, all types and all operators are implemented in the standard > library. How do you express the idea that, when you add values of disparate > types T and U, the result should be of the type with greater precision? You > need to be able

Re: [swift-evolution] floating point numbers implicit conversion

Off the top of my head? As the language stands now, maybe a ton of extensions so that it never actually hits the fully generic version? extension Addable where Self == Int8 {...} extension Addable where Self == Int16 {...} extension Addable where Self == Int32 { static func + (lhs: Self, rhs:

Re: [swift-evolution] In-line scope designators

> On Jun 19, 2017, at 11:45, Robert Bennett via swift-evolution > wrote: > > +1 for member variables, -1 for member functions. Functions take up too much > vertical space to make this convenient; Yeah, I think that really only made sense in the world of header files, where function declarat

Re: [swift-evolution] floating point numbers implicit conversion

Sent from my iPhone > On Jun 19, 2017, at 13:44, John McCall via swift-evolution > wrote: > >>> On Jun 19, 2017, at 1:58 PM, Stephen Canon via swift-evolution >>> wrote: >>> On Jun 19, 2017, at 11:46 AM, Ted F.A. van Gaalen via swift-evolution >>> wrote: >>> >>> var result: Float = 0.0 >

Re: [swift-evolution] [Proposal] Associated Type and Generic One-to-One Mapping

> On Jun 23, 2017, at 5:28 PM, David Moore via swift-evolution > wrote: > > I do indeed have quite a few real examples of this, such prompted me to bring > this up. I think this could be done without any impact to existing code, but > it would require some type of keyword. Take the following

Re: [swift-evolution] [Proposal] Associated Type and Generic One-to-One Mapping

For every Bar.T that is currently distinct from Foo.T, this would be > source-breaking. >> On Sat, Jun 24, 2017 at 01:51 David Sweeris via swift-evolution >> wrote: >> >> > On Jun 23, 2017, at 5:28 PM, David Moore via swift-evolution >> > wrote: >>

Re: [swift-evolution] [Pitch] New Version of Array Proposal

Sent from my iPhone > On Jul 23, 2017, at 08:45, Taylor Swift via swift-evolution > wrote: > > > >> On Sun, Jul 23, 2017 at 5:29 AM, Adrian Zubarev via swift-evolution >> wrote: >> I wanted to read the proposal, but skipped it as soon as I’ve seen the >> syntax. From the esthetic point o

Re: [swift-evolution] [Pitch] New Version of Array Proposal

> On Jul 23, 2017, at 09:08, Taylor Swift wrote: > > let fsa:[2 * Int] = [2 * 5, 3] // [10, 3] ??? Correct. If you wanted a multidimensional array, that'd be written "let nestedFSA: [2*[5*Int]]". Or, speculating a bit, I suppose maybe "let nestedFSA: [[5*Int]*2]", if we wanted there to be a c

Re: [swift-evolution] [Pre-pitch] Conform Int (and others) to LosslessStringConvertible

> On Jul 23, 2017, at 09:15, Matheus Martins via swift-evolution > wrote: > > I came across what i think is an inconsistency in the standard library. > > Why are some numeric types like Int not conforming to > LosslessStringConvertible by default while Float and Double do conform to it > in

Re: [swift-evolution] [Pitch] New Version of Array Proposal

On Jul 23, 2017, at 12:18, Taylor Swift mailto:kelvin1...@gmail.com>> wrote: > On Sun, Jul 23, 2017 at 2:21 PM, David Sweeris > wrote: > > On Jul 23, 2017, at 09:08, Taylor Swift > wrote: > >> let fsa:[2 * Int] = [2 * 5, 3] // [10, 3] ?

Re: [swift-evolution] [Pitch] New Version of Array Proposal

> On Jul 23, 2017, at 2:49 PM, David Sweeris via swift-evolution > wrote: > > > On Jul 23, 2017, at 12:18, Taylor Swift <mailto:kelvin1...@gmail.com>> wrote: > >> On Sun, Jul 23, 2017 at 2:21 PM, David Sweeris > <mailto:daveswee...@mac.com>> wr

Re: [swift-evolution] [Pitch] New Version of Array Proposal

> On Jul 23, 2017, at 2:49 PM, David Sweeris via swift-evolution > wrote: > > > On Jul 23, 2017, at 12:18, Taylor Swift <mailto:kelvin1...@gmail.com>> wrote: > >> Speaking of which, IIRC, at one point we were considering adding subscripts >> to tupl

Re: [swift-evolution] [Pitch] New Version of Array Proposal

> On Jul 23, 2017, at 8:32 PM, Taylor Swift wrote: > >> On Sun, Jul 23, 2017 at 5:48 PM, David Sweeris wrote: >> >>> On Jul 23, 2017, at 12:18, Taylor Swift wrote: >>> On Sun, Jul 23, 2017 at 2:21 PM, David Sweeris wrote: > On Jul 23, 2017, at 09:08, Taylor Swift wrote:

Re: [swift-evolution] [Pitch] New Version of Array Proposal

Which brings us I think full circle back to using literal values as generic parameters, "let fsa = FSA(whateverArgs) //where `Count` is an integer literal, or some other integer value that can be determined at compile time". - Dave Sweeris > On Jul 24, 2017, at 1:05 AM, Félix Cloutier via swif

Re: [swift-evolution] [Pitch] New Version of Array Proposal

> On Jul 24, 2017, at 9:22 AM, Félix Cloutier wrote: > > There are other alternatives that don't use generics. Last time this came > around, the straw man syntax was (4 x Int), and it was merely to be a > shorthand for (Int, Int, Int, Int). > > Every non-existing feature that needs to be impl

Re: [swift-evolution] [RFC] Definitive Initialization and Incompatibilities with Fixed-size Arrays

> On Jul 24, 2017, at 9:37 AM, Chris Lattner via swift-evolution > wrote: > > >> On Jul 23, 2017, at 4:27 PM, Félix Cloutier wrote: >> Well, fixed-size arrays don’t have initializers, for the same reason tuples don’t: they’re compound types instead of named types and they >

Re: [swift-evolution] [Pitch] Small bit of sugar for enum case with Void associated value

> On Jul 25, 2017, at 12:38, Robert Bennett via swift-evolution > wrote: > > Currently if you have the following enum: > > enum E { > case c(T) > } > > then if T is Void, you have to write one of the following: > > let x: E = .c(Void()) > let y: E = .c(()) > > Looks awkward, no? In th

Re: [swift-evolution] [Pitch] Small bit of sugar for enum case with Void associated value

> On Jul 25, 2017, at 2:20 PM, Xiaodi Wu wrote: > > Yes, I discussed this some time back. It breaks some things with overloads, > if I recall, but off the top of my head not recalling what. Functions that are overloaded with one version taking no arguments and another taking only some number

Re: [swift-evolution] Why couldn't a class call any of its superclass' initializers?

I think it's some subtlety... I might vaguely remember someone saying something about it. Since a proposal didn't come of that, I'm assuming there was a technical issue or something. I could easily be wrong, though. - Dave Sweeris > On Jul 25, 2017, at 9:36 PM, Daryle Walker via swift-evolution

Re: [swift-evolution] [Planning][Request] "constexpr" for Swift 5

> On Jul 31, 2017, at 1:37 PM, Gor Gyolchanyan via swift-evolution > wrote: > > >>> On Jul 31, 2017, at 11:23 PM, John McCall wrote: >>> >>> On Jul 31, 2017, at 4:00 PM, Gor Gyolchanyan wrote: > On Jul 31, 2017, at 10:09 PM, John McCall wrote: > >> On J

Re: [swift-evolution] [Idea] Custom keywords for operators.

Sent from my iPad > On Jul 31, 2017, at 2:09 PM, Gor Gyolchanyan via swift-evolution > wrote: > > So I was thinking the other day (and by "the other day" I mean "It just > occurred to me") that Swift's custom operator declaration mechanism is pretty > sweet (it's become even sweeter ever si

Re: [swift-evolution] [Planning][Request] "constexpr" for Swift 5

On Jul 31, 2017, at 12:15 AM, Gor Gyolchanyan via swift-evolution wrote: >> On Jul 31, 2017, at 7:10 AM, John McCall via swift-evolution >> wrote: >> >>> On Jul 30, 2017, at 11:43 PM, Daryle Walker wrote: >>> The parameters for a fixed-size array type determine the type's >>> size/stride,

Re: [swift-evolution] [Idea] Custom keywords for operators.

> On Jul 31, 2017, at 3:59 PM, Taylor Swift via swift-evolution > wrote: > > I’m gonna come out and say I’m not a fan of this at all. I’m already pretty > suspicious of operator overloading, and I think supporting this would make > Swift code much more difficult to read. Also, while for some

Re: [swift-evolution] Extensions

> On Jul 31, 2017, at 4:19 PM, Omar Charif via swift-evolution > wrote: > > I am a big fan of extensions, but I wonder what would happen years from now > when we start to have lots of extensions created for the primitive classes. > The problem is that we can write a String extension for examp

Re: [swift-evolution] [Pitch] #dup -- a duplication "macro"(?)

> On Jul 31, 2017, at 7:23 PM, Daryle Walker via swift-evolution > wrote: > > When coming up with new array interfaces, I had some array to/from tuple > conversion functions: > > func array(from: (T, …U)) -> [1 + #countOf(U) ; T] allwhere U == T > > The problem is going the other way: > > f

Re: [swift-evolution] [Pitch] New Version of Array Proposal

> On Aug 1, 2017, at 10:54 AM, Daryle Walker via swift-evolution > wrote: > > A tuple can have its members initialized in piecemeal and still satisfy > deterministic initialization. The named types need to do all their > sub-objects' initializations before any designated initializer ends. I w

Re: [swift-evolution] TrigonometricFloatingPoint/MathFloatingPoint protocol?

Sent from my iPad > On Aug 2, 2017, at 3:43 PM, Xiaodi Wu via swift-evolution > wrote: > > >> On Wed, Aug 2, 2017 at 17:37 Nicolas Fezans wrote: >> I think that the items mentioned earlier in the list (just reminded below) >> should not all be treated equally. >> >> - RNG and cryptography

Re: [swift-evolution] TrigonometricFloatingPoint/MathFloatingPoint protocol?

> On Aug 2, 2017, at 4:29 PM, Xiaodi Wu wrote: > >> On Wed, Aug 2, 2017 at 6:17 PM, David Sweeris wrote: >> >> >> >> Sent from my iPad >> On Aug 2, 2017, at 3:43 PM, Xiaodi Wu via swift-evolution >> wrote: >> >>> On Wed, Aug 2, 2017 at 17:37 Nicolas Fezans wrote: I think

Re: [swift-evolution] TrigonometricFloatingPoint/MathFloatingPoint protocol?

> On Aug 2, 2017, at 4:29 PM, Nicolas Fezans wrote: > > Your notation is indeed correct, even though using x on both side might > confuse some people, this is correct. But no I would not go that far, I would, just not right now. There are more important issues to the larger community that nee

Re: [swift-evolution] [Pitch] #dup -- a duplication "macro"(?)

> On Aug 2, 2017, at 21:39, Daryle Walker wrote: > >>> On Aug 1, 2017, at 9:56 AM, Daryle Walker wrote: >>> On Jul 31, 2017, at 10:38 PM, David Sweeris wrote: On Jul 31, 2017, at 7:23 PM, Daryle Walker via swift-evolution wrote: The tuple will be a bunch of “

Re: [swift-evolution] [Pitch] New Version of Array Proposal

> On Aug 2, 2017, at 21:45, Daryle Walker via swift-evolution > wrote: > > I’m not good at explicit explanations, so having to justify adding a type > that’s been around for a long time (at least FORTRAN 4+ decades ago) an > almost every systems programming language has is frustrating. I thou

Re: [swift-evolution] [Pitch] Improving unspecified generic usability

> On Aug 7, 2017, at 3:00 PM, Logan Shire via swift-evolution > wrote: > > One of my longstanding frustrations with generic types and protocols has been > how hard it is to work with them when their type is unspecified. > Often I find myself wishing that I could write a function that takes a

Re: [swift-evolution] [Pitch] Improving unspecified generic usability

> On Aug 8, 2017, at 06:38, Karl Wagner wrote: > > >>> On 8. Aug 2017, at 04:35, David Sweeris via swift-evolution >>> wrote: >>> >>> >>> On Aug 7, 2017, at 3:00 PM, Logan Shire via swift-evolution >>> wrote: >>>

Re: [swift-evolution] Enums and Source Compatibility

(Now with more mailing lists in the "to" field!) > On Aug 8, 2017, at 3:27 PM, Jordan Rose via swift-evolution > wrote: > > Hi, everyone. Now that Swift 5 is starting up, I'd like to circle back to an > issue that's been around for a while: the source compatibility of enums. > Today, it's an e

Re: [swift-evolution] Enums and Source Compatibility

> On Aug 9, 2017, at 11:04, Matthew Johnson wrote: > >> On Aug 9, 2017, at 12:15 PM, Tony Allevato via swift-evolution >> wrote: >> >>> On Wed, Aug 9, 2017 at 9:40 AM David Sweeris via swift-evolution >>> wrote: >>> (Now with more mailing

Re: [swift-evolution] Swift source mentorship program

> On Aug 16, 2017, at 3:18 PM, Chris Lattner via swift-evolution > wrote: > > If you have questions about contributing or get stuck, then head over the the > swift-dev mailing list. That’s the best place to connect with others working > on hacking on Swift itself. Is that mailing list an ap

Re: [swift-evolution] pure functions

> On Aug 18, 2017, at 12:11, Chris Lattner via swift-evolution > wrote: > > Splitting this out from the concurrency thread: > >> >>> On Aug 18, 2017, at 6:12 AM, Matthew Johnson wrote: On Aug 17, 2017, at 11:53 PM, Chris Lattner wrote: In the manifesto you talk about restric

Re: [swift-evolution] Beyond Typewriter-Styled Code in Swift, Adoption of Symbols

On Aug 28, 2017, at 7:57 PM, John Pratt via swift-evolution mailto:swift-evolution@swift.org>> wrote: > I sent a postal envelope to the Swift team with an article I wrote, arguing > that > symbols and graphics would push the programming language forward. > > Wouldn’t it be nice to have an actu

Re: [swift-evolution] Beyond Typewriter-Styled Code in Swift, Adoption of Symbols

> On Aug 30, 2017, at 8:21 AM, John Pratt via swift-evolution > wrote: > > I agree with what you said and I wonder myself if it is possible at this > time for Swift to do what I mentioned in that article, given the current > roadmap. > > Everyone would have to rewrite the agenda of Swift 5 to

Re: [swift-evolution] Beyond Typewriter-Styled Code in Swift, Adoption of Symbols

> On Aug 31, 2017, at 2:51 PM, Dave DeLong via swift-evolution > wrote: > > Just a side observation… > > One of the downsides I would put forward to notation like this is it > massively increases the barrier to entry for anyone else. I look at that > “Reduction.agda” file and wonder if I nee

Re: [swift-evolution] Beyond Typewriter-Styled Code in Swift, Adoption of Symbols

> On Aug 31, 2017, at 3:17 PM, Dave DeLong wrote: > >> >> On Aug 31, 2017, at 3:58 PM, David Sweeris > > wrote: >> >> >>> On Aug 31, 2017, at 2:51 PM, Dave DeLong via swift-evolution >>> mailto:swift-evolution@swift.org>> wrote: >>> >>> Just a side observation… >

  1   2   3   4   5   6   >