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

"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 messages. Don't feed him. Gwendal > Le 12 juin 2017 à 23:10, Jérémie Girault via

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

On Mon, Jun 12, 2017 at 9:31 PM, Paul Cantrell via swift-evolution < swift-evolution@swift.org> wrote: > I support everything Jon wrote. > > +1 Free-for-all brainstorming venue separate from focused proposal > discussion. > +1, particularly for this being a section in Discourse ;-)

Re: [swift-evolution] Revisiting SE-0110

What’s the status of this Chris’s double parens idea below? It garnered some positive responses, but the discussion seems to have fizzled out. Is there something needed to help nudge this along? What’s the likelihood of getting this fixed before Swift 4 goes live, and the great wave of

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

> On Jun 12, 2017, at 7:12 PM, Ted Kremenek wrote: > > >> On Jun 12, 2017, at 12:47 PM, Paul Cantrell wrote: >> >> >>> On Jun 12, 2017, at 1:29 AM, Ted Kremenek via swift-evolution >>> wrote: >>> On Jun 11, 2017, at

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

I support everything Jon wrote. +1 Free-for-all brainstorming venue separate from focused proposal discussion. +1 Working groups when helpful. +1 Longer public incubation for unstable / experimental features (but that idea executed & communicated with caution, preferably with active support

Re: [swift-evolution] Reproducible builds (same code -> always same binary)

> On 12. Jun 2017, at 21:56, Tuur Anton via swift-evolution > wrote: > > > adrian kashivskyy wrote: > > > open-source projects and that most of them are compiled by users > > > Maybe that's true, but there are apps where most of users just download the > binary.

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

> On Jun 12, 2017, at 5:12 PM, Ted Kremenek via swift-evolution > wrote: > > - Sometimes (often?) refinements aren’t part of a grand design. They evolve > in the mind space from usage of Swift. In other words, greedy optimization > is sometimes just a natural way

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] Introducing synthesized locks

> On 12. Jun 2017, at 11:10, Erik Aigner via swift-evolution > wrote: > > In my day to day tasks, synchronization primitives are used quite often. ObjC > had the @synchronized attribute for methods. I didn’t find anything about > this in swift evolution, so I

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

> On Jun 12, 2017, at 6:42 PM, Vladimir.S wrote: > > John, could you clarify the details regarding function types, SE-0066 and > SE-0110 implementations *planned* for Swift 4 release? I believe all these > are important questions to be answered to understand the near feature

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

On Sun, Jun 11, 2017 at 1:52 AM, Haravikk via swift-evolution < swift-evolution@swift.org> wrote: > > With the ability to specify throwaway variables more easily, I'm sticking > with my using syntax here: > > var theNames:[String] = [] > while let eachItem = theIterator.next() using (var theTotal

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

> On Jun 12, 2017, at 12:47 PM, Paul Cantrell wrote: > > >> On Jun 12, 2017, at 1:29 AM, Ted Kremenek via swift-evolution >> wrote: >> >>> On Jun 11, 2017, at 4:47 PM, Erica Sadun via swift-evolution >>> wrote: >>>

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

This: https://twitter.com/slava_pestov/status/874394132340289536 seems to suggest that the current Swift 4 behavior will not change much in this domain. On Tue, Jun 13, 2017 at 1:11 AM, Vladimir.S wrote: > On 12.06.2017 23:17, Jens Persson via swift-evolution wrote: > >> I

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

On 12.06.2017 23:17, Jens Persson via swift-evolution wrote: I think this proposal would be complicating rather than simplifying the type system, it would be adding a special rule. And it is not a step towards resolving the many parentheses-related inconsistencies that still remain. Here is

Re: [swift-evolution] Int indexing into UTF16View

> On Jun 10, 2017, at 19:01, Charles Srstka via swift-evolution > wrote: > >> On Jun 8, 2017, at 2:35 PM, Tony Allevato via swift-evolution >> wrote: >> >> It is an extremely rare case for a developer to know a priori what literal >>

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

On Mon, Jun 12, 2017 at 5:38 PM, Xiaodi Wu wrote: > On Mon, Jun 12, 2017 at 5:25 PM, Jérémie Girault < > jeremie.gira...@gmail.com> wrote: > >> >> >> — >> very short reply expected - vsre.info >> Jérémie Girault >> >> On 12 juin 2017 at 23:56:37, Xiaodi Wu

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

John, could you clarify the details regarding function types, SE-0066 and SE-0110 implementations *planned* for Swift 4 release? I believe all these are important questions to be answered to understand the near feature of Swift and to be prepared for changes. Given : func fooParam(_ x: Int,

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

On Mon, Jun 12, 2017 at 5:25 PM, Jérémie Girault wrote: > > > — > very short reply expected - vsre.info > Jérémie Girault > > On 12 juin 2017 at 23:56:37, Xiaodi Wu (xiaodi...@gmail.com) wrote: > > On Mon, Jun 12, 2017 at 4:47 PM, Jérémie Girault

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

— very short reply expected - vsre.info Jérémie Girault On 12 juin 2017 at 23:56:37, Xiaodi Wu (xiaodi...@gmail.com) wrote: On Mon, Jun 12, 2017 at 4:47 PM, Jérémie Girault wrote: > - Void as arguments is pretty common when using generics, that’s a core > point of

Re: [swift-evolution] Int indexing into UTF16View

> On Jun 11, 2017, at 10:25 PM, David Hart via swift-evolution > wrote: > > > On 11 Jun 2017, at 02:49, Ben Cohen > wrote: > >> >>> On Jun 8, 2017, at 10:32 AM, David Hart via swift-evolution >>>

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

— very short reply expected - vsre.info Jérémie Girault On 12 juin 2017 at 23:27:31, Xiaodi Wu (xiaodi...@gmail.com) wrote: On Mon, Jun 12, 2017 at 4:10 PM, Jérémie Girault wrote: > > — > very short reply expected - vsre.info > Jérémie Girault > > On 12 juin 2017 at

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

On Mon, Jun 12, 2017 at 4:47 PM, Jérémie Girault wrote: > - Void as arguments is pretty common when using generics, that’s a core > point of this proposal. An maybe that’s why we misunderstood ourselves > (around 0110 / 0066). This proposal addresses arguments. > -

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

On 12.06.2017 21:04, Xiaodi Wu via swift-evolution wrote: On Mon, Jun 12, 2017 at 12:44 Jérémie Girault > wrote: Void was the empty tuple because arguments were tuples. As John explained, that is _not_ correct. Void was not

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

On Mon, Jun 12, 2017 at 4:10 PM, Jérémie Girault wrote: > > — > very short reply expected - vsre.info > Jérémie Girault > > On 12 juin 2017 at 22:34:45, Xiaodi Wu (xiaodi...@gmail.com) wrote: > > On Mon, Jun 12, 2017 at 3:16 PM, Jérémie Girault

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

— very short reply expected - vsre.info Jérémie Girault On 12 juin 2017 at 22:34:45, Xiaodi Wu (xiaodi...@gmail.com) wrote: On Mon, Jun 12, 2017 at 3:16 PM, Jérémie Girault wrote: > I invite you to read the proposal rules again with a fresh mindset and > benevolence

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

> On Jun 12, 2017, at 3:03 PM, Austin Zheng wrote: > > > The Great Access Modifiers Wars and the recent fussing of SE-110 fallout > > are good examples of these problems. > > I want to mention that SE-0110 is part of a suite of proposals originally > asked for or

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

Oh, no need to apologize! I didn't want to distract from the main point of your post, which I think is very good. The fact is that SE-0110 introduced unforeseen consequences, and that we need to deal with them one way or another (including by reverting, if it comes to that). The problem in this

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

On Mon, Jun 12, 2017 at 3:16 PM, Jérémie Girault wrote: > I invite you to read the proposal rules again with a fresh mindset and > benevolence spirit. > It’s my first one and may not be very clear but the rules are > straightforward. > > Especially try to forget that

Re: [swift-evolution] [Pitch] #error

> On Jun 12, 2017, at 3:57 PM, Daryle Walker via swift-evolution > wrote: > > >> On Jun 12, 2017, at 8:03 AM, Ben Rimmington > > wrote: >> >> >>> On 11 Jun 2017, at 19:15, Beta wrote: >>> >>> A proposal and

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

Exactly, that means that your implementation of the tuple splatting operator is out of the type system. Can you expose it’s signature ? If you want the operator to be “compiler-magic” it’s possible. This proposal is an alternate solution. My point is that updating Void according to this proposal

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

As I said, the goal is to make propositions for rules which would solves inconsistencies, but it’s needed on multiple levels : - tuples of cardinality 0 - tuples of cardinality 1 - tuples of cardinality n > 1 This proposition effectively addresses the first one and not the others. The goal is

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

I invite you to read the proposal rules again with a fresh mindset and benevolence spirit. It’s my first one and may not be very clear but the rules are straightforward. Especially try to forget that Void is a tuple or anything. Void is Nothing in the programmer’s mind. An instance of Void

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

I think this proposal would be complicating rather than simplifying the type system, it would be adding a special rule. And it is not a step towards resolving the many parentheses-related inconsistencies that still remain. Here is an example of one such remaining inconsistency, it's still in

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

On Mon, Jun 12, 2017 at 3:04 PM, Jérémie Girault wrote: > Exactly, that means that your implementation of the tuple splatting > operator is out of the type system. > Can you expose it’s signature ? > > If you want the operator to be “compiler-magic” it’s possible. >

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

On Mon, Jun 12, 2017 at 2:56 PM, Jérémie Girault wrote: > @Xiaodi Wu > Disagree, and we would need the original designer here to help us, but my > understanding of the original meaning of tuples-as-arguments is that when I > define: > `func foo(_ arg0: Any, _ arg1:

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

> On Jun 12, 2017, at 1:29 AM, Ted Kremenek via swift-evolution > wrote: > >> On Jun 11, 2017, at 4:47 PM, Erica Sadun via swift-evolution >> wrote: >> >> I think having a queue to submit "proposals for eventually", written when >> the

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

Yes, I agree and I think the behavior of Swift 4 is more consistent than that of Swift 3(.2) here. On Mon, Jun 12, 2017 at 9:57 PM, Xiaodi Wu wrote: > On Mon, Jun 12, 2017 at 2:49 PM, Jens Persson wrote: > >> Just adding this here for reference: >> func

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

On Mon, Jun 12, 2017 at 2:49 PM, Jens Persson wrote: > Just adding this here for reference: > func foo(_: Void) {} > func bar() {} > // All these compile in Swift 3: > foo() > foo(()) > bar() > bar(()) > // But only these two compile in Swift 4: > foo(()) > bar() > So, `foo`

Re: [swift-evolution] [Pitch] #error

> On Jun 12, 2017, at 8:03 AM, Ben Rimmington wrote: > > >> On 11 Jun 2017, at 19:15, Beta wrote: >> >> A proposal and implementation of #warning exist. It has been judged out of >> scope for Swift 3 and Swift 4 phase 2. >> >>

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

@Xiaodi Wu Disagree, and we would need the original designer here to help us, but my understanding of the original meaning of tuples-as-arguments is that when I define: `func foo(_ arg0: Any, _ arg1: Any) {}` I can afterwards “apply” a tuple to a function named `foo` and therefore execute the

Re: [swift-evolution] Reproducible builds (same code -> always same binary)

> adrian kashivskyy wrote: > open-source projects and that most of them are compiled by users Maybe that's true, but there are apps where most of users just download the binary. A great example is Signal for iOS. There's no way to verify the binary comes from the supposed source code. So "open

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

On Mon, Jun 12, 2017 at 2:32 PM, Jérémie Girault wrote: > @xiaodi > I disagree on many points, for example what is the type of x when we type > `let x = *Void` ? > That would not be a legal statement. Exploding a tuple is an operation that only makes sense inside an

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

Ok, I understand, thanks! On Mon, Jun 12, 2017 at 9:29 PM, John McCall wrote: > On Jun 12, 2017, at 3:13 PM, Jens Persson wrote: > On Mon, Jun 12, 2017 at 8:52 PM, John McCall wrote: >> >> >> We really do want to tie most of these

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

@xiaodi I disagree on many points, for example what is the type of x when we type `let x = *Void` ? This is the essence of the problem and this proposition wants to solve this. The regression is due to both reason combined : typealias Void = () AND SE-0110 My proposition is to change the meaning

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

> On Jun 12, 2017, at 3:13 PM, Jens Persson wrote: > On Mon, Jun 12, 2017 at 8:52 PM, John McCall > wrote: > > We really do want to tie most of these features specifically to function > calls. > > > I'm not sure if I

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

On Mon, Jun 12, 2017 at 2:05 PM, David Hart wrote: > > On 12 Jun 2017, at 19:25, Xiaodi Wu via swift-evolution < > swift-evolution@swift.org> wrote: > > Unfortunately, I think this proposal appears to be mistaken as to this key > premise: Void was never (IIUC) meant to model

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

On Mon, Jun 12, 2017 at 8:52 PM, John McCall wrote: > > > We really do want to tie most of these features specifically to function > calls. > I'm not sure if I understand what you mean. Do you mean that you really don't want these features to require changes to the type

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

Just want to note that `Void` aka empty tuple is still constructible, so it doesn’t exactly mean “no value” but only “an occurrence without a substantial value”, especially when a stream of voids in FRP can be used as a trigger. To exactly represent “no value”, inhabitable types like `Never`

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

> On 12 Jun 2017, at 19:25, Xiaodi Wu via swift-evolution > wrote: > > Unfortunately, I think this proposal appears to be mistaken as to this key > premise: Void was never (IIUC) meant to model the absence of arguments; it is > a type with one possible value. > >

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

> On Jun 12, 2017, at 2:36 PM, Jens Persson via swift-evolution > wrote: > > > On Mon, Jun 12, 2017 at 7:13 PM, Michael Ilseman > wrote: > > * Unless you’re proposing a change to the semantics of the language that

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

It’s from type theory: https://en.wikipedia.org/wiki/Unit_type > On 12 Jun 2017, at 19:57, David Sweeris via swift-evolution > wrote: > > > On Jun 12, 2017, at 10:44, Jérémie Girault via swift-evolution >

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

On Mon, Jun 12, 2017 at 7:13 PM, Michael Ilseman wrote: > > > * Unless you’re proposing a change to the semantics of the language that > could affect e.g. name mangling or the type metadata hierarchy, then that > would be ABI-affecting. For example, proposing that all

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

Nothing, Unit, and other names have been frequently suggested in the past, but changing the name of Void was said to be out of scope even for Swift 3. On Mon, Jun 12, 2017 at 13:02 Robert Bennett via swift-evolution < swift-evolution@swift.org> wrote: > The name Unit is used in Foundation for

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

On Mon, Jun 12, 2017 at 12:44 Jérémie Girault wrote: > Void was the empty tuple because arguments were tuples. > As John explained, that is _not_ correct. Void was not motivated by anything to do with argument lists. So no arguments meant empty tuple. > > If we

Re: [swift-evolution] [Review] SE-0180: String Index Overhaul

> On Jun 9, 2017, at 9:24 PM, Dave Abrahams via swift-evolution > wrote: > on Fri Jun 09 2017, Kevin Ballard > wrote: >> On Tue, Jun 6, 2017, at 10:57 AM, Dave Abrahams via swift-evolution wrote: >> >>

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

The name Unit is used in Foundation for that exact meaning: https://developer.apple.com/documentation/foundation/unit . I like the name `Nothing` for the empty tuple. func foo(Nothing) {} > On Jun 12, 2017, at 1:57 PM, David Sweeris

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] [Proposal] Change Void meaning

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` Void, however, seem naturally fitted for the absence of argument. Should `func foo(Void)` be

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

Still I don’t understand your point about SE-0066, and maybe we are not talking about the same thing ? This new proposal basically tries to address that in Swift4 : `func foo() {}` is different from `func foo(Void) {}`, and cannot be coerced. That does not seem a natural thing from the developer

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

Unfortunately, I think this proposal appears to be mistaken as to this key premise: Void was never (IIUC) meant to model the absence of arguments; it is a type with one possible value. If I recall, a number of conversations have been raised about Void being a typealias of (), and the definitive

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

At the moment I’m only considering the zero-cardinality tuple and don’t want to address the implicit destructuring issues. Therefore you are right with foo(fnA) and foo(fnB); but foo(fnC) won’t compile. My goal is to add small propositions with simple rules to have better compatilibty and a more

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

> On Jun 12, 2017, at 4:48 AM, Jérémie Girault via swift-evolution > wrote: > > Hi here, > > As I tested swift4 in xcode9b1 I noticed a lot of regressions about tuples > usage. > > After documenting myself about the changes which happened, I thought that > they

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

> On Jun 9, 2017, at 4:34 PM, Jens Persson wrote: > > The analogy of the special first parameter label was relevant (for me) in > that it was a special rule that was invented to resolve a problem/situation > with no clear best solution. Probably most people agree now that

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

I have just had a quick look but I'm interested in what you think about the following example, which currently behaves like the comments say: func foo(_ fn: (A) -> Void) {} func fnA() {} func fnB(_ a: Int) {} func fnC(_ a: Int, _ b: Int) {} foo(fnA) // Compiles in Swift 3, error in Swift 4

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

Hi there, While I also feel it's kind of odd to have Void defined as the empty tuple with the latest changes like SE-0110, I also see issues with your proposal. For example, your change will cause ambiguity when calling generic functions and functions that contain all the arguments but the

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

Interesting use-case, Actually, after double-checking the rules I proposed, it seem to be possible, to do `let x: Void = foo()` but all “pseudo-instances” of Void would be stripped at compile time. Therefore this does not introduces source-breaking changes even if this use case is quite

Re: [swift-evolution] Introduction of OrderedSet

> On Jun 10, 2017, at 8:42 AM, Tony Parker wrote: > > This is still something I want to do, but I suspect it will require some > coordination work with the NSOrderedSet ref type in Foundation. > > Also, as Doug says, there is a larger question too of how we make

Re: [swift-evolution] Guard let

On 10.06.2017 7:07, Justin Oroz via swift-evolution wrote: First time trying to contribute, hopefully this is the proper channel to submit. I propose an addition to the guard let statement to allow for replacement of optionals with unwrapped values. ex) two current options

Re: [swift-evolution] Guard let

very recently gave some input on “Swift phases and mis-timed proposals”: https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170612/037340.html <https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170612/037340.html> Regards, David > On 10 Jun 2017, at 0

Re: [swift-evolution] [Proposal] Foundation Swift Encoders

> On Jun 12, 2017, at 8:32 AM, Ben Rimmington via swift-evolution > wrote: > > The new `JSONSerialization.WritingOptions.sortedKeys` option was mentioned at > WWDC. > > "What's New in Cocoa" [33:03 ... 33:33] >

[swift-evolution] Guard let

First time trying to contribute, hopefully this is the proper channel to submit. I propose an addition to the guard let statement to allow for replacement of optionals with unwrapped values. ex) two current options obj.methodWithCallback() {(foo, bar) in guard let foo = foo else {

[swift-evolution] Introducing synthesized locks

In my day to day tasks, synchronization primitives are used quite often. ObjC had the @synchronized attribute for methods. I didn’t find anything about this in swift evolution, so I thought i bring it up here. I think it would quite easily be possible to introduce a synchronized qualifier for

Re: [swift-evolution] Proposal: Always flatten the single element tuple

I think it’s interesting to discuss tuples, especially around 1-sized tuples. I also have an issue about 0-sized tuples and drafted a proposal here. https://github.com/jeremiegirault/swift-evolution/blob/master/proposals/-flatten-void.md I think by addressing empty, 1 and n-sized tuples

[swift-evolution] Pitch: Documentation access from the Swift REPL

I am new to Swift and just started learning but... When exploring standard library and the language it self from the REPL. Users currently need to switch between a browser to read documentation and the REPL it self. What I would like to see in the REPL is behaviour like this: 1> :help print

Re: [swift-evolution] [Proposal] Foundation Swift Encoders

The new `JSONSerialization.WritingOptions.sortedKeys` option was mentioned at WWDC. "What's New in Cocoa" [33:03 ... 33:33] When the

Re: [swift-evolution] Pitch: Allow @objc for all property declarations regardless of type

Self-correction: will/didChangeValue still do accept string key paths; it’s just that in that case they are not respelled and still use “forKey:” as their first argument label. Not sure why that didn’t come up in autocomplete when I was doing my tests the other day. I still think that making

Re: [swift-evolution] [Pitch] constexpr (i.e. compile-time constant expressions)

Daryle, there have been discussions of this idea here in the past, and some very good points have been brought up. Recently, there was also an attempt to resurrect discussion on pure functions, which are of course a very much related topic. Then, with the luxury of time, i was able to pull

Re: [swift-evolution] Reproducible builds (same code -> always same binary)

Hi, > Have you considered adding reproducible builds to Swift? If you compile the > same code under the same conditions, you always get the same binary. I don’t honestly know if „reproducible builds” are part of ABI stability, but if you are interested in that, you can find more information in

[swift-evolution] [Pitch] constexpr (i.e. compile-time constant expressions)

I’m not a language/library designer, just a wannabe designer; I’m hitting the limits of my expertise. So unless I lucked out, one of the main designers will have to pick up this ball and clean it up. I’ll be here if you need clarification on stuff. The seed of this idea was coming up with a

Re: [swift-evolution] [Pitch] #error

> On 11 Jun 2017, at 19:15, Beta wrote: > > A proposal and implementation of #warning exist. It has been judged out of > scope for Swift 3 and Swift 4 phase 2. > > https://github.com/apple/swift-evolution/pull/353 See also "[Pitch] #warning" in the mailing lists:

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

On 12.06.2017 11:48, Jérémie Girault via swift-evolution wrote: Hi here, As I tested swift4 in xcode9b1 I noticed a lot of regressions about tuples usage. After documenting myself about the changes which happened, I thought that they could be improved. Instead of fighting these propositions

[swift-evolution] Reproducible builds (same code -> always same binary)

Have you considered adding reproducible builds to Swift? If you compile the same code under the same conditions, you always get the same binary. This would be huge for open source source, because people could *prove* that an app binary came from the code it's supposed to be coming from. This

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

> The reason of this is that arguments were initially considered as tuple. If > this is no more the case, then it’s no more a reason to keep Void as an empty > tuple. Didn't have the time to look into the draft yet, but at first thought, your idea makes much sense to me — although my current

[swift-evolution] [Proposal] Change Void meaning

Hi here, As I tested swift4 in xcode9b1 I noticed a lot of regressions about tuples usage. After documenting myself about the changes which happened, I thought that they could be improved. Instead of fighting these propositions (which make sense), I wanted create a few proposal which would

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

> Changing how Objective-C initializers are imported sounds like a big and > dangerous task, but factory initializers behave exactly how Objective-C > initializers behave, compared to Swift initializers. Importing them all as > `fatory` init wouldn't change the behavior in any way, only mark

Re: [swift-evolution] Introduction of OrderedSet

Thanks for your replies. Something like an OrderedSet should always be in the standard library to serve the best possible performance and thats why I’m not in favor of a third party implementation. The biggest issue seems to be bridging. I really don’t want to „ignore“ bridging, because

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

> On Jun 11, 2017, at 4:47 PM, Erica Sadun via swift-evolution > wrote: > > I am sitting on a number of ideas that I think have merit (in a non-random > use-case non-C# way) and I have no idea when the right time will be to bring > them up. Several were marked as