Re: [swift-evolution] [Pitch] Percentage Type

Sent from my iPhone > On Jan 16, 2018, at 23:45, Jonathan Hull via swift-evolution > wrote: > > Mainly semantics. > > We could technically use Int instead of having a Bool type (just using 1 and > 0). We don’t do that since Int and Bool have intrinsically

Re: [swift-evolution] [pitch] adding toggle to Bool

> On Jan 11, 2018, at 22:15, Chris Eidhof via swift-evolution > wrote: > > Hey SE! > > When we have a bunch of nested structs: > > struct Sample { > var bar: Bar > } > > struct Bar { > var show: Bool > } > > var foo =

Re: [swift-evolution] Proposal: Introduce User-defined "Dynamic Member Lookup" Types

Sent from my iPhone > On Nov 30, 2017, at 00:24, Douglas Gregor via swift-evolution > wrote: > > > >> On Nov 26, 2017, at 10:04 PM, Chris Lattner via swift-evolution >> wrote: >> >> I’d like to formally propose the inclusion of

Re: [swift-evolution] Synthesizing Equatable, Hashable, and Comparable for tuple types

> On Nov 25, 2017, at 08:05, Xiaodi Wu via swift-evolution > wrote: > > >> On Sat, Nov 25, 2017 at 06:35 Mike Kluev wrote: >>> On 25 November 2017 at 03:12, Xiaodi Wu wrote: >> On Fri, Nov 24, 2017 at 9:08 PM, Mike

Re: [swift-evolution] Synthesizing Equatable, Hashable, and Comparable for tuple types

> On Nov 21, 2017, at 22:54, Douglas Gregor via swift-evolution > wrote: > >> On Nov 21, 2017, at 10:48 PM, David Hart wrote: >> >> >> >> On 22 Nov 2017, at 07:41, Douglas Gregor via swift-evolution >> wrote: >>

Re: [swift-evolution] Large Proposal: Non-Standard Libraries

> On Nov 7, 2017, at 1:58 PM, Ted Kremenek via swift-evolution > wrote: > > Hi Dave, > > Thanks for bringing up this topic. This has been kicked around a little, and > we’re still exploring different models on how to extend Swift. > > The server APIs work group

Re: [swift-evolution] “Integer” protocol?

> On Nov 1, 2017, at 14:54, Kelvin Ma via swift-evolution > wrote: > > > >> On Wed, Nov 1, 2017 at 12:15 PM, Xiaodi Wu via swift-evolution >> wrote: >>> On Wed, Nov 1, 2017 at 07:24 Daryle Walker wrote: >> >>> >>>

Re: [swift-evolution] Making capturing semantics of local functions explicit

> On Oct 25, 2017, at 4:41 AM, David Hart via swift-evolution > wrote: > > I got bit again by a sneaky memory leak concerning local functions and would > like to discuss a small language change. I vaguely remember this being > discussed in the past, but can’t find

Re: [swift-evolution] [draft] Target environment platform condition

One quick question... WRT `os()`, should that take a string instead of some keywordish thing? There's at least one OS which has a Swift port, but doesn't show up on that list (Haiku: https://www.haiku-os.org/blog/return0e/2017-08-28_gsoc_2017_porting_swift_to_haiku_-_final_report/

Re: [swift-evolution] /*Let it be*/ func() -> @discardable Bool {} /*Rather Than*/ @discardableResult func() -> Bool {}

> On Oct 20, 2017, at 22:18, Eagle Offshore <eagleoffsh...@mac.com> wrote: > > >> On Oct 20, 2017, at 2:55 PM, David Sweeris via swift-evolution >> <swift-evolution@swift.org> wrote: >> >> how else are we supposed to express nuances when the

Re: [swift-evolution] /*Let it be*/ func() -> @discardable Bool {} /*Rather Than*/ @discardableResult func() -> Bool {}

> On Oct 20, 2017, at 10:54, Eagle Offshore via swift-evolution > wrote: > > +1 > > I really feel like the number of modifiers and decorators and annotations > etchas reached the point of illegibility. > > It purpose="intensifier">reallyridiculous > > That's

Re: [swift-evolution] [Draft] Rename Sequence.elementsEqual

Oh, this is weird... I replied to a different thread an hour ago. Somehow that message hasn't posted yet, but this one from three days ago apparently got reposted? Weird. > On Oct 19, 2017, at 12:11 PM, David Sweeris via swift-evolution > <swift-evolution@swift.org> wrote: >

Re: [swift-evolution] [Draft] Rename Sequence.elementsEqual

> On Oct 16, 2017, at 10:42, BJ Homer via swift-evolution > wrote: > >>> On Oct 16, 2017, at 8:20 AM, Thorsten Seitz via swift-evolution >>> wrote: >>> >>> Am 16.10.2017 um 07:19 schrieb Xiaodi Wu : >> >>> What

Re: [swift-evolution] [Draft] Rename Sequence.elementsEqual

> On Oct 18, 2017, at 1:04 PM, Adam Kemp via swift-evolution > wrote: > > >> On Oct 18, 2017, at 12:25 PM, Thorsten Seitz via swift-evolution >> wrote: >> >> Therefore having `elementsEqual` as API for unordered collections is a >>

Re: [swift-evolution] [Draft] Rename Sequence.elementsEqual

> On Oct 17, 2017, at 9:34 AM, Xiaodi Wu via swift-evolution > wrote: > > > On Tue, Oct 17, 2017 at 09:42 Jonathan Hull > wrote: >> On Oct 17, 2017, at 5:44 AM, Xiaodi Wu >

Re: [swift-evolution] [Draft] Rename Sequence.elementsEqual

.com > <mailto:milse...@apple.com>> wrote: > >> >> >>> On Oct 16, 2017, at 8:46 AM, David Sweeris via swift-evolution >>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >>> >>> >>> On O

Re: [swift-evolution] [Draft] Rename Sequence.elementsEqual

> On Oct 16, 2017, at 10:42, BJ Homer via swift-evolution > wrote: > >>> On Oct 16, 2017, at 8:20 AM, Thorsten Seitz via swift-evolution >>> wrote: >>> >>> Am 16.10.2017 um 07:19 schrieb Xiaodi Wu : >> >>> What

Re: [swift-evolution] [Draft] Rename Sequence.elementsEqual

> On Oct 16, 2017, at 09:21, Michael Ilseman <milse...@apple.com> wrote: > > > >> On Oct 16, 2017, at 8:46 AM, David Sweeris via swift-evolution >> <swift-evolution@swift.org> wrote: >> >> >> On Oct 16, 2017, at 07:20, Xiaodi Wu via

Re: [swift-evolution] [Draft] Rename Sequence.elementsEqual

> On Oct 16, 2017, at 07:20, Xiaodi Wu via swift-evolution > wrote: > > >> On Mon, Oct 16, 2017 at 05:48 Jonathan Hull wrote: >> >>> On Oct 15, 2017, at 9:58 PM, Xiaodi Wu wrote: >>> On Sun, Oct 15, 2017 at 8:51 PM,

Re: [swift-evolution] /*Let it be*/ func() -> @discardable Bool {} /*Rather Than*/ @discardableResult func() -> Bool {}

> On Oct 9, 2017, at 9:02 AM, Dave DeLong via swift-evolution > wrote: > > Oooo, I really like this. > > It also brings up an interesting point on the whole async discussion. Doesn’t > the async apply to the return value and not the other stuff? No, the whole

Re: [swift-evolution] A path forward on rationalizing unicode identifiers and operators

Oct 2, 2017, at 10:06 PM, Chris Lattner <clatt...@nondot.org >>> <mailto:clatt...@nondot.org>> wrote: >>> >>> On Oct 2, 2017, at 9:12 PM, David Sweeris via swift-evolution >>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

Re: [swift-evolution] A path forward on rationalizing unicode identifiers and operators

> On Oct 2, 2017, at 10:06 PM, Chris Lattner <clatt...@nondot.org> wrote: > > On Oct 2, 2017, at 9:12 PM, David Sweeris via swift-evolution > <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >>> Keep in mind that Swift alr

Re: [swift-evolution] A path forward on rationalizing unicode identifiers and operators

> On Oct 2, 2017, at 7:57 PM, Xiaodi Wu wrote: > > On Mon, Oct 2, 2017 at 9:04 PM, David Sweeris > wrote: > > On Oct 2, 2017, at 5:45 PM, Xiaodi Wu via swift-evolution >

Re: [swift-evolution] Fix "private extension" (was "Public Access Modifier Respected in Type Definition")

> On Oct 2, 2017, at 6:52 PM, Tony Allevato via swift-evolution > wrote: > > Thanks for hoisting this out into its own thread, Jordan. I was hesitant to > elaborate more on another access level thread :) > > I think the change should absolutely be made. Even though

Re: [swift-evolution] A path forward on rationalizing unicode identifiers and operators

> On Oct 2, 2017, at 5:45 PM, Xiaodi Wu via swift-evolution > wrote: > >> On Mon, Oct 2, 2017 at 19:28 Ethan Tira-Thompson via swift-evolution >> wrote: >> I’m all for fixing pressing issues requested by Xiaodi, but beyond that I >>

Re: [swift-evolution] A path forward on rationalizing unicode identifiers and operators

; What is your use case for this? >>> >>>> On Mon, Oct 2, 2017 at 10:56 David Sweeris via swift-evolution >>>> <swift-evolution@swift.org> wrote: >>>> >>>>> On Oct 1, 2017, at 22:01, Chris Lattner via swift-evolution >>

Re: [swift-evolution] A path forward on rationalizing unicode identifiers and operators

On Oct 2, 2017, at 09:14, Xiaodi Wu <xiaodi...@gmail.com <mailto:xiaodi...@gmail.com>> wrote: > What is your use case for this? > > On Mon, Oct 2, 2017 at 10:56 David Sweeris via swift-evolution > <swift-evolution@swift.org <mailto:swift-evolution@swift.org>&g

Re: [swift-evolution] A path forward on rationalizing unicode identifiers and operators

> On Oct 1, 2017, at 22:01, Chris Lattner via swift-evolution > wrote: > > >> On Oct 1, 2017, at 9:26 PM, Kenny Leung via swift-evolution >> wrote: >> >> Hi All. >> >> I’d like to help as well. I have fun with operators. >> >> There

Re: [swift-evolution] A path forward on rationalizing unicode identifiers and operators

> On Sep 30, 2017, at 16:13, Xiaodi Wu via swift-evolution > wrote: > > I’m happy to participate in the reshaping of the proposal. It would be nice > to gather a group of people again to help drive it forward. > > That said, it’s unclear to me that superscript T is

Re: [swift-evolution] Enums and Source Compatibility

> On Sep 28, 2017, at 4:15 PM, Goffredo Marocchi via swift-evolution > wrote: > > Agreed, I am not seeing this change doing so much good because maybe it could > prevent issues Library writers or developers updating libraries without > checking things... not trying

Re: [swift-evolution] Enums and Source Compatibility

> On Sep 20, 2017, at 4:15 PM, Dave DeLong via swift-evolution > wrote: > > Hi Jordan, > > One thing I’m still not clear on exhaustive vs non-exhaustive… > > What will stop a developer from releasing an exhaustive enum in version 1 of > their library, and then

Re: [swift-evolution] [Proposal] Explicit Synthetic Behaviour

> On Sep 12, 2017, at 8:07 PM, Tony Allevato via swift-evolution > wrote: > > But all that stuff about custom attributes and metaprogramming introspection > is a big topic of it's own that isn't going to be solved in Swift 5, so this > is a bit of a digression. :)

Re: [swift-evolution] pure functions

> On Sep 9, 2017, at 10:48 AM, Dave Abrahams via swift-evolution > wrote: > > on Wed Aug 23 2017, Joe Groff wrote: On Aug 18, 2017, at 12:10 PM, Chris Lattner via swift-evolution wrote: Splitting

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

> On Aug 31, 2017, at 4:54 PM, Dave DeLong wrote: > >> >> On Aug 31, 2017, at 5:45 PM, David Sweeris > > wrote: >> >>> >>> On Aug 31, 2017, at 3:17 PM, Dave DeLong >> > wrote:

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

> On Aug 31, 2017, at 6:27 PM, John McCall via swift-evolution > wrote: > > I would argue that there is a much broader philosophical truth here. > Programming is not, and never can be, a pure exercise in mathematics, and the > concepts necessary for understanding

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

> On Aug 31, 2017, at 4:54 PM, Brent Royal-Gordon via swift-evolution > wrote: > > (Also, I really doubt changing concatenation to `++` is going to fly. Swift > is not Haskell.) Of course not... the concatenation operator should be `|` 

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 >>>

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 >

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

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 > 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. > >

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

Re: [swift-evolution] Enums and Source Compatibility

> On Aug 9, 2017, at 11:04, Matthew Johnson <matt...@anandabits.com> wrote: > >> On Aug 9, 2017, at 12:15 PM, Tony Allevato via swift-evolution >> <swift-evolution@swift.org> wrote: >> >>> On Wed, Aug 9, 2017 at 9:40 AM David Sweeris via swift-evo

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

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

> On Aug 8, 2017, at 06:38, Karl Wagner <razie...@gmail.com> wrote: > > >>> On 8. Aug 2017, at 04:35, David Sweeris via swift-evolution >>> <swift-evolution@swift.org> wrote: >>> >>> >>> On Aug 7, 2017, at 3:00 PM, Loga

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

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

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

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

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: >> >>>

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

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

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

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

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

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

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:

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

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

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(()) >

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

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

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

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

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

> On Jul 23, 2017, at 2:49 PM, David Sweeris via swift-evolution > <swift-evolution@swift.org> wrote: > > > On Jul 23, 2017, at 12:18, Taylor Swift <kelvin1...@gmail.com > <mailto:kelvin1...@gmail.com>> wrote: > >> Speaking of which, IIRC, at on

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

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

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

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

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

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

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

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

gt; > 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 >> <swift-evolution@swift.org> wrote: >> >> > On Jun 23, 2017, at 5:28 PM, David Moore via swift-evol

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

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

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

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] 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?

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

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 >> > wrote: >> >>> On Jun 12, 2017, at 12:47 PM, Paul Cantrell

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"

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 >>>

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 >> > wrote: >> On Mon, Jun 12, 2017 at 9:31 PM, Paul

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

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 > > wrote: > > With the ability to specify throwaway variables

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

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

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 >>

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

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. 

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

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

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

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

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

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

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

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:

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

om >> <mailto:xiaodi...@gmail.com>> wrote: >> >> On Wed, May 24, 2017 at 3:32 PM, David Sweeris via swift-evolution >> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >> So, I’m working on a type, and would like to make it conform t

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

> On May 24, 2017, at 5:11 PM, Xiaodi Wu <xiaodi...@gmail.com> wrote: > > On Wed, May 24, 2017 at 3:32 PM, David Sweeris via swift-evolution > <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: > So, I’m working on a type,

[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...) { … }

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.

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: > > >

  1   2   3   4   5   >