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

[Gwendal Roué via swift-evolution]

"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 swift-evolution 
>  a écrit :
> 
> 
> —
> 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 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 shouldn’t even 
>> exist.
>> 
>> Sorry, that's not correct. Void is what's called Unit in other languages. It 
>> exists. That is why functions with "no return value" return Void. OTOH, 
>> Never does not exist. This discussion was had in great detail during the 
>> naming debate over Never.
> 
> Let’s put facts in front of correctness assertions. Is Void = Unit in C or 
> c++ ? can you create instances of void in java ? you have Void for generics. 
> https://en.wikipedia.org/wiki/Unit_type 
> 
> And if you look at assembly, sending void or returning void actually means 
> "nothing to push on the stack / nothing to pop”. Seems like having this 
> stripping on signatures at compile-time could be great !
> 
> Actually, in my opinion we could discuss naming when we agree that the 
> mechanism works, using this name is just a way to not impact the developer 
> with code changes.
> 
> So either we agree on the fact that the mechanism works and we can move on to 
> naming, or we get back on the topic : do you see a flaw in the proposal rules 
> ? It elegantly transforms signature arity and provides the programmer a 
> natural syntax to express it’s code.
> 
>> 
>>  
>> The proposed meaning of Void is to be a “lack” of arguments. It means that 
>> each “Void” argument reduces the arity of the function by one, at its exact 
>> position. Especially look at the canonical signature definition, and the 
>> proposed rules of reduction.
>> 
>> I don't understand why you propose to name this new idea "Void". You're 
>> proposing something that's not even a lack of an argument, but an 
>> anti-argument, like anti-matter! I'm not sure I understand why this is 
>> necessary. It seems to be a very strange workaround for one specific issue 
>> arising from disallowing implicit tuple splatting.
> 
> 
> Look at other languages, when you put Void in functions in C or java, do you 
> need to add a value ? Ease of use is important. 
> 
> You imply that I disagree with splatting were I don’t, let’s not make it 
> personal. This proposal is even compatible with tuple splatting !
> 
> The proposal rules seem to work and provides great user value. Let’s try to 
> consider this !
> 
>> 
>>  
>> That proposal, if implemented, would effectively allow `Callback` to 
>> be called without arguments in the context of swift4.
>> 
>> —
>> very short reply expected - vsre.info 
>> Jérémie Girault
>> 
>> On 12 juin 2017 at 22:06:54, Xiaodi Wu (xiaodi...@gmail.com 
>> ) wrote:
>> 
>>> 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: Any) {}`
>>> I can afterwards “apply” a tuple to a function named `foo` and therefore 
>>> execute the function on this tuple.
>>> Calling a function syntax was equivalent to put a tuple next to a function 
>>> name:
>>> `foo(42, “hello")` the left-hand is `foo`, the right-hand is `(42, 
>>> “hello")` is the tuple.
>>> 
>>> The same way if I have
>>> `func foo()`
>>> `foo()` means calling `foo` with argument `()` and there we have our 
>>> original `Void`
>>> 
>>> That meaning changed recently due to multiple SE implementations actually.
>>> 
>>> Tuples-as-arguments never shipped in any version of Swift, and the ability 
>>> to "apply" a tuple like that was removed by SE-0029--the original goal was 
>>> to implement this change in time for Swift 2.2.
>>>  
>>> The parenthesis around the call don't have a tuple meaning anymore. 
>>> Therefore it breaks a lot of code relying on this feature of the language, 
>>> which was quite elegant, but could not handle advanced functions features.
>>> 
>>> Yes, this is an intentional and approved part of SE-0029. The drawbacks 
>>> were 

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

[Jacob Bandes-Storch via swift-evolution]

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 ;-)
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Revisiting SE-0110

[Paul Cantrell via swift-evolution]

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 readability regressions hits?

P

> On Jun 4, 2017, at 12:16 PM, Chris Lattner via swift-evolution 
>  wrote:
> 
> 
>> On Jun 1, 2017, at 3:06 PM, John McCall via swift-evolution 
>> > wrote:
>> 
>> 
>>> On Jun 1, 2017, at 2:39 PM, Pavol Vaskovic >> > wrote:
>>> 
>>> On Thu, Jun 1, 2017 at 8:52 PM, John McCall via swift-evolution 
>>> > wrote:
>>> 
>>> I understand that there are developers who dislike SE-0110's impact on 
>>> certain kinds of functional programming, but that is a very broad complaint 
>>> that is unlikely to reach consensus or acceptance, especially for Swift 4. 
>>> 
>>> The impact of SE-0110 as currently implemented in Swift 4 leads to 
>>> following migration choice wherever you have a closure that takes tuple 
>>> argument:
>>> * concise but obfuscate code ($0.1, ...)
>>> * readable but verbose code (requiring a ton of boilerplate: intermediate 
>>> argument, expand signature to include return type, desctructure tuple on 
>>> new line using let, add return clause)
>>> 
>>> Maybe I misunderstood you, but I don't think this is marginal issue 
>>> affecting only some "developers that dislike the impact on certain kinds of 
>>> functional programming". 
>> 
>> You're misunderstanding me.  I have explicitly said, several times, that I 
>> agree that the impact on tuple destructuring in closures is a serious 
>> regression.  There have *also* been objections to losing argument-splat 
>> behavior, and while that does negatively affect some functional styles, I 
>> think it would be a mistake to try to address that now.
> 
> I agree with both points: we need to fix the type checker 
> semantics+performance regression, but I also sympathize with the beauty 
> regression for closures.  Here are some the examples Gwendal Roué cited 
> up-thread (just to make the discussion concrete):
> 
> Example 1
> -return columns.index { (column, _) in column.lowercased() == 
> lowercaseName }
> +return columns.index { $0.0.lowercased() == lowercaseName }
> 
> Example 2 :
> -.map { (mappedColumn, baseColumn) -> (Int, String) in
> +.map { (pair) -> (Int, String) in
> +let mappedColumn = pair.key
> +let baseColumn = pair.value
> 
> Example 3 :
> -.map { (table, columns) in 
> "\(table)(\(columns.sorted().joined(separator: ", ")))" } 
> +.map { "\($0.key)(\($0.value.sorted().joined(separator: ", 
> ")))" }
> 
> Example 4 :
> -dictionary.first { (column, value) in column.lowercased() == 
> orderedColumn.lowercased() }
> +dictionary.first { $0.key.lowercased() == 
> orderedColumn.lowercased() }
> 
> 
> 
> 
> One way to split the difference here is to eliminate the splatting behavior, 
> but keep the destructuring (irrefutable pattern matching) behavior as well.  
> In these cases, just require an extra explicit paren for the parameter list.  
> This would change the diff's to:
> 
> Example 1
> -return columns.index { (column, _) in column.lowercased() == 
> lowercaseName }
> +   return columns.index { ((column, _)) in column.lowercased() == 
> lowercaseName }
> 
> Example 2 :
> -.map { (mappedColumn, baseColumn) -> (Int, String) in
> +.map { ((mappedColumn, baseColumn)) -> (Int, String) in
> 
> Example 3 :
> -.map { (table, columns) in 
> "\(table)(\(columns.sorted().joined(separator: ", ")))" } 
> +.map { ((table, columns)) in 
> "\(table)(\(columns.sorted().joined(separator: ", ")))" }   
> 
> Example 4 :
> -dictionary.first { (column, value) in column.lowercased() == 
> orderedColumn.lowercased() }
> +dictionary.first { ((column, value)) in column.lowercased() 
> == orderedColumn.lowercased() }
> 
> 
> What do you think?  Seems like it would solve the type checker problem, 
> uglify the code a lot less, and make the fixit/migration happily trivial.
> 
> -Chris
> 
> 
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Paul Cantrell via swift-evolution]

> 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 4:47 PM, Erica Sadun via swift-evolution 
  wrote:
 
 I think having a queue to submit "proposals for eventually", written when 
 the inspiration is there, and having a core team review (say once a month 
 or even once a quarter) of their viability for future Swift directions 
 would be amazingly valuable.
>>> 
>>> This is a good point.  I think the concern about a queue is that ideas in 
>>> it may still be subject to starvation if the queue gets too long.  Ideas 
>>> also can atrophy in their relevance as the language evolves but proposals 
>>> stay in the queue.  It then becomes a delicate matter when closing out old 
>>> proposals. …
>>> 
>>> The point about understanding “viable for future Swift directions” is key 
>>> here.  Viability really comes down to trajectory for the language.  None of 
>>> us are fully omniscient about what is coming in future releases, but we do 
>>> have a sense of some of the priorities for the language that we need to 
>>> tackle, balanced with what **kind** of changes are still acceptable to take 
>>> into the language depending on the kind of disruption they cause for users, 
>>> the tools we have to mitigate any pain with those changes, etc.
>> 
>> This touches on two related concerns I’ve long had about how swift-evolution 
>> has worked so far.
>> 
>> Concern #1 is that we consider proposals in relative isolation, on their own 
>> merits. That’s understandable and wise. Without this focus, we’d never reach 
>> conclusions about anything. However, this does tilt the process toward 
>> greedy optimization as we traverse the language space. I worry that there’s 
>> not enough attention to the big picture.
> 
> I agree that some of the proposals have felt like steps of a hill-climbing 
> algorithm.
> 
> A few thoughts here:
> 
> - In contrast to the greedy optimization analogy, the series of manifestos in 
> the Swift 4 timeframe (ABI stability, String, Ownership) are intended to 
> provide an umbrella of design for what will turn out to be related but 
> separate SE proposals.  The idea of these manifestos is to chart a direction 
> for design and provide the basis for which the proposals related to the goals 
> of the manifesto will be evaluated.

Yes, the manifestos have been a positive and successful approach, and very 
helpful when present. I mentioned ABI stability, but the string & ownership 
manifestos also deserve their own huzzahs!

> - Many SE proposals have been about language refinements, which fall into a 
> category of topics that have been part of an ongoing design discussion for 
> Swift for years — including long before Swift was publicly announced.  While 
> the proposals may sometimes feel disjoint, their evaluation is not 
> necessarily so.  Often for me proposals relate (directly or indirectly) to 
> design discussions from previous versions of Swift (including pre-Swift 1) 
> that help provide broader optics when evaluating the merit of the proposals.  
> Sometimes when a proposal comes back for revision it incorporates those 
> optics.
> 
> - 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 discussion and design happens.  The question 
> in my mind is when these concerns come up should we throttle individual 
> proposals and take more time to take a broader view?  Maybe that’s the 
> answer.  Having been in discussions in the Core Team meetings I can say that 
> sometimes it is clear there is a broader topic to be discussed, and other 
> times it isn’t.

Perhaps the solution is not necessarily throttling proposals per se, but having 
some mechanism for routing a proposal to something other than either a review 
cycle or the freezer: “this needs manifesto-ing,” “this needs prototyping to 
measure impact on existing code,” “this needs to simmer and find its context 
before we work it into a proposal,” etc. (That’s related to Daryle’s original 
message.)

Jon’s idea of shunting some ideas to working groups seems like a good one.

> 
>> Concern #2 is that it’s hard to know what to do with a proposal when the 
>> ideal answer is “we need to see how it plays out in practice and then decide 
>> whether to accept it.” Theoretical discussion untempered by practical 
>> prototyping is a great way for a group to talk itself into a bad idea. (This 
>> will especially be a problem with future work to build out generics & 
>> existentials.)
> 
> I agree.  Do you have specific thoughts here on what could be done 
> differently?

I don’t have any brilliant ideas (or I’d have 

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

[Paul Cantrell via swift-evolution]

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 from the 
compiler for preventing careless dependance).

P

> On Jun 12, 2017, at 9:16 PM, Jonathan Hull  wrote:
> 
> 
>> 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 discussion and design happens.  The question 
>> in my mind is when these concerns come up should we throttle individual 
>> proposals and take more time to take a broader view?  Maybe that’s the 
>> answer.  Having been in discussions in the Core Team meetings I can say that 
>> sometimes it is clear there is a broader topic to be discussed, and other 
>> times it isn’t.
> 
> I would like to see an explicit place (maybe another list or a section of the 
> eventual discourse) where we can ideate.  Ideation requires a less critical 
> environment than this list has been able to provide, and I think it has been 
> contributing a great deal to our inability to deal with the larger picture.  
> The exception to this are the manifestos provided by the core team, which I 
> would guess are a result of off-list ideation sessions, followed by 
> concentrated refinement.
> 
> In the absence of an official place, it seems that there are a lot of ad-hoc 
> places where this is being done in a fragmented way.  The issue with this is 
> that, when I see “We had a long discussion on Slack”, I don’t know where this 
> Slack channel is, how to get an invite (or even if I am eligible for an 
> invite). Even if I have access to all of the places this discussion is 
> happening, it is so fractured that going back to find important bits of a 
> part of a conversation later is nearly impossible. 
> 
> I would also like to see a place where ideas and known issues can be 
> organized and referenced.
> 
> A structure that has worked well in member-driven organizations I have been a 
> part of in the past is that of working groups.  That is, we would larger 
> identify areas of interest for the future development of swift (e.g. 
> Strings), and then spawn a separate list or discourse section for deeper 
> discussion (anyone who is interested could join).  The group’s mandate would 
> be to work through the big picture surrounding that issue (including an 
> ideation stage) and develop a resulting manifesto.  That manifesto should be 
> an evolving document with known issues that need to be solved, and a record 
> of attempted solutions which failed and the reason for their failure.
> 
> I think this structure would take some pressure off of the core team and 
> allow deep thinking on important topics.  It would free the main list to 
> focus on specific proposals based on the guideposts provided by the 
> manifestos.  Discussions like the Great Access Modifier War would have been 
> contained to a working group, with the main list only receiving a 
> recommendation at the end.
> 
>>> Concern #2 is that it’s hard to know what to do with a proposal when the 
>>> ideal answer is “we need to see how it plays out in practice and then 
>>> decide whether to accept it.” Theoretical discussion untempered by 
>>> practical prototyping is a great way for a group to talk itself into a bad 
>>> idea. (This will especially be a problem with future work to build out 
>>> generics & existentials.)
>> 
>> I agree.  Do you have specific thoughts here on what could be done 
>> differently?
> 
> I think we can partially solve this by having an extra stage of “stability” 
> in our documentation.  Right now, things are either officially part of the 
> language or they aren’t (with a very short beta period between WWDC and the 
> Fall).  What I would like to see in the documentation is a notion of how sure 
> we are of a particular piece of API or syntax.
> 
> Unstable - This is actively under development/design and should be expected 
> to change. It is not safe to build frameworks on top of this.
> 
> Pre-Stable - We think we have a design which works, but we need to see how it 
> works in the larger ecosystem before guaranteeing stability.  Anything built 
> on this should be prepared for potentially large changes in the future, and 
> be marked “Pre-Stable” themselves.
> 
> Stable - This has been extensively tested in the actual swift ecosystem and 
> proven itself a useful addition.  Any changes to this in the future are 
> guaranteed to either be source-compatible or have a full depreciation cycle. 
> It is completely safe to build on.
> 
> I think being explicit about what we expect to 

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

[Karl Wagner via swift-evolution]

> 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. A great example is Signal for iOS. There's no way to verify the 
> binary comes from the supposed source code. So "open source" is providing all 
> these users with a false sense of security.
> 
> 
> Imagine if this was possible: (1) Download an "open source" app on your 
> iPhone from the App Store. (2) Connect your iPhone to your Mac and extract 
> the app binary to your Mac. (3) Compile the app's source code from GitHub. 
> (4) Compare the SHA-256 hashes of both binaries and verify they're the same.
> 
> 
> Wouldn't this be cool? I think so, because any user could ask a tech-savvy 
> friend to verify the binary. The app's reputation would go down the tubes if 
> the SHA-256 hashes would stop matching.
> 
> 
> From this perspective, I think bitcode, app thinning, etc. are taking us 
> backwards. I hope those never become mandatory. Developers should have the 
> option to make steps (1)-(4) possible.
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

App-thinning is not part of Swift (I don’t think we do anything special for 
bitcode, either - that happens at the LLVM level).

Anyway, those are just distribution technologies that Apple have chosen to 
implement for their AppStore. Whether or not they become requirements for 
submitting your App to the AppStore is up to Apple and their policy decisions. 
Again, nothing to do with the Swift language itself.

- Karl
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Jonathan Hull via swift-evolution]

> 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 discussion and design happens.  The question 
> in my mind is when these concerns come up should we throttle individual 
> proposals and take more time to take a broader view?  Maybe that’s the 
> answer.  Having been in discussions in the Core Team meetings I can say that 
> sometimes it is clear there is a broader topic to be discussed, and other 
> times it isn’t.

I would like to see an explicit place (maybe another list or a section of the 
eventual discourse) where we can ideate.  Ideation requires a less critical 
environment than this list has been able to provide, and I think it has been 
contributing a great deal to our inability to deal with the larger picture.  
The exception to this are the manifestos provided by the core team, which I 
would guess are a result of off-list ideation sessions, followed by 
concentrated refinement.

In the absence of an official place, it seems that there are a lot of ad-hoc 
places where this is being done in a fragmented way.  The issue with this is 
that, when I see “We had a long discussion on Slack”, I don’t know where this 
Slack channel is, how to get an invite (or even if I am eligible for an 
invite). Even if I have access to all of the places this discussion is 
happening, it is so fractured that going back to find important bits of a part 
of a conversation later is nearly impossible. 

I would also like to see a place where ideas and known issues can be organized 
and referenced.

A structure that has worked well in member-driven organizations I have been a 
part of in the past is that of working groups.  That is, we would larger 
identify areas of interest for the future development of swift (e.g. Strings), 
and then spawn a separate list or discourse section for deeper discussion 
(anyone who is interested could join).  The group’s mandate would be to work 
through the big picture surrounding that issue (including an ideation stage) 
and develop a resulting manifesto.  That manifesto should be an evolving 
document with known issues that need to be solved, and a record of attempted 
solutions which failed and the reason for their failure.

I think this structure would take some pressure off of the core team and allow 
deep thinking on important topics.  It would free the main list to focus on 
specific proposals based on the guideposts provided by the manifestos.  
Discussions like the Great Access Modifier War would have been contained to a 
working group, with the main list only receiving a recommendation at the end.

>> Concern #2 is that it’s hard to know what to do with a proposal when the 
>> ideal answer is “we need to see how it plays out in practice and then decide 
>> whether to accept it.” Theoretical discussion untempered by practical 
>> prototyping is a great way for a group to talk itself into a bad idea. (This 
>> will especially be a problem with future work to build out generics & 
>> existentials.)
> 
> I agree.  Do you have specific thoughts here on what could be done 
> differently?

I think we can partially solve this by having an extra stage of “stability” in 
our documentation.  Right now, things are either officially part of the 
language or they aren’t (with a very short beta period between WWDC and the 
Fall).  What I would like to see in the documentation is a notion of how sure 
we are of a particular piece of API or syntax.

Unstable - This is actively under development/design and should be expected to 
change. It is not safe to build frameworks on top of this.

Pre-Stable - We think we have a design which works, but we need to see how it 
works in the larger ecosystem before guaranteeing stability.  Anything built on 
this should be prepared for potentially large changes in the future, and be 
marked “Pre-Stable” themselves.

Stable - This has been extensively tested in the actual swift ecosystem and 
proven itself a useful addition.  Any changes to this in the future are 
guaranteed to either be source-compatible or have a full depreciation cycle. It 
is completely safe to build on.

I think being explicit about what we expect to change in the future, and having 
a notion of “stable” that is truly stable will give us a lot more freedom to 
experiment as well as room to fix our mistakes.

Thanks,
Jon___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[David Sweeris via swift-evolution]

> 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 more easily, I'm sticking 
> with my using syntax here:
> 
> var theNames:[String] = []
> while let eachItem = theIterator.next() using (var theTotal = 0) where 
> (theTotal < 100) {
>   theNames.append(eachItem.name)
>   theTotal += eachItem.value
> }
> 
> Depending upon your preference on how to structure the using and where parts 
> this is shorter and easier.
> 
> I think you just reinvented the C-style for loop, that was removed in SE-0007 
> .
Eh, as long as a feature wasn’t removed for security or correctness reasons 
(which isn’t the case with SE-0007), I don’t see a problem with one proposal 
enabling functionality that was removed by another. It’s not like we said 
C-style for loops are evil or anything, just that they weren’t right for Swift. 
If it turns out that something which otherwise is right for Swift can be 
“abused” to get C-style for loop semantics, then those who voted against 
SE-0007 are free to try out this new syntax and see if that helps them. IMHO, 
anyway.

- Dave Sweeris___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Introducing synthesized locks

[Karl Wagner via swift-evolution]

> 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 thought i bring it up here. I think it would 
> quite easily be possible to introduce a synchronized qualifier for 
> struct/class objects that automatically synthesize a semaphore variable on 
> the object and use it to lock said method. Here is an example of how that 
> would work
> 
> Without the synchronized attribute (code written in mail, not compiled):
> 
> class Obj {
> 
>private let sema = DispatchSemaphore(value: 1)
> 
>   func synchronizedMethod() {
>   sema.wait()
>   defer {
>   sema.signal()
>   }
>   // do something...
>   }
> }
> 
> With synchronized attribute (the semaphore/wait/deferred-signal is 
> synthesized by Swift automatically)
> 
> class Obj {
> 
>   synchronized func method() {
>   // semaphore is synthesized automatically, do something…
>   }
> }
> 
> 
> Cheers,
> Erik
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

Swift does not currently have any special support for concurrency. That will 
undoubtedly come in some future version of Swift, and atomic operations and 
data are pretty common use-cases which I’m sure the community will want covered.

- Karl
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[John McCall via swift-evolution]

> 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 of 
> Swift and to be prepared for changes.

It's not hard to figure out what any of these *should* do in Swift 4.  I'm not 
going to commit to promising that Swift 4 will not have bugs that cause 
deviations from that.  If the Core Team decides that something needs to happen 
with parameter destructuring in Swift 4, that will not go without comment here.

John.

> 
> Given :
> 
> func fooParam(_ x: Int, _ y: Int){}
> func fooTuple(_ x: (Int, Int)) {}
> 
> and
> 
> var closureParam = { (x: Int, y: Int) in print("in closureParam") }
> var closureTuple = { (x: (Int, Int)) in  }
> 
> 
> * What will be the result in Swift 4 release? :
>  1. type(of:fooParam)
>  2. type(of:fooTuple)
>  3. type(of:closureParam)
>  4. type(of:closureTuple)
> 
> * Will this be true in Swift 4 release? :
>  1. type(of: fooParam) == type(of: fooTuple)
>  2. fooParam is ((Int,Int))->()
>  3. fooTuple is (Int,Int)->()
>  4. type(of: closureParam) == type(of: closureTuple)
>  5. closureParam is ((Int,Int))->()
>  6. closureTuple is (Int,Int)->()
> 
> * Will this code still be valid in Swift 4 release? :
>  1.
>   closureTuple = closureParam
>   closureTuple((1,2)) // prints "in closureParam"
> 
>  2.
>   var f: () -> Int = { 5 } // function with no parameters
>   var g: (()) -> Int = { 5 }  // function taking a single () parameter
>   f = g
>   f()
> 
> * Does core team plan to introduce some syntactic sugar for tuple argument 
> destructuring in closures *before* Swift 4 release?
> If so, what do you think about a suggestion to allow type inference for 
> currently allowed syntax for tuple argument destructuring? I.e.
> allowed: .filter {(friend: (name: String, age: Int)) in friend.age >= 18 }
> proposed: .filter {(friend: (name, age)) in friend.age >= 18 }
> 
> * And the same for passing function with no parameters if function with 
> single Void parameter is expected? I.e. in such situation:
> func foo(_ callback: (T)->Void) {}
> func bar(){}
> foo(bar)
> 
> 
> Thank you for your time.
> Vladimir.
> 
> On 12.06.2017 20:15, John McCall via swift-evolution wrote:
>>> 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 could be improved. Instead of fighting these propositions (which make 
>>> sense), I wanted create a few proposal which would improve these recent 
>>> changes with a few simple rules.
>>> 
>>> My propositions are based on the recent decisions and in the continuation 
>>> of SE-0110. The first one is about Void.
>>> Void is historically defined as the type of the empty tuple. The reason of 
>>> this is that arguments were initially considered as tuple.
>> The dominant consideration here was always return types, not parameters.  
>> I'm not sure there was ever much point in writing Void in a parameter list, 
>> but whatever reasons there were surely vanished with SE-0066.
>> Note that 'void' in C was originally exclusively a return type.  ANSI gave 
>> it a new purpose it with void*, but the meaning is totally unrelated.
>> John.
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Pavol Vaskovic via swift-evolution]

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 = 0) where
> (theTotal < 100) {
> theNames.append(eachItem.name)
> theTotal += eachItem.value
> }
>
>
> Depending upon your preference on how to structure the using and where
> parts this is shorter and easier.
>

I think you just reinvented the C-style for loop, that was removed in
SE-0007

.

--Pavol
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Ted Kremenek via swift-evolution]

> 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:
>>> 
>>> I think having a queue to submit "proposals for eventually", written when 
>>> the inspiration is there, and having a core team review (say once a month 
>>> or even once a quarter) of their viability for future Swift directions 
>>> would be amazingly valuable.
>> 
>> This is a good point.  I think the concern about a queue is that ideas in it 
>> may still be subject to starvation if the queue gets too long.  Ideas also 
>> can atrophy in their relevance as the language evolves but proposals stay in 
>> the queue.  It then becomes a delicate matter when closing out old 
>> proposals. …
>> 
>> The point about understanding “viable for future Swift directions” is key 
>> here.  Viability really comes down to trajectory for the language.  None of 
>> us are fully omniscient about what is coming in future releases, but we do 
>> have a sense of some of the priorities for the language that we need to 
>> tackle, balanced with what **kind** of changes are still acceptable to take 
>> into the language depending on the kind of disruption they cause for users, 
>> the tools we have to mitigate any pain with those changes, etc.
> 
> This touches on two related concerns I’ve long had about how swift-evolution 
> has worked so far.
> 
> Concern #1 is that we consider proposals in relative isolation, on their own 
> merits. That’s understandable and wise. Without this focus, we’d never reach 
> conclusions about anything. However, this does tilt the process toward greedy 
> optimization as we traverse the language space. I worry that there’s not 
> enough attention to the big picture.

I agree that some of the proposals have felt like steps of a hill-climbing 
algorithm.

A few thoughts here:

- In contrast to the greedy optimization analogy, the series of manifestos in 
the Swift 4 timeframe (ABI stability, String, Ownership) are intended to 
provide an umbrella of design for what will turn out to be related but separate 
SE proposals.  The idea of these manifestos is to chart a direction for design 
and provide the basis for which the proposals related to the goals of the 
manifesto will be evaluated.

- Many SE proposals have been about language refinements, which fall into a 
category of topics that have been part of an ongoing design discussion for 
Swift for years — including long before Swift was publicly announced.  While 
the proposals may sometimes feel disjoint, their evaluation is not necessarily 
so.  Often for me proposals relate (directly or indirectly) to design 
discussions from previous versions of Swift (including pre-Swift 1) that help 
provide broader optics when evaluating the merit of the proposals.  Sometimes 
when a proposal comes back for revision it incorporates those optics.

- 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 discussion and design happens.  The question in my 
mind is when these concerns come up should we throttle individual proposals and 
take more time to take a broader view?  Maybe that’s the answer.  Having been 
in discussions in the Core Team meetings I can say that sometimes it is clear 
there is a broader topic to be discussed, and other times it isn’t.

> 
> Concern #2 is that it’s hard to know what to do with a proposal when the 
> ideal answer is “we need to see how it plays out in practice and then decide 
> whether to accept it.” Theoretical discussion untempered by practical 
> prototyping is a great way for a group to talk itself into a bad idea. (This 
> will especially be a problem with future work to build out generics & 
> existentials.)

I agree.  Do you have specific thoughts here on what could be done differently?

> 
> Swift is already a very featureful language, and not always in a good way. A 
> new feature that makes good sense in the context of a particular problem may 
> make less sense when we consider the totality of its effect on the programmer 
> model: its mental burden, its unforeseen interactions, its surprising 
> pitfalls. How often do we reviewers give only a perfunctory answer to “Does 
> this proposal fit well with the feel and direction of Swift?” How often _can_ 
> we give anything but?
> 
> The net result is that IMO we tend to over-favor narrow solutions that solve 
> very specific problems, and under-favor simpler, more general features that 
> are good-enough solutions to _many_ problems at once — not as nice for any 
> _one_ of those problems in isolation, but nicer to work with taken as a whole.
> 
> The Great Access Modifiers Wars and the recent fussing of SE-110 fallout are 
> good examples 

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

[Jens Persson via swift-evolution]

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 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
>> (latest dev snapshot) Swift 4, so this is the behavior of both Swift 3(.2)
>> and 4:
>> func foo() -> Void {}
>> func foo(_: Void) -> Void {} // This is OK
>> func bar(fn: () -> Void) {}
>> func bar(fn: (_: Void) -> Void) {} // ERR: Invalid redecl.
>>
>> I think the least surprising behavior here would be no error, rather than
>> two.
>> The current behavior with one error is very surprising.
>>
>
> As I understand, currently in Swift 4 there are a number of bugs related
> to function types, so I believe it is incorrect to make conclusions based
> on current behavior of Swift 4 code. I've asked John McCall in this thread
> about *planned* behavior of some Swift 4 release code related to function
> types, let's see what will be the reply.
>
> (I'd suggest to create a bug on bugs.swift.org for this particular issue
> - probably this will help to improve Swift 4 compiler)
>
>
>>
>> On Mon, Jun 12, 2017 at 10:09 PM, Xiaodi Wu via swift-evolution <
>> swift-evolution@swift.org > wrote:
>>
>> On Mon, Jun 12, 2017 at 3:04 PM, Jérémie Girault <
>> jeremie.gira...@gmail.com
>> > 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.
>>
>> Yes, it requires compiler support.
>>
>> This proposal is an alternate solution.
>>
>> My point is that updating Void according to this proposal would
>>   - preserve the type system in a better way
>>   - have better source compatibility (in time for swift 4
>> release, were we
>> probably won’t see tuple splatting)
>>   - also keep the elegant original syntax of swift instead of
>> stacking
>> parenthesis
>>
>> The impact for code writers would be minimized on time for swift
>> 4 release
>>
>> As for return values: this proposition does not intend to change
>> the how
>> return value of Void functions works.
>>
>> —
>> very short reply expected - vsre.info 
>> Jérémie Girault
>>
>> On 12 juin 2017 at 21:45:08, Xiaodi Wu (xiaodi...@gmail.com
>> ) wrote:
>>
>> On Mon, Jun 12, 2017 at 2:32 PM, Jérémie Girault<
>>> jeremie.gira...@gmail.com
>>> >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 argument list. Likewise `let x =
>>> ` will not
>>> compile.
>>>
>>> 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 of Void from () to
>>> “something
>>> else” that is type-compatible with SE-0110 (and splatting in
>>> the future).
>>>
>>>
>>> I'm not sure I understand your motivation. Void is just a
>>> typealias. If
>>> tomorrow Void meant something else, all functions must still
>>> return (), and
>>> there is still no implicit tuple splatting.
>>>
>>
>>
>>
>>> If you want an example of the changes needed to migrate to
>>> swift4, just
>>> look at the 42 files of handling parenthesis PR of RxSwift
>>> needed for
>>> swift4 upgrade : https://github.com/ReactiveX/R
>>> xSwift/pull/1282/files
>>> 
>>>
>>>
>>> Indeed, that's the result of SE-0110; these parentheses are
>>> needed because
>>> there is no implicit tuple splatting. They would be required
>>> even if `Void`
>>> did not exist in the language at all.
>>>
>>>
>>> —
>>> very short reply expected -vsre.info 
>>> Jérémie Girault
>>>
>>> On 12 juin 2017 at 21:18:06, Xiaodi Wu (xiaodi...@gmail.com
>>> 

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

[Vladimir.S via swift-evolution]

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 an example of one such remaining inconsistency, it's still in (latest dev 
snapshot) Swift 4, so this is the behavior of both Swift 3(.2) and 4:

func foo() -> Void {}
func foo(_: Void) -> Void {} // This is OK
func bar(fn: () -> Void) {}
func bar(fn: (_: Void) -> Void) {} // ERR: Invalid redecl.

I think the least surprising behavior here would be no error, rather than two.
The current behavior with one error is very surprising.


As I understand, currently in Swift 4 there are a number of bugs related to function 
types, so I believe it is incorrect to make conclusions based on current behavior of 
Swift 4 code. I've asked John McCall in this thread about *planned* behavior of some 
Swift 4 release code related to function types, let's see what will be the reply.


(I'd suggest to create a bug on bugs.swift.org for this particular issue - probably 
this will help to improve Swift 4 compiler)





On Mon, Jun 12, 2017 at 10:09 PM, Xiaodi Wu via swift-evolution 
> wrote:


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. 



Yes, it requires compiler support.

This proposal is an alternate solution.

My point is that updating Void according to this proposal would
  - preserve the type system in a better way
  - have better source compatibility (in time for swift 4 release, were 
we
probably won’t see tuple splatting)
  - also keep the elegant original syntax of swift instead of stacking
parenthesis

The impact for code writers would be minimized on time for swift 4 
release

As for return values: this proposition does not intend to change the how
return value of Void functions works.

—
very short reply expected - vsre.info 
Jérémie Girault

On 12 juin 2017 at 21:45:08, Xiaodi Wu (xiaodi...@gmail.com
) wrote:


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 argument list. Likewise `let x = ` will 
not
compile.

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 of Void from () to 
“something
else” that is type-compatible with SE-0110 (and splatting in the 
future).


I'm not sure I understand your motivation. Void is just a typealias. If
tomorrow Void meant something else, all functions must still return (), 
and
there is still no implicit tuple splatting.





If you want an example of the changes needed to migrate to swift4, 
just
look at the 42 files of handling parenthesis PR of RxSwift needed 
for
swift4 upgrade : 
https://github.com/ReactiveX/RxSwift/pull/1282/files



Indeed, that's the result of SE-0110; these parentheses are needed 
because
there is no implicit tuple splatting. They would be required even if 
`Void`
did not exist in the language at all.


—
very short reply expected -vsre.info 
Jérémie Girault

On 12 juin 2017 at 21:18:06, Xiaodi Wu (xiaodi...@gmail.com
) wrote:


On Mon, Jun 12, 2017 at 2:05 PM, David Hart>wrote:



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.

If I recall, a number of conversations have been 

Re: [swift-evolution] Int indexing into UTF16View

[Jordan Rose via swift-evolution]

> 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 
>> numeric indices should be used when indexing into a string, because it only 
>> applies when strings fall into a very specific format and encoding.
> 
> Knowing this is required for accessibility support on macOS, since it’s 
> needed to implement NSAccessibility methods such as 
> accessibilityAttributedString(for:), accessibilityRTF(for:), 
> accessibilityFrame(for:), etc.

I think Tony was getting at knowing the best indices for a string, vs. a format 
or API that is documented to use UTF-8 or UTF-16 indexes specifically (like, 
unfortunately, most of Cocoa and Cocoa Touch). It stinks that those may not be 
random-access if the underlying string buffer turns out to not be UTF-16, but 
that's true with NSString as well.

Jordan

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Xiaodi Wu via swift-evolution]

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 (xiaodi...@gmail.com) wrote:
>>
>> On Mon, Jun 12, 2017 at 4:47 PM, Jérémie Girault > .com> 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.
>>> - maybe it should be revised around this ? Simple example :
>>>
>>> `typealias Callback = (T) -> Void` -> `Callback` will give
>>> `(Void) => Void`.
>>>
>>> It was acceptable before swift4 but no more. However nobody cares about
>>> this `Void` argument and actually we know it’s value. So why let the
>>> developer type it ?
>>>
>>
>> Ah, I see. The purpose of SE-0029...SE-0110 was to make it possible to
>> distinguish an argument list `(Void)` from an argument list `()`. This does
>> cause some verbosity where previously users relied on implicit tuple
>> splatting. Ideally, we would bring back some syntactic sugar to make this
>> more ergonomic. But, whether or not the spelling is made more
>> user-friendly, the point here is that _everybody_ should care about this
>> `Void` argument.
>>
>> It is still be typechecked and appropriate errors should be reported to
>> the user so _nobody_ will ignore it.
>>
>> But with the proposal the code will be striped out of Void arguments at
>> compile-time. I think it's a win for the developer on a lot of grounds. The
>> fact that this proposal integrates with the type-system is also important.
>>
>> If you are not comfortable about Void being stripped, we can also discuss
>> alternatives: someone was suggesting me that it would be possible to
>> replace :
>>
>> ```
>>
>> func foo(t: T, u: U) -> V {
>>
>>   // do something with t and u
>>
>>   // return some V
>>
>> }
>>
>> ```
>>
>> with
>>
>> ```
>>
>> func foo(u: Int) -> String { let t = ()
>>
>>   // do something with t and u
>>
>>   // return some V
>>
>> }
>>
>> ```
>>
>> or
>>
>> ```
>>
>> func foo(t: Void = (), u: Int) -> String {
>>
>>   // do something with t and u
>>
>>   // return some V
>>
>> }
>>
>> ```
>>
>> I don’t know what you would consider more effective or elegant (at an
>> implementation level) but it’s the same result for the developper.
>>
>
Ah, but I think I catch your drift with the last example. Is this a more
general point that the compiler should treat every parameter of type Void
as having an implied default value of Void? That would be an interesting
idea.

What is the goal of such changes? Is it to allow you to write `foo()`
> instead of `foo(())` for a function `foo` of type `(T) -> Void`?
>
> If so, then I think what you're seeking to do is reverse SE-0066 (as
> Vladimir points out), which explicits details how it's is an intentional
> change to require such a spelling. I think you're starting from the premise
> that this is unintended or undesirable, when in fact it is deliberate and
> approved.
>
> It is also, unless I'm mistaken, not the issue that was raised initially
> with respect to SE-0110, which had to do with the extra boilerplate of
> destructuring a tuple inside a closure, something that was not so obvious
> before implementation.
>
> My point here is that `Void` should be “striped” by “reducing” argument
>>> list signatures.
>>>
>>> —
>>> very short reply expected - vsre.info
>>> Jérémie Girault
>>>
>>> On 12 juin 2017 at 19:15:18, John McCall (rjmcc...@apple.com) wrote:
>>>
>>>
>>> On Jun 12, 2017, at 4:48 AM, Jérémie Girault via swift-evolution <
>>> swift-evolution@swift.org> 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 (which
>>> make sense), I wanted create a few proposal which would improve these
>>> recent changes with a few simple rules.
>>>
>>> My propositions are based on the recent decisions and in the
>>> continuation of SE-0110. The first one is about Void.
>>> Void is historically defined as the type of the empty tuple. The reason
>>> of this is that arguments were initially considered as tuple.
>>>
>>>
>>> The dominant consideration here was always return types, not
>>> parameters.  I'm not sure there was ever much point in writing Void in a
>>> parameter list, but whatever reasons there were surely vanished with
>>> SE-0066.
>>>
>>> Note that 'void' in C was originally exclusively a return type.  ANSI
>>> gave it a new purpose it with void*, but the meaning is totally unrelated.
>>>
>>> John.
>>>
>>>
>>
>>
>
___
swift-evolution mailing list

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

[Vladimir.S via swift-evolution]

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, _ y: Int){}
func fooTuple(_ x: (Int, Int)) {}

and

var closureParam = { (x: Int, y: Int) in print("in closureParam") }
var closureTuple = { (x: (Int, Int)) in  }


* What will be the result in Swift 4 release? :
  1. type(of:fooParam)
  2. type(of:fooTuple)
  3. type(of:closureParam)
  4. type(of:closureTuple)

* Will this be true in Swift 4 release? :
  1. type(of: fooParam) == type(of: fooTuple)
  2. fooParam is ((Int,Int))->()
  3. fooTuple is (Int,Int)->()
  4. type(of: closureParam) == type(of: closureTuple)
  5. closureParam is ((Int,Int))->()
  6. closureTuple is (Int,Int)->()

* Will this code still be valid in Swift 4 release? :
  1.
closureTuple = closureParam
closureTuple((1,2)) // prints "in closureParam"

  2.
var f: () -> Int = { 5 } // function with no parameters
var g: (()) -> Int = { 5 }  // function taking a single () parameter
f = g
f()

* Does core team plan to introduce some syntactic sugar for tuple argument 
destructuring in closures *before* Swift 4 release?
If so, what do you think about a suggestion to allow type inference for currently 
allowed syntax for tuple argument destructuring? I.e.

allowed: .filter {(friend: (name: String, age: Int)) in friend.age >= 18 }
proposed: .filter {(friend: (name, age)) in friend.age >= 18 }

* And the same for passing function with no parameters if function with single Void 
parameter is expected? I.e. in such situation:

func foo(_ callback: (T)->Void) {}
func bar(){}
foo(bar)


Thank you for your time.
Vladimir.

On 12.06.2017 20:15, John McCall via swift-evolution wrote:


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 
could be improved. Instead of fighting these propositions (which make sense), I 
wanted create a few proposal which would improve these recent changes with a few 
simple rules.


My propositions are based on the recent decisions and in the continuation of 
SE-0110. The first one is about Void.
Void is historically defined as the type of the empty tuple. The reason of this is 
that arguments were initially considered as tuple.


The dominant consideration here was always return types, not parameters.  I'm not 
sure there was ever much point in writing Void in a parameter list, but whatever 
reasons there were surely vanished with SE-0066.


Note that 'void' in C was originally exclusively a return type.  ANSI gave it a new 
purpose it with void*, but the meaning is totally unrelated.


John.


___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Xiaodi Wu via swift-evolution]

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  .com> 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.
>> - maybe it should be revised around this ? Simple example :
>>
>> `typealias Callback = (T) -> Void` -> `Callback` will give
>> `(Void) => Void`.
>>
>> It was acceptable before swift4 but no more. However nobody cares about
>> this `Void` argument and actually we know it’s value. So why let the
>> developer type it ?
>>
>
> Ah, I see. The purpose of SE-0029...SE-0110 was to make it possible to
> distinguish an argument list `(Void)` from an argument list `()`. This does
> cause some verbosity where previously users relied on implicit tuple
> splatting. Ideally, we would bring back some syntactic sugar to make this
> more ergonomic. But, whether or not the spelling is made more
> user-friendly, the point here is that _everybody_ should care about this
> `Void` argument.
>
> It is still be typechecked and appropriate errors should be reported to
> the user so _nobody_ will ignore it.
>
> But with the proposal the code will be striped out of Void arguments at
> compile-time. I think it's a win for the developer on a lot of grounds. The
> fact that this proposal integrates with the type-system is also important.
>
> If you are not comfortable about Void being stripped, we can also discuss
> alternatives: someone was suggesting me that it would be possible to
> replace :
>
> ```
>
> func foo(t: T, u: U) -> V {
>
>   // do something with t and u
>
>   // return some V
>
> }
>
> ```
>
> with
>
> ```
>
> func foo(u: Int) -> String { let t = ()
>
>   // do something with t and u
>
>   // return some V
>
> }
>
> ```
>
> or
>
> ```
>
> func foo(t: Void = (), u: Int) -> String {
>
>   // do something with t and u
>
>   // return some V
>
> }
>
> ```
>
> I don’t know what you would consider more effective or elegant (at an
> implementation level) but it’s the same result for the developper.
>

What is the goal of such changes? Is it to allow you to write `foo()`
instead of `foo(())` for a function `foo` of type `(T) -> Void`?

If so, then I think what you're seeking to do is reverse SE-0066 (as
Vladimir points out), which explicits details how it's is an intentional
change to require such a spelling. I think you're starting from the premise
that this is unintended or undesirable, when in fact it is deliberate and
approved.

It is also, unless I'm mistaken, not the issue that was raised initially
with respect to SE-0110, which had to do with the extra boilerplate of
destructuring a tuple inside a closure, something that was not so obvious
before implementation.

My point here is that `Void` should be “striped” by “reducing” argument
>> list signatures.
>>
>> —
>> very short reply expected - vsre.info
>> Jérémie Girault
>>
>> On 12 juin 2017 at 19:15:18, John McCall (rjmcc...@apple.com) wrote:
>>
>>
>> On Jun 12, 2017, at 4:48 AM, Jérémie Girault via swift-evolution <
>> swift-evolution@swift.org> 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 (which make
>> sense), I wanted create a few proposal which would improve these recent
>> changes with a few simple rules.
>>
>> My propositions are based on the recent decisions and in the continuation
>> of SE-0110. The first one is about Void.
>> Void is historically defined as the type of the empty tuple. The reason
>> of this is that arguments were initially considered as tuple.
>>
>>
>> The dominant consideration here was always return types, not parameters.
>> I'm not sure there was ever much point in writing Void in a parameter list,
>> but whatever reasons there were surely vanished with SE-0066.
>>
>> Note that 'void' in C was originally exclusively a return type.  ANSI
>> gave it a new purpose it with void*, but the meaning is totally unrelated.
>>
>> John.
>>
>>
>
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Jérémie Girault via swift-evolution]

—
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 this proposal. An maybe that’s why we misunderstood ourselves
> (around 0110 / 0066). This proposal addresses arguments.
> - maybe it should be revised around this ? Simple example :
>
> `typealias Callback = (T) -> Void` -> `Callback` will give
> `(Void) => Void`.
>
> It was acceptable before swift4 but no more. However nobody cares about
> this `Void` argument and actually we know it’s value. So why let the
> developer type it ?
>

Ah, I see. The purpose of SE-0029...SE-0110 was to make it possible to
distinguish an argument list `(Void)` from an argument list `()`. This does
cause some verbosity where previously users relied on implicit tuple
splatting. Ideally, we would bring back some syntactic sugar to make this
more ergonomic. But, whether or not the spelling is made more
user-friendly, the point here is that _everybody_ should care about this
`Void` argument.

It is still be typechecked and appropriate errors should be reported to the
user so _nobody_ will ignore it.

But with the proposal the code will be striped out of Void arguments at
compile-time. I think it's a win for the developer on a lot of grounds. The
fact that this proposal integrates with the type-system is also important.

If you are not comfortable about Void being stripped, we can also discuss
alternatives: someone was suggesting me that it would be possible to
replace :

```

func foo(t: T, u: U) -> V {

  // do something with t and u

  // return some V

}

```

with

```

func foo(u: Int) -> String { let t = ()

  // do something with t and u

  // return some V

}

```

or

```

func foo(t: Void = (), u: Int) -> String {

  // do something with t and u

  // return some V

}

```

I don’t know what you would consider more effective or elegant (at an
implementation level) but it’s the same result for the developper.




My point here is that `Void` should be “striped” by “reducing” argument
> list signatures.
>
> —
> very short reply expected - vsre.info
> Jérémie Girault
>
> On 12 juin 2017 at 19:15:18, John McCall (rjmcc...@apple.com) wrote:
>
>
> On Jun 12, 2017, at 4:48 AM, Jérémie Girault via swift-evolution <
> swift-evolution@swift.org> 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 (which make
> sense), I wanted create a few proposal which would improve these recent
> changes with a few simple rules.
>
> My propositions are based on the recent decisions and in the continuation
> of SE-0110. The first one is about Void.
> Void is historically defined as the type of the empty tuple. The reason of
> this is that arguments were initially considered as tuple.
>
>
> The dominant consideration here was always return types, not parameters.
> I'm not sure there was ever much point in writing Void in a parameter list,
> but whatever reasons there were surely vanished with SE-0066.
>
> Note that 'void' in C was originally exclusively a return type.  ANSI gave
> it a new purpose it with void*, but the meaning is totally unrelated.
>
> John.
>
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Int indexing into UTF16View

[Michael Ilseman via swift-evolution]

> 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 
>>> > wrote:
>>> 
>>> Hello,
>>> 
>>> When working with Strings which are known to be ASCII, I tend to use the 
>>> UTF16View for the performance of random access. I would also like to have 
>>> the convenience of indexing with Int:
>>> 
>>> let barcode = "M1X/CLEMENT   EELT9QBQGVAAMSEZY1353 244 21D 531  
>>> 10A1311446838”
>>> let name = barcode.utf16[2..<22]
>>> let pnrCode = barcode.utf16[23..<30]
>>> let seatNo = barcode.utf16[47..<51]
>>> let fromCity = barcode.utf16[30..<33]
>>> let toCity = barcode.utf16[33..<36]
>>> let carrier = barcode.utf16[36..<39]
>>> let flightNumber = barcode.utf16[39..<44]
>>> let day = barcode.utf16[44..<47]
>>> 
>>> I define my own subscript in an extension to UTF16View but I think this 
>>> should go in the Standard Library.
>>> Any thoughts?
>>> 
>>> David.
>>> ___
>>> swift-evolution mailing list
>>> swift-evolution@swift.org 
>>> https://lists.swift.org/mailman/listinfo/swift-evolution 
>>> 
>> 
>> 
>> Hi David,
>> 
>> My view is positional shredding of strings is enough of a use case that we 
>> ought to think about handling it better. I don’t think having to convert the 
>> string into an Array of Character, or bytes, or use Data, should be 
>> necessary, since this implies losing the stringiness of the slices you are 
>> creating, which is an inconvenience for many use cases. Strings-as-data is a 
>> thing we should support, and support well.
>> 
>> But I also don’t think giving String or its views integer indices is the 
>> right way to go either, incorrectly implying as it does random access 
>> 
>> (or, even if we did end up making utf16 permanently random-access, 
>> encouraging people towards using utf16 to support this use case when often 
>> they’d be better served sticking with characters).
>> 
>> There’s a few things to note about the example you give:
>> 1) Do you really want utf16 view slices for your variable types? Maybe in 
>> this case you do, but I would guess a lot of the time what is desired would 
>> be a (sub)string.
> 
> Not really. I would be quite happy with Substring. The variable type is just 
> the consequence of my choice of the UTF16 view.
> 
>> 2) Do you really want to hard-code integer literals into your code? Maybe 
>> for a quick shell script use case, but for anything more this seems like an 
>> anti-pattern that integer indices encourage.
> 
> I agree. I took the code out of a project of mine and simplified it. I have 
> the Int ranges defined as named constants.
> 
>> 3) Are you likely to actually want validation at each step – that the string 
>> was long enough, that the string data was valid at that point?
> 
> No. I pre-validate the string and it's length beforehand.
> 
>> 4) This case doesn’t seem to need random access particularly, so much as the 
>> (questionable? see above) convenience of integer indexing. Although 
>> reordered in the example, it seems like the code could be written to 
>> progressively traverse the string from left to right to get the fields. 
>> Unless the plan is to repeatedly access some fields over and over. But I’m 
>> not sure we’d want to put affordances into the std lib to encourage 
>> accessing stringly typed data...
> 
> Indeed. I initially rewrote the code to traverse the string from left to 
> write, advancing indices by deltas. But (1) it made the code less readable, 
> (2) further removed from the barcode spec which is defined in terms of 
> offsets, and (3) more brittle - editing deltas forces chain modifications:
> 
> let nameStart = barcode.index(name.startIndex, offsetBy: 2)
> let nameEnd = barcode.index(nameStart, offsetBy: 20)
> let name = barcode[nameStart.. 
> let pnrCodeStart = barcode.index(nameEnd, offsetBy: 1)
> let pnrCodeEnd = barcode.index(pnrCodeStart, offsetBy: 7)
> let pnrCode = barcode[pnrCodeStart.. 
>> So the question is, what affordances should we put into the standard 
>> library, or maybe other libraries, to help with these use cases? This is a 
>> big design space to explore, and at least some ideas ought to feed into our 
>> ongoing improvements to String for future releases.
>> 
>> For example:
>> 
>> Now that we have Substring, it opens up the ability to efficiently consume 
>> from the front (since it’s just adjusting the substring range):
>> 
>> extension Collection where Self == SubSequence {
>> // or some better name...
>> mutating func removeFirst(_ n: IndexDistance) -> SubSequence? {
>> guard let i = index(startIndex, offsetBy: n, 

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

[Jérémie Girault via swift-evolution]

—
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 22:34:45, Xiaodi Wu (xiaodi...@gmail.com) wrote:
>
> On Mon, Jun 12, 2017 at 3:16 PM, Jérémie Girault  gmail.com> 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 Void is a tuple or anything.
>> Void is Nothing in the programmer’s mind. An instance of Void shouldn’t
>> even exist.
>>
>
> Sorry, that's not correct. Void is what's called Unit in other languages.
> It exists. That is why functions with "no return value" return Void. OTOH,
> Never does not exist. This discussion was had in great detail during the
> naming debate over Never.
>
> Let’s put facts in front of correctness assertions. Is Void = Unit in C or
> c++ ? can you create instances of void in java ? you have Void for generics.
>  https://en.wikipedia.org/wiki/Unit_type
>

Sorry, I don't understand your line of argumentation. Fact: in Swift, Void
is the name of the unit type. Are you objecting to the naming of the unit
type in Swift? Do you want the unit type to have other features? Is there
some other way of modeling the unit type other than a tuple of arity 0 that
you prefer?

As I’m saying I’m not discussing the name. I propose to replace Void with
another mechanism so that source compatibility is improved. Defining a unit
type and names is trivial afterwards.




> And if you look at assembly, sending void or returning void actually means
> "nothing to push on the stack / nothing to pop”. Seems like having this
> stripping on signatures at compile-time could be great !
>
> Actually, in my opinion we could discuss naming when we agree that the
> mechanism works, using this name is just a way to not impact the developer
> with code changes.
>
> So either we agree on the fact that the mechanism works and we can move on
> to naming, or we get back on the topic : do you see a flaw in the proposal
> rules ? It elegantly transforms signature arity and provides the programmer
> a natural syntax to express it’s code.
>

I have read your proposal three times, but I do not understand what it is
proposing, in part because your proposal contains factual errors in the
premises. For instance, it claims repeatedly that Void is a typealias for
() because of something to do with argument lists, which is not true. It is
therefore unclear to me what it is you are proposing to do and what is
motivating such a proposal.

All I am saying is that, in previous conversations on this list, people who
actually do the work of implementing features in the compiler have stated
that `typealias Void = ()` is a fait accompli. With that as a starting
point, what do you propose to do?

You probably know the original designer intent better than me because you
are here for a longer time, but that’s not the point. And thank you for
trying to understand it again :

- The goal of the proposal is to replace Void by an intrinsic which would
reduce the arity of argument list it is present in.

- Why ? Because, especially when using generics, Void will easily be
introduced in parameter lists. Actually it introduces useless arguments. If
you follow the rules in Detailed design, you will see that the reduction of
arity will lead to a better source compatibility and syntax. Moreover the
expected result, from a developer point of view, feels more natural.




>
>
>> The proposed meaning of Void is to be a “lack” of arguments. It means
>> that each “Void” argument reduces the arity of the function by one, at its
>> exact position. Especially look at the canonical signature definition, and
>> the proposed rules of reduction.
>>
>
> I don't understand why you propose to name this new idea "Void". You're
> proposing something that's not even a lack of an argument, but an
> anti-argument, like anti-matter! I'm not sure I understand why this is
> necessary. It seems to be a very strange workaround for one specific issue
> arising from disallowing implicit tuple splatting.
>
>
> Look at other languages, when you put Void in functions in C or java, do
> you need to add a value ? Ease of use is important.
>
> You imply that I disagree with splatting were I don’t, let’s not make it
> personal. This proposal is even compatible with tuple splatting !
>
> The proposal rules seem to work and provides great user value. Let’s try
> to consider this !
>
>
>
>
>> That proposal, if implemented, would effectively allow `Callback`
>> to be called without arguments in the context of swift4.
>>
>> —
>> very short reply expected - vsre.info
>> Jérémie Girault
>>
>> On 12 juin 2017 at 22:06:54, Xiaodi Wu 

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

[Xiaodi Wu via swift-evolution]

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.
> - maybe it should be revised around this ? Simple example :
>
> `typealias Callback = (T) -> Void` -> `Callback` will give
> `(Void) => Void`.
>
> It was acceptable before swift4 but no more. However nobody cares about
> this `Void` argument and actually we know it’s value. So why let the
> developer type it ?
>

Ah, I see. The purpose of SE-0029...SE-0110 was to make it possible to
distinguish an argument list `(Void)` from an argument list `()`. This does
cause some verbosity where previously users relied on implicit tuple
splatting. Ideally, we would bring back some syntactic sugar to make this
more ergonomic. But, whether or not the spelling is made more
user-friendly, the point here is that _everybody_ should care about this
`Void` argument.

My point here is that `Void` should be “striped” by “reducing” argument
> list signatures.
>
> —
> very short reply expected - vsre.info
> Jérémie Girault
>
> On 12 juin 2017 at 19:15:18, John McCall (rjmcc...@apple.com) wrote:
>
>
> On Jun 12, 2017, at 4:48 AM, Jérémie Girault via swift-evolution <
> swift-evolution@swift.org> 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 (which make
> sense), I wanted create a few proposal which would improve these recent
> changes with a few simple rules.
>
> My propositions are based on the recent decisions and in the continuation
> of SE-0110. The first one is about Void.
> Void is historically defined as the type of the empty tuple. The reason of
> this is that arguments were initially considered as tuple.
>
>
> The dominant consideration here was always return types, not parameters.
> I'm not sure there was ever much point in writing Void in a parameter list,
> but whatever reasons there were surely vanished with SE-0066.
>
> Note that 'void' in C was originally exclusively a return type.  ANSI gave
> it a new purpose it with void*, but the meaning is totally unrelated.
>
> John.
>
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Vladimir.S via swift-evolution]

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 motivated by anything to do 
with argument lists.


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`


It has been suggested to rename Void to Unit. I do believe it’s on the commonly 
rejected ideas list (and if it’s not, it ought to be).


Void, however, seem naturally fitted for the absence of argument.

Should `func foo(Void)` be different from `func foo()`?


SE-0110 determined that the two should in fact be different.


Actually *SE-0066* determinate this first:

(code example in *Proposed solution* section)

let f: () -> Int // function with no parameters
let g: (()) -> Int   // function taking a single () parameter
let h: ((())) -> Int // function taking a single () parameter

f();   g(()); h(())  // correct
f(()); g();   h()// errors

Seems like it's just SE-0066 *more correctly* implemented in Swift 4 *in addition* to 
SE-0110 implementation.




I don’t think so. But different from `func foo(Unit)` ? Yes !


It sounds like your quarrel is with the name of the typealias. I don’t see how that 
solves any issues with the loss of tuple splatting. Functions will still return (), 
and you foo(()) is not foo().


My point here is that we probably won’t have splatting for swift4.


But if we consider the type system as a guide, we can consider 3 simple set 
of
rules and restore almost 100% source compatibility while keeping the 
improvement
of SE-0110
- Rules for swift3 tuples-arguments of cardinality zero (Void) in swift 4 
(this
proposition)
- Rules for swift3 tuples-arguments of cardinality one in swift 4 
(proposition to
be done)
- Rules for swift3 tuples-arguments of cardinality > 1 in swift 4 
(proposition to
be done)

—
very short reply expected - vsre.info 
Jérémie Girault

On 12 juin 2017 at 19:25:31, Xiaodi Wu (xiaodi...@gmail.com
) 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.


If I recall, a number of conversations have been raised about Void being a
typealias of (), and the definitive response has been that this falls into 
the
ship-has-sailed category of out-of-scope changes.

More generally, the recent spate of complaints about regressions to a
particular coding style have to do with loss of implicit tuple splatting, 
the
cure for which is a proper implementation of tuple splatting, not poking 
holes
into settled parts of the type system.



On Mon, Jun 12, 2017 at 12:15 John McCall via swift-evolution
> wrote:



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 could be improved. Instead of fighting these propositions (which 
make
sense), I wanted create a few proposal which would improve these recent
changes with a few simple rules.

My propositions are based on the recent decisions and in the 
continuation
of SE-0110. The first one is about Void.
Void is historically defined as the type of the empty tuple. The reason 
of
this is that arguments were initially considered as tuple.


The dominant consideration here was always return types, not parameters. 
I'm not sure there was ever much point in writing Void in a parameter list,

but whatever reasons there were surely vanished with SE-0066.

Note that 'void' in C was originally exclusively a return type.  ANSI 
gave
it a new purpose it with void*, but the meaning is totally unrelated.

John.
___
swift-evolution mailing list
swift-evolution@swift.org 
https://lists.swift.org/mailman/listinfo/swift-evolution




___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Xiaodi Wu via swift-evolution]

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  gmail.com> 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 Void is a tuple or anything.
>> Void is Nothing in the programmer’s mind. An instance of Void shouldn’t
>> even exist.
>>
>
> Sorry, that's not correct. Void is what's called Unit in other languages.
> It exists. That is why functions with "no return value" return Void. OTOH,
> Never does not exist. This discussion was had in great detail during the
> naming debate over Never.
>
> Let’s put facts in front of correctness assertions. Is Void = Unit in C or
> c++ ? can you create instances of void in java ? you have Void for
> generics. https://en.wikipedia.org/wiki/Unit_type
>

Sorry, I don't understand your line of argumentation. Fact: in Swift, Void
is the name of the unit type. Are you objecting to the naming of the unit
type in Swift? Do you want the unit type to have other features? Is there
some other way of modeling the unit type other than a tuple of arity 0 that
you prefer?


> And if you look at assembly, sending void or returning void actually means
> "nothing to push on the stack / nothing to pop”. Seems like having this
> stripping on signatures at compile-time could be great !
>
> Actually, in my opinion we could discuss naming when we agree that the
> mechanism works, using this name is just a way to not impact the developer
> with code changes.
>
> So either we agree on the fact that the mechanism works and we can move on
> to naming, or we get back on the topic : do you see a flaw in the proposal
> rules ? It elegantly transforms signature arity and provides the programmer
> a natural syntax to express it’s code.
>

I have read your proposal three times, but I do not understand what it is
proposing, in part because your proposal contains factual errors in the
premises. For instance, it claims repeatedly that Void is a typealias for
() because of something to do with argument lists, which is not true. It is
therefore unclear to me what it is you are proposing to do and what is
motivating such a proposal.

All I am saying is that, in previous conversations on this list, people who
actually do the work of implementing features in the compiler have stated
that `typealias Void = ()` is a fait accompli. With that as a starting
point, what do you propose to do?


>
>
>> The proposed meaning of Void is to be a “lack” of arguments. It means
>> that each “Void” argument reduces the arity of the function by one, at its
>> exact position. Especially look at the canonical signature definition, and
>> the proposed rules of reduction.
>>
>
> I don't understand why you propose to name this new idea "Void". You're
> proposing something that's not even a lack of an argument, but an
> anti-argument, like anti-matter! I'm not sure I understand why this is
> necessary. It seems to be a very strange workaround for one specific issue
> arising from disallowing implicit tuple splatting.
>
>
> Look at other languages, when you put Void in functions in C or java, do
> you need to add a value ? Ease of use is important.
>
> You imply that I disagree with splatting were I don’t, let’s not make it
> personal. This proposal is even compatible with tuple splatting !
>
> The proposal rules seem to work and provides great user value. Let’s try
> to consider this !
>
>
>
>
>> That proposal, if implemented, would effectively allow `Callback`
>> to be called without arguments in the context of swift4.
>>
>> —
>> very short reply expected - vsre.info
>> Jérémie Girault
>>
>> On 12 juin 2017 at 22:06:54, Xiaodi Wu (xiaodi...@gmail.com) wrote:
>>
>> On Mon, Jun 12, 2017 at 2:56 PM, Jérémie Girault > gmail.com> 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: Any) {}`
>>> I can afterwards “apply” a tuple to a function named `foo` and therefore
>>> execute the function on this tuple.
>>> Calling a function syntax was equivalent to put a tuple next to a
>>> function name:
>>> `foo(42, “hello")` the left-hand is `foo`, the right-hand is `(42,
>>> “hello")` is the tuple.
>>>
>>> The same way if I have
>>> `func foo()`
>>> `foo()` means calling `foo` with argument `()` and there we have our
>>> original `Void`
>>>
>>> That meaning changed recently due to multiple SE implementations
>>> actually.
>>>
>>
>> Tuples-as-arguments never shipped in any version of Swift, and the
>> ability to "apply" a tuple like that was 

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

[Jérémie Girault via swift-evolution]

—
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 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 shouldn’t
> even exist.
>

Sorry, that's not correct. Void is what's called Unit in other languages.
It exists. That is why functions with "no return value" return Void. OTOH,
Never does not exist. This discussion was had in great detail during the
naming debate over Never.

Let’s put facts in front of correctness assertions. Is Void = Unit in C or
c++ ? can you create instances of void in java ? you have Void for
generics. https://en.wikipedia.org/wiki/Unit_type

And if you look at assembly, sending void or returning void actually means
"nothing to push on the stack / nothing to pop”. Seems like having this
stripping on signatures at compile-time could be great !

Actually, in my opinion we could discuss naming when we agree that the
mechanism works, using this name is just a way to not impact the developer
with code changes.

So either we agree on the fact that the mechanism works and we can move on
to naming, or we get back on the topic : do you see a flaw in the proposal
rules ? It elegantly transforms signature arity and provides the programmer
a natural syntax to express it’s code.




> The proposed meaning of Void is to be a “lack” of arguments. It means that
> each “Void” argument reduces the arity of the function by one, at its exact
> position. Especially look at the canonical signature definition, and the
> proposed rules of reduction.
>

I don't understand why you propose to name this new idea "Void". You're
proposing something that's not even a lack of an argument, but an
anti-argument, like anti-matter! I'm not sure I understand why this is
necessary. It seems to be a very strange workaround for one specific issue
arising from disallowing implicit tuple splatting.


Look at other languages, when you put Void in functions in C or java, do
you need to add a value ? Ease of use is important.

You imply that I disagree with splatting were I don’t, let’s not make it
personal. This proposal is even compatible with tuple splatting !

The proposal rules seem to work and provides great user value. Let’s try to
consider this !




> That proposal, if implemented, would effectively allow `Callback` to
> be called without arguments in the context of swift4.
>
> —
> very short reply expected - vsre.info
> Jérémie Girault
>
> On 12 juin 2017 at 22:06:54, Xiaodi Wu (xiaodi...@gmail.com) wrote:
>
> On Mon, Jun 12, 2017 at 2:56 PM, Jérémie Girault <
> jeremie.gira...@gmail.com> 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: Any) {}`
>> I can afterwards “apply” a tuple to a function named `foo` and therefore
>> execute the function on this tuple.
>> Calling a function syntax was equivalent to put a tuple next to a
>> function name:
>> `foo(42, “hello")` the left-hand is `foo`, the right-hand is `(42,
>> “hello")` is the tuple.
>>
>> The same way if I have
>> `func foo()`
>> `foo()` means calling `foo` with argument `()` and there we have our
>> original `Void`
>>
>> That meaning changed recently due to multiple SE implementations actually.
>>
>
> Tuples-as-arguments never shipped in any version of Swift, and the ability
> to "apply" a tuple like that was removed by SE-0029--the original goal was
> to implement this change in time for Swift 2.2.
>
>
>> The parenthesis around the call don't have a tuple meaning anymore.
>> Therefore it breaks a lot of code relying on this feature of the language,
>> which was quite elegant, but could not handle advanced functions features.
>>
>
> Yes, this is an intentional and approved part of SE-0029. The drawbacks
> were enumerated in that proposal and were deemed acceptable.
>
>
>> @john: Void can happen easily in parameters due to generics, the easiest
>> example that breaks with swift4 is
>> `typealias Callback = (T) -> Void`
>> here
>> `Callback` which is perfectly reasonable introduces Void in the
>> argument list and forces the caller to introduces an empty partenthesis set
>> when invoking:
>> ```
>> let foo: Callback = { }
>> foo(())
>> ```
>>
>
> `Callback = (T) -> Void` refers to a callback that takes exactly one
> argument. Since argument lists are not tuples, it is not possible to invoke
> such a callback with zero arguments, or for that matter with two, three,
> four, or five arguments.
>
> That’s were the proposal shines in my opinion: adapting the meaning of
>> Void to the 

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

[Paul Cantrell via swift-evolution]

> 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 proposed directly by the core team as part of an overarching 
> attempt to fix issues with how the type system handles function and tuple 
> types. It was never intended as self-contained fussing over aesthetic purity, 
> or pretty much anything else it's been accused as in recent posts to the 
> list. In this case, there is a "coherent big picture"; the problem is that 
> this big picture was laid out months ago and it's not really fair to ask 
> newcomers to the discussion to dig through mailing list archives to try and 
> find the relevant posts.

Right, sorry to pick on 110. I realize that proposal has taken a lot of abuse 
and become a bit of a boogeyman.

I do realize that there was a coherent (and good!) plan behind the sequence of 
SEs that lead to 110. And for the record, I DO NOT accuse anyone of 
“self-contained fussing over aesthetic purity!” More generally, I do not 
approve of the peanut gallery’s occasional degeneration into nasty ad hominems. 
I have the utmost trust in the expertise and motivation of the core team and 
proposal authors, who have done heroic, excellent work.

The problem here as I see it is that that chain of tuple-related SEs that lead 
to 110, once approved, had unintended consequences for dictionary-as-collection 
operations and RxSwift — consequences that were hard to foresee in discussion, 
but that prototyping could likely have revealed earlier. (My concern #2.)

We are now faced with the unpleasant prospect of working out those consequences 
under a tight timeline, and thus looking for a local solution within tight 
design constraints. (My concern #1.) It seems likely to me that we’re going to 
end up with yet another little language wrinkle that solves the immediate 
problem, but adds to language bloat.

That’s probably the best we can do for the concerns raised by 110 for now; I do 
not mean to derail or denegrate that debate. My argument is that there may be 
an underlying process problem — and thus process solution — to consider for 
future work.

Cheers, P


> 
> Regards,
> Austin
> 
> On Mon, Jun 12, 2017 at 12:47 PM, Paul Cantrell via swift-evolution 
> > 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:
> >>
> >> I think having a queue to submit "proposals for eventually", written when 
> >> the inspiration is there, and having a core team review (say once a month 
> >> or even once a quarter) of their viability for future Swift directions 
> >> would be amazingly valuable.
> >
> > This is a good point.  I think the concern about a queue is that ideas in 
> > it may still be subject to starvation if the queue gets too long.  Ideas 
> > also can atrophy in their relevance as the language evolves but proposals 
> > stay in the queue.  It then becomes a delicate matter when closing out old 
> > proposals. …
> >
> > The point about understanding “viable for future Swift directions” is key 
> > here.  Viability really comes down to trajectory for the language.  None of 
> > us are fully omniscient about what is coming in future releases, but we do 
> > have a sense of some of the priorities for the language that we need to 
> > tackle, balanced with what **kind** of changes are still acceptable to take 
> > into the language depending on the kind of disruption they cause for users, 
> > the tools we have to mitigate any pain with those changes, etc.
> 
> This touches on two related concerns I’ve long had about how swift-evolution 
> has worked so far.
> 
> Concern #1 is that we consider proposals in relative isolation, on their own 
> merits. That’s understandable and wise. Without this focus, we’d never reach 
> conclusions about anything. However, this does tilt the process toward greedy 
> optimization as we traverse the language space. I worry that there’s not 
> enough attention to the big picture.
> 
> Concern #2 is that it’s hard to know what to do with a proposal when the 
> ideal answer is “we need to see how it plays out in practice and then decide 
> whether to accept it.” Theoretical discussion untempered by practical 
> prototyping is a great way for a group to talk itself into a bad idea. (This 
> will especially be a problem with future work to build out generics & 
> existentials.)
> 
> Swift is already a very featureful language, and not always in a good way. A 
> new feature that makes good sense in the context of a particular problem may 
> make less 

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

[Austin Zheng via swift-evolution]

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 case is staging a refactor across two major versions of
Swift, in which the user experience is regressed by the first half of the
"necessary" work before it can be fixed by the second half. Throw in source
compatibility as a goal and you have a problematic situation.

That said, I've clarified what I wanted to, so I'll withdraw respectfully
from this conversation and allow others to express their views.

Austin



On Mon, Jun 12, 2017 at 1:48 PM, Paul Cantrell  wrote:

>
> 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 proposed directly by the core team as part of an overarching
> attempt to fix issues with how the type system handles function and tuple
> types. It was never intended as self-contained fussing over aesthetic
> purity, or pretty much anything else it's been accused as in recent posts
> to the list. In this case, there is a "coherent big picture"; the problem
> is that this big picture was laid out months ago and it's not really fair
> to ask newcomers to the discussion to dig through mailing list archives to
> try and find the relevant posts.
>
>
> Right, sorry to pick on 110. I realize that proposal has taken a lot of
> abuse and become a bit of a boogeyman.
>
> I do realize that there was a coherent (and good!) plan behind the
> sequence of SEs that lead to 110. And for the record, I DO NOT accuse
> anyone of “self-contained fussing over aesthetic purity!” More generally,
> I do not approve of the peanut gallery’s occasional degeneration into
> nasty ad hominems. I have the utmost trust in the expertise and motivation of
> the core team and proposal authors, who have done heroic, excellent work.
>
> The problem here as I see it is that that chain of tuple-related SEs that
> lead to 110, once approved, had unintended consequences for
> dictionary-as-collection operations and RxSwift — consequences that were
> hard to foresee in discussion, but that prototyping could likely have
> revealed earlier. (My concern #2.)
>
> We are now faced with the unpleasant prospect of working out those
> consequences under a tight timeline, and thus looking for a local solution
> within tight design constraints. (My concern #1.) It seems likely to me
> that we’re going to end up with yet another little language wrinkle that
> solves the immediate problem, but adds to language bloat.
>
> That’s probably the best we can do for the concerns raised by 110 for now;
> I do not mean to derail or denegrate that debate. My argument is that there
> may be an underlying process problem — and thus process solution — to
> consider for future work.
>
> Cheers, P
>
>
>
> Regards,
> Austin
>
> On Mon, Jun 12, 2017 at 12:47 PM, Paul Cantrell via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>>
>> > On Jun 12, 2017, at 1:29 AM, Ted Kremenek via swift-evolution <
>> swift-evolution@swift.org> wrote:
>> >
>> >> On Jun 11, 2017, at 4:47 PM, Erica Sadun via swift-evolution <
>> swift-evolution@swift.org> wrote:
>> >>
>> >> I think having a queue to submit "proposals for eventually", written
>> when the inspiration is there, and having a core team review (say once a
>> month or even once a quarter) of their viability for future Swift
>> directions would be amazingly valuable.
>> >
>> > This is a good point.  I think the concern about a queue is that ideas
>> in it may still be subject to starvation if the queue gets too long.  Ideas
>> also can atrophy in their relevance as the language evolves but proposals
>> stay in the queue.  It then becomes a delicate matter when closing out old
>> proposals. …
>> >
>> > The point about understanding “viable for future Swift directions” is
>> key here.  Viability really comes down to trajectory for the language.
>> None of us are fully omniscient about what is coming in future releases,
>> but we do have a sense of some of the priorities for the language that we
>> need to tackle, balanced with what **kind** of changes are still acceptable
>> to take into the language depending on the kind of disruption they cause
>> for users, the tools we have to mitigate any pain with those changes, etc.
>>
>> This touches on two related concerns I’ve long had about how
>> swift-evolution has worked so far.
>>
>> Concern #1 is that we consider proposals in relative isolation, on their
>> own merits. That’s understandable and wise. Without this focus, we’d never
>> reach conclusions about anything. However, this does tilt the process
>> toward greedy 

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

[Xiaodi Wu via swift-evolution]

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 Void is a tuple or anything.
> Void is Nothing in the programmer’s mind. An instance of Void shouldn’t
> even exist.
>

Sorry, that's not correct. Void is what's called Unit in other languages.
It exists. That is why functions with "no return value" return Void. OTOH,
Never does not exist. This discussion was had in great detail during the
naming debate over Never.


> The proposed meaning of Void is to be a “lack” of arguments. It means that
> each “Void” argument reduces the arity of the function by one, at its exact
> position. Especially look at the canonical signature definition, and the
> proposed rules of reduction.
>

I don't understand why you propose to name this new idea "Void". You're
proposing something that's not even a lack of an argument, but an
anti-argument, like anti-matter! I'm not sure I understand why this is
necessary. It seems to be a very strange workaround for one specific issue
arising from disallowing implicit tuple splatting.


> That proposal, if implemented, would effectively allow `Callback` to
> be called without arguments in the context of swift4.
>
> —
> very short reply expected - vsre.info
> Jérémie Girault
>
> On 12 juin 2017 at 22:06:54, Xiaodi Wu (xiaodi...@gmail.com) wrote:
>
> On Mon, Jun 12, 2017 at 2:56 PM, Jérémie Girault <
> jeremie.gira...@gmail.com> 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: Any) {}`
>> I can afterwards “apply” a tuple to a function named `foo` and therefore
>> execute the function on this tuple.
>> Calling a function syntax was equivalent to put a tuple next to a
>> function name:
>> `foo(42, “hello")` the left-hand is `foo`, the right-hand is `(42,
>> “hello")` is the tuple.
>>
>> The same way if I have
>> `func foo()`
>> `foo()` means calling `foo` with argument `()` and there we have our
>> original `Void`
>>
>> That meaning changed recently due to multiple SE implementations actually.
>>
>
> Tuples-as-arguments never shipped in any version of Swift, and the ability
> to "apply" a tuple like that was removed by SE-0029--the original goal was
> to implement this change in time for Swift 2.2.
>
>
>> The parenthesis around the call don't have a tuple meaning anymore.
>> Therefore it breaks a lot of code relying on this feature of the language,
>> which was quite elegant, but could not handle advanced functions features.
>>
>
> Yes, this is an intentional and approved part of SE-0029. The drawbacks
> were enumerated in that proposal and were deemed acceptable.
>
>
>> @john: Void can happen easily in parameters due to generics, the easiest
>> example that breaks with swift4 is
>> `typealias Callback = (T) -> Void`
>> here
>> `Callback` which is perfectly reasonable introduces Void in the
>> argument list and forces the caller to introduces an empty partenthesis set
>> when invoking:
>> ```
>> let foo: Callback = { }
>> foo(())
>> ```
>>
>
> `Callback = (T) -> Void` refers to a callback that takes exactly one
> argument. Since argument lists are not tuples, it is not possible to invoke
> such a callback with zero arguments, or for that matter with two, three,
> four, or five arguments.
>
> That’s were the proposal shines in my opinion: adapting the meaning of
>> Void to the current context of swift4 gives back the language the elegant
>> syntax it had while preserving the type system
>>
>
> I'm not sure what you mean by this. No change in `Void` can cause a
> function of type (T) -> Void to accept zero arguments: it requires one
> argument of type T.
>
>
> On 12 juin 2017 at 20:04:18, Xiaodi Wu (xiaodi...@gmail.com) 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 motivated by
>> anything to do with argument lists.
>>
>> 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`
>>>
>>
>> It has been suggested to rename Void to Unit. I do believe it’s on the
>> commonly rejected ideas list (and if it’s not, it ought to be).
>>
>> Void, however, seem naturally fitted for the absence of argument.
>>>
>>> Should `func foo(Void)` be different from `func foo()`?
>>>
>>
>> SE-0110 determined that the two should in fact be different.
>>
>> I don’t think so. But different from `func foo(Unit)` ? Yes !
>>>
>>
>> It sounds like your quarrel is with the name of the typealias. I don’t
>> see how that solves any issues 

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

[Daryle Walker via swift-evolution]

> 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 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:
>> 
>> > > (35)
>> 
>> >  
>> >
>>  (11)
> 
>   
> >
>  for the initial post.
> 
>> >  
>> >
>>  (24)
> 
>   
> >
>  for the initial post broken from the first part.

And:

>
>
>

But the Discourse site contains most of these.

— 
Daryle Walker
Mac, Internet, and Video Game Junkie
darylew AT mac DOT com 

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Jérémie Girault via swift-evolution]

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 would
 - preserve the type system in a better way
 - have better source compatibility (in time for swift 4 release, were we
probably won’t see tuple splatting)
 - also keep the elegant original syntax of swift instead of stacking
parenthesis

The impact for code writers would be minimized on time for swift 4 release

As for return values: this proposition does not intend to change the how
return value of Void functions works.

—
very short reply expected - vsre.info
Jérémie Girault

On 12 juin 2017 at 21:45:08, Xiaodi Wu (xiaodi...@gmail.com) wrote:

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 argument list. Likewise `let x = ` will not
compile.


> 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 of Void from () to “something
> else” that is type-compatible with SE-0110 (and splatting in the future).
>

I'm not sure I understand your motivation. Void is just a typealias. If
tomorrow Void meant something else, all functions must still return (), and
there is still no implicit tuple splatting.





> If you want an example of the changes needed to migrate to swift4, just
> look at the 42 files of handling parenthesis PR of RxSwift needed for
> swift4 upgrade : https://github.com/ReactiveX/RxSwift/pull/1282/files
>

Indeed, that's the result of SE-0110; these parentheses are needed because
there is no implicit tuple splatting. They would be required even if `Void`
did not exist in the language at all.


>
> —
> very short reply expected - vsre.info
> Jérémie Girault
>
> On 12 juin 2017 at 21:18:06, Xiaodi Wu (xiaodi...@gmail.com) wrote:
>
> 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 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 response has been that this falls
>> into the ship-has-sailed category of out-of-scope changes.
>>
>> More generally, the recent spate of complaints about regressions to a
>> particular coding style have to do with loss of implicit tuple splatting,
>> the cure for which is a proper implementation of tuple splatting, not
>> poking holes into settled parts of the type system.
>>
>>
>> But you can’t deny that SE-0110 has also caused regressions in the use of
>> Void as generic argument because Void is modelled as the empty tuple.
>>
>
> I'm not sure I understand this statement. Void is a synonym for the empty
> tuple, and that hasn't ever changed, so it can't be the root cause of any
> regressions.
>
>
>> And tuple splatting will not fix those regressions.
>>
>
> How come? If `*` is the splat operator, then it would be legal to call a
> function `foo` that takes no arguments with `foo(*Void)`; if implicit tuple
> splatting returns in fully implemented form, then it would be legal to call
> it once again with `foo(Void)`.
>
> And contrary to what some people might think, this is not an “edge-case”.
>> Most useful monads modelled with generics have good reasons to use Void:
>>
>> *The Result monad:* Result represents the result of an
>> operation with no return value
>> *The Promise monad:* Promise represents the result of an
>> asynchronous operation with no return value
>> *The Observable monad (in functional reactive programming):* 
>> Observable
>> represents a stream of events with no values
>>
>> I use all three monads in my code and I’ve had to modify a lot of code
>> when migrating to Swift 4 beta1 because of Void.
>>
>
> Can you give examples of the modifications needed during migration? From
> here, I can only see that the reason any code needs modification is the
> complete removal of implicit tuple splatting. Nothing has changed about
> Void being a synonym for the empty tuple; even if you rename Void,
> functions will still return () by some other name, and unless there is
> tuple splatting in some form, the migration you performed is inevitable.
>
> On Mon, Jun 12, 2017 at 12:15 John McCall via swift-evolution <
>> swift-evolution@swift.org> wrote:
>>
>>>
>>> On Jun 12, 2017, at 

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

[Jérémie Girault via swift-evolution]

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 improve consistency step by step with simple rules.
Having this clear set of rules would resolve a lot of issues, and having a
tuple-Void type is actually legacy and confusing in swift4 where arguments
have changed a lot at the moment.

—
very short reply expected - vsre.info
Jérémie Girault

On 12 juin 2017 at 22:17:31, Jens Persson (j...@bitcycle.com) 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 an example of one such remaining inconsistency, it's still in
(latest dev snapshot) Swift 4, so this is the behavior of both Swift 3(.2)
and 4:
func foo() -> Void {}
func foo(_: Void) -> Void {} // This is OK
func bar(fn: () -> Void) {}
func bar(fn: (_: Void) -> Void) {} // ERR: Invalid redecl.

I think the least surprising behavior here would be no error, rather than
two.
The current behavior with one error is very surprising.


On Mon, Jun 12, 2017 at 10:09 PM, Xiaodi Wu via swift-evolution <
swift-evolution@swift.org> wrote:

> On Mon, Jun 12, 2017 at 3:04 PM, Jérémie Girault <
> jeremie.gira...@gmail.com> 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.
>>
>
> Yes, it requires compiler support.
>
>
>> This proposal is an alternate solution.
>>
>> My point is that updating Void according to this proposal would
>>  - preserve the type system in a better way
>>  - have better source compatibility (in time for swift 4 release, were we
>> probably won’t see tuple splatting)
>>  - also keep the elegant original syntax of swift instead of stacking
>> parenthesis
>>
>> The impact for code writers would be minimized on time for swift 4 release
>>
>> As for return values: this proposition does not intend to change the how
>> return value of Void functions works.
>>
>> —
>> very short reply expected - vsre.info
>> Jérémie Girault
>>
>> On 12 juin 2017 at 21:45:08, Xiaodi Wu (xiaodi...@gmail.com) wrote:
>>
>> On Mon, Jun 12, 2017 at 2:32 PM, Jérémie Girault > .com> 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 argument list. Likewise `let x = `
>> will not compile.
>>
>>
>>> 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 of Void from () to “something
>>> else” that is type-compatible with SE-0110 (and splatting in the future).
>>>
>>
>> I'm not sure I understand your motivation. Void is just a typealias. If
>> tomorrow Void meant something else, all functions must still return (), and
>> there is still no implicit tuple splatting.
>>
>>
>>
>>
>>
>>> If you want an example of the changes needed to migrate to swift4, just
>>> look at the 42 files of handling parenthesis PR of RxSwift needed for
>>> swift4 upgrade : https://github.com/ReactiveX/RxSwift/pull/1282/files
>>>
>>
>> Indeed, that's the result of SE-0110; these parentheses are needed
>> because there is no implicit tuple splatting. They would be required even
>> if `Void` did not exist in the language at all.
>>
>>
>>>
>>> —
>>> very short reply expected - vsre.info
>>> Jérémie Girault
>>>
>>> On 12 juin 2017 at 21:18:06, Xiaodi Wu (xiaodi...@gmail.com) wrote:
>>>
>>> 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 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 response has been that this
 falls into the ship-has-sailed category of out-of-scope changes.

 More generally, the recent spate of complaints about regressions to a
 particular coding style have to do with loss of implicit tuple splatting,
 the cure for which is a proper implementation of tuple splatting, not
 poking holes into settled parts of the type system.


 But you can’t deny that SE-0110 has also caused regressions in 

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

[Jérémie Girault via swift-evolution]

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 shouldn’t
even exist.

The proposed meaning of Void is to be a “lack” of arguments. It means that
each “Void” argument reduces the arity of the function by one, at its exact
position. Especially look at the canonical signature definition, and the
proposed rules of reduction.

That proposal, if implemented, would effectively allow `Callback` to
be called without arguments in the context of swift4.

—
very short reply expected - vsre.info
Jérémie Girault

On 12 juin 2017 at 22:06:54, Xiaodi Wu (xiaodi...@gmail.com) wrote:

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: Any) {}`
> I can afterwards “apply” a tuple to a function named `foo` and therefore
> execute the function on this tuple.
> Calling a function syntax was equivalent to put a tuple next to a function
> name:
> `foo(42, “hello")` the left-hand is `foo`, the right-hand is `(42,
> “hello")` is the tuple.
>
> The same way if I have
> `func foo()`
> `foo()` means calling `foo` with argument `()` and there we have our
> original `Void`
>
> That meaning changed recently due to multiple SE implementations actually.
>

Tuples-as-arguments never shipped in any version of Swift, and the ability
to "apply" a tuple like that was removed by SE-0029--the original goal was
to implement this change in time for Swift 2.2.


> The parenthesis around the call don't have a tuple meaning anymore.
> Therefore it breaks a lot of code relying on this feature of the language,
> which was quite elegant, but could not handle advanced functions features.
>

Yes, this is an intentional and approved part of SE-0029. The drawbacks
were enumerated in that proposal and were deemed acceptable.


> @john: Void can happen easily in parameters due to generics, the easiest
> example that breaks with swift4 is
> `typealias Callback = (T) -> Void`
> here
> `Callback` which is perfectly reasonable introduces Void in the
> argument list and forces the caller to introduces an empty partenthesis set
> when invoking:
> ```
> let foo: Callback = { }
> foo(())
> ```
>

`Callback = (T) -> Void` refers to a callback that takes exactly one
argument. Since argument lists are not tuples, it is not possible to invoke
such a callback with zero arguments, or for that matter with two, three,
four, or five arguments.

That’s were the proposal shines in my opinion: adapting the meaning of Void
> to the current context of swift4 gives back the language the elegant syntax
> it had while preserving the type system
>

I'm not sure what you mean by this. No change in `Void` can cause a
function of type (T) -> Void to accept zero arguments: it requires one
argument of type T.


On 12 juin 2017 at 20:04:18, Xiaodi Wu (xiaodi...@gmail.com) 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 motivated by
> anything to do with argument lists.
>
> 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`
>>
>
> It has been suggested to rename Void to Unit. I do believe it’s on the
> commonly rejected ideas list (and if it’s not, it ought to be).
>
> Void, however, seem naturally fitted for the absence of argument.
>>
>> Should `func foo(Void)` be different from `func foo()`?
>>
>
> SE-0110 determined that the two should in fact be different.
>
> I don’t think so. But different from `func foo(Unit)` ? Yes !
>>
>
> It sounds like your quarrel is with the name of the typealias. I don’t see
> how that solves any issues with the loss of tuple splatting. Functions will
> still return (), and you foo(()) is not foo().
>
> My point here is that we probably won’t have splatting for swift4.
>>
>>
>> But if we consider the type system as a guide, we can consider 3 simple
>> set of rules and restore almost 100% source compatibility while keeping the
>> improvement of SE-0110
>> - Rules for swift3 tuples-arguments of cardinality zero (Void) in swift 4
>> (this proposition)
>> - Rules for swift3 tuples-arguments of cardinality one in swift 4
>> (proposition to be done)
>> - Rules for swift3 tuples-arguments of cardinality > 1 in swift 4
>> (proposition to be done)
>>
>> —
>> very short reply expected - vsre.info
>> Jérémie Girault
>>
>> On 12 juin 2017 at 19:25:31, Xiaodi Wu (xiaodi...@gmail.com) wrote:
>>
>> Unfortunately, I think this 

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

[Jens Persson via swift-evolution]

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
(latest dev snapshot) Swift 4, so this is the behavior of both Swift 3(.2)
and 4:
func foo() -> Void {}
func foo(_: Void) -> Void {} // This is OK
func bar(fn: () -> Void) {}
func bar(fn: (_: Void) -> Void) {} // ERR: Invalid redecl.

I think the least surprising behavior here would be no error, rather than
two.
The current behavior with one error is very surprising.


On Mon, Jun 12, 2017 at 10:09 PM, Xiaodi Wu via swift-evolution <
swift-evolution@swift.org> wrote:

> On Mon, Jun 12, 2017 at 3:04 PM, Jérémie Girault <
> jeremie.gira...@gmail.com> 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.
>>
>
> Yes, it requires compiler support.
>
>
>> This proposal is an alternate solution.
>>
>> My point is that updating Void according to this proposal would
>>  - preserve the type system in a better way
>>  - have better source compatibility (in time for swift 4 release, were we
>> probably won’t see tuple splatting)
>>  - also keep the elegant original syntax of swift instead of stacking
>> parenthesis
>>
>> The impact for code writers would be minimized on time for swift 4 release
>>
>> As for return values: this proposition does not intend to change the how
>> return value of Void functions works.
>>
>> —
>> very short reply expected - vsre.info
>> Jérémie Girault
>>
>> On 12 juin 2017 at 21:45:08, Xiaodi Wu (xiaodi...@gmail.com) wrote:
>>
>> On Mon, Jun 12, 2017 at 2:32 PM, Jérémie Girault > .com> 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 argument list. Likewise `let x = `
>> will not compile.
>>
>>
>>> 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 of Void from () to “something
>>> else” that is type-compatible with SE-0110 (and splatting in the future).
>>>
>>
>> I'm not sure I understand your motivation. Void is just a typealias. If
>> tomorrow Void meant something else, all functions must still return (), and
>> there is still no implicit tuple splatting.
>>
>>
>>
>>
>>
>>> If you want an example of the changes needed to migrate to swift4, just
>>> look at the 42 files of handling parenthesis PR of RxSwift needed for
>>> swift4 upgrade : https://github.com/ReactiveX/RxSwift/pull/1282/files
>>>
>>
>> Indeed, that's the result of SE-0110; these parentheses are needed
>> because there is no implicit tuple splatting. They would be required even
>> if `Void` did not exist in the language at all.
>>
>>
>>>
>>> —
>>> very short reply expected - vsre.info
>>> Jérémie Girault
>>>
>>> On 12 juin 2017 at 21:18:06, Xiaodi Wu (xiaodi...@gmail.com) wrote:
>>>
>>> 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 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 response has been that this
 falls into the ship-has-sailed category of out-of-scope changes.

 More generally, the recent spate of complaints about regressions to a
 particular coding style have to do with loss of implicit tuple splatting,
 the cure for which is a proper implementation of tuple splatting, not
 poking holes into settled parts of the type system.


 But you can’t deny that SE-0110 has also caused regressions in the use
 of Void as generic argument because Void is modelled as the empty tuple.

>>>
>>> I'm not sure I understand this statement. Void is a synonym for the
>>> empty tuple, and that hasn't ever changed, so it can't be the root cause of
>>> any regressions.
>>>
>>>
 And tuple splatting will not fix those regressions.

>>>
>>> How come? If `*` is the splat operator, then it would be legal to call a
>>> function `foo` that takes no arguments with `foo(*Void)`; if implicit tuple
>>> splatting returns in fully implemented form, then it would be legal to call
>>> it once again with `foo(Void)`.
>>>
>>> And contrary to what some people 

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

[Xiaodi Wu via swift-evolution]

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

Yes, it requires compiler support.


> This proposal is an alternate solution.
>
> My point is that updating Void according to this proposal would
>  - preserve the type system in a better way
>  - have better source compatibility (in time for swift 4 release, were we
> probably won’t see tuple splatting)
>  - also keep the elegant original syntax of swift instead of stacking
> parenthesis
>
> The impact for code writers would be minimized on time for swift 4 release
>
> As for return values: this proposition does not intend to change the how
> return value of Void functions works.
>
> —
> very short reply expected - vsre.info
> Jérémie Girault
>
> On 12 juin 2017 at 21:45:08, Xiaodi Wu (xiaodi...@gmail.com) wrote:
>
> On Mon, Jun 12, 2017 at 2:32 PM, Jérémie Girault  gmail.com> 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 argument list. Likewise `let x = `
> will not compile.
>
>
>> 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 of Void from () to “something
>> else” that is type-compatible with SE-0110 (and splatting in the future).
>>
>
> I'm not sure I understand your motivation. Void is just a typealias. If
> tomorrow Void meant something else, all functions must still return (), and
> there is still no implicit tuple splatting.
>
>
>
>
>
>> If you want an example of the changes needed to migrate to swift4, just
>> look at the 42 files of handling parenthesis PR of RxSwift needed for
>> swift4 upgrade : https://github.com/ReactiveX/RxSwift/pull/1282/files
>>
>
> Indeed, that's the result of SE-0110; these parentheses are needed because
> there is no implicit tuple splatting. They would be required even if `Void`
> did not exist in the language at all.
>
>
>>
>> —
>> very short reply expected - vsre.info
>> Jérémie Girault
>>
>> On 12 juin 2017 at 21:18:06, Xiaodi Wu (xiaodi...@gmail.com) wrote:
>>
>> 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 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 response has been that this falls
>>> into the ship-has-sailed category of out-of-scope changes.
>>>
>>> More generally, the recent spate of complaints about regressions to a
>>> particular coding style have to do with loss of implicit tuple splatting,
>>> the cure for which is a proper implementation of tuple splatting, not
>>> poking holes into settled parts of the type system.
>>>
>>>
>>> But you can’t deny that SE-0110 has also caused regressions in the use
>>> of Void as generic argument because Void is modelled as the empty tuple.
>>>
>>
>> I'm not sure I understand this statement. Void is a synonym for the empty
>> tuple, and that hasn't ever changed, so it can't be the root cause of any
>> regressions.
>>
>>
>>> And tuple splatting will not fix those regressions.
>>>
>>
>> How come? If `*` is the splat operator, then it would be legal to call a
>> function `foo` that takes no arguments with `foo(*Void)`; if implicit tuple
>> splatting returns in fully implemented form, then it would be legal to call
>> it once again with `foo(Void)`.
>>
>> And contrary to what some people might think, this is not an “edge-case”.
>>> Most useful monads modelled with generics have good reasons to use Void:
>>>
>>> *The Result monad:* Result represents the result of an
>>> operation with no return value
>>> *The Promise monad:* Promise represents the result of an
>>> asynchronous operation with no return value
>>> *The Observable monad (in functional reactive programming):* 
>>> Observable
>>> represents a stream of events with no values
>>>
>>> I use all three monads in my code and I’ve had to modify a lot of code
>>> when migrating to Swift 4 beta1 because of Void.
>>>
>>
>> Can you give examples of the modifications needed during migration? From
>> here, I can only see that the reason any code needs modification is the
>> complete removal of implicit tuple splatting. Nothing has changed about
>> Void being a synonym for the empty tuple; even if you rename Void,
>> 

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

[Xiaodi Wu via swift-evolution]

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: Any) {}`
> I can afterwards “apply” a tuple to a function named `foo` and therefore
> execute the function on this tuple.
> Calling a function syntax was equivalent to put a tuple next to a function
> name:
> `foo(42, “hello")` the left-hand is `foo`, the right-hand is `(42,
> “hello")` is the tuple.
>
> The same way if I have
> `func foo()`
> `foo()` means calling `foo` with argument `()` and there we have our
> original `Void`
>
> That meaning changed recently due to multiple SE implementations actually.
>

Tuples-as-arguments never shipped in any version of Swift, and the ability
to "apply" a tuple like that was removed by SE-0029--the original goal was
to implement this change in time for Swift 2.2.


> The parenthesis around the call don't have a tuple meaning anymore.
> Therefore it breaks a lot of code relying on this feature of the language,
> which was quite elegant, but could not handle advanced functions features.
>

Yes, this is an intentional and approved part of SE-0029. The drawbacks
were enumerated in that proposal and were deemed acceptable.


> @john: Void can happen easily in parameters due to generics, the easiest
> example that breaks with swift4 is
> `typealias Callback = (T) -> Void`
> here
> `Callback` which is perfectly reasonable introduces Void in the
> argument list and forces the caller to introduces an empty partenthesis set
> when invoking:
> ```
> let foo: Callback = { }
> foo(())
> ```
>

`Callback = (T) -> Void` refers to a callback that takes exactly one
argument. Since argument lists are not tuples, it is not possible to invoke
such a callback with zero arguments, or for that matter with two, three,
four, or five arguments.

That’s were the proposal shines in my opinion: adapting the meaning of Void
> to the current context of swift4 gives back the language the elegant syntax
> it had while preserving the type system
>

I'm not sure what you mean by this. No change in `Void` can cause a
function of type (T) -> Void to accept zero arguments: it requires one
argument of type T.


On 12 juin 2017 at 20:04:18, Xiaodi Wu (xiaodi...@gmail.com) 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 motivated by
> anything to do with argument lists.
>
> 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`
>>
>
> It has been suggested to rename Void to Unit. I do believe it’s on the
> commonly rejected ideas list (and if it’s not, it ought to be).
>
> Void, however, seem naturally fitted for the absence of argument.
>>
>> Should `func foo(Void)` be different from `func foo()`?
>>
>
> SE-0110 determined that the two should in fact be different.
>
> I don’t think so. But different from `func foo(Unit)` ? Yes !
>>
>
> It sounds like your quarrel is with the name of the typealias. I don’t see
> how that solves any issues with the loss of tuple splatting. Functions will
> still return (), and you foo(()) is not foo().
>
> My point here is that we probably won’t have splatting for swift4.
>>
>>
>> But if we consider the type system as a guide, we can consider 3 simple
>> set of rules and restore almost 100% source compatibility while keeping the
>> improvement of SE-0110
>> - Rules for swift3 tuples-arguments of cardinality zero (Void) in swift 4
>> (this proposition)
>> - Rules for swift3 tuples-arguments of cardinality one in swift 4
>> (proposition to be done)
>> - Rules for swift3 tuples-arguments of cardinality > 1 in swift 4
>> (proposition to be done)
>>
>> —
>> very short reply expected - vsre.info
>> Jérémie Girault
>>
>> On 12 juin 2017 at 19:25:31, Xiaodi Wu (xiaodi...@gmail.com) 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.
>>
>>
>>
>> If I recall, a number of conversations have been raised about Void being
>> a typealias of (), and the definitive response has been that this falls
>> into the ship-has-sailed category of out-of-scope changes.
>>
>> More generally, the recent spate of complaints about regressions to a
>> particular coding style have to do with loss of implicit tuple splatting,
>> the cure for which is a proper implementation of tuple splatting, not
>> poking holes into settled parts of the type system.
>>
>>
>>
>>
>> On Mon, Jun 12, 2017 at 12:15 John McCall via swift-evolution <
>> swift-evolution@swift.org> wrote:
>>
>>>
>>> On Jun 12, 2017, at 4:48 AM, 

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

[Paul Cantrell via swift-evolution]

> 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 inspiration is there, and having a core team review (say once a month or 
>> even once a quarter) of their viability for future Swift directions would be 
>> amazingly valuable.
> 
> This is a good point.  I think the concern about a queue is that ideas in it 
> may still be subject to starvation if the queue gets too long.  Ideas also 
> can atrophy in their relevance as the language evolves but proposals stay in 
> the queue.  It then becomes a delicate matter when closing out old proposals. 
> …
> 
> The point about understanding “viable for future Swift directions” is key 
> here.  Viability really comes down to trajectory for the language.  None of 
> us are fully omniscient about what is coming in future releases, but we do 
> have a sense of some of the priorities for the language that we need to 
> tackle, balanced with what **kind** of changes are still acceptable to take 
> into the language depending on the kind of disruption they cause for users, 
> the tools we have to mitigate any pain with those changes, etc.

This touches on two related concerns I’ve long had about how swift-evolution 
has worked so far.

Concern #1 is that we consider proposals in relative isolation, on their own 
merits. That’s understandable and wise. Without this focus, we’d never reach 
conclusions about anything. However, this does tilt the process toward greedy 
optimization as we traverse the language space. I worry that there’s not enough 
attention to the big picture.

Concern #2 is that it’s hard to know what to do with a proposal when the ideal 
answer is “we need to see how it plays out in practice and then decide whether 
to accept it.” Theoretical discussion untempered by practical prototyping is a 
great way for a group to talk itself into a bad idea. (This will especially be 
a problem with future work to build out generics & existentials.)

Swift is already a very featureful language, and not always in a good way. A 
new feature that makes good sense in the context of a particular problem may 
make less sense when we consider the totality of its effect on the programmer 
model: its mental burden, its unforeseen interactions, its surprising pitfalls. 
How often do we reviewers give only a perfunctory answer to “Does this proposal 
fit well with the feel and direction of Swift?” How often _can_ we give 
anything but?

The net result is that IMO we tend to over-favor narrow solutions that solve 
very specific problems, and under-favor simpler, more general features that are 
good-enough solutions to _many_ problems at once — not as nice for any _one_ of 
those problems in isolation, but nicer to work with taken as a whole.

The Great Access Modifiers Wars and the recent fussing of SE-110 fallout are 
good examples of these problems.

The work on ABI stability is perhaps a good model for non-greedy planning 
guided by a coherent big picture.

Do these musings make sense? I don’t have any clear answers, but hope the 
observations are helpful.

Cheers,

Paul

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Jens Persson via swift-evolution]

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 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` takes one argument of type `()` but `bar` takes zero arguments.
> The expectation that you can call a function with a single tuple of some
> arity instead of the declared number of arguments is fulfilled by implicit
> tuple splatting, which is intentionally removed. This has nothing to do
> with what `Void` means; the single argument could be `Int` or `String` or
> `Data`.
>
>
> On Mon, Jun 12, 2017 at 9:44 PM, Xiaodi Wu via swift-evolution <
>> swift-evolution@swift.org> wrote:
>>
>>> On Mon, Jun 12, 2017 at 2:32 PM, Jérémie Girault <
>>> jeremie.gira...@gmail.com> 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 argument list. Likewise `let x = `
>>> will not compile.
>>>
>>>
 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 of Void from () to “something
 else” that is type-compatible with SE-0110 (and splatting in the future).

>>>
>>> I'm not sure I understand your motivation. Void is just a typealias. If
>>> tomorrow Void meant something else, all functions must still return (), and
>>> there is still no implicit tuple splatting.
>>>
>>>
 If you want an example of the changes needed to migrate to swift4, just
 look at the 42 files of handling parenthesis PR of RxSwift needed for
 swift4 upgrade : https://github.com/ReactiveX/RxSwift/pull/1282/files

>>>
>>> Indeed, that's the result of SE-0110; these parentheses are needed
>>> because there is no implicit tuple splatting. They would be required even
>>> if `Void` did not exist in the language at all.
>>>
>>>

 —
 very short reply expected - vsre.info
 Jérémie Girault

 On 12 juin 2017 at 21:18:06, Xiaodi Wu (xiaodi...@gmail.com) wrote:

 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 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 response has been that this
> falls into the ship-has-sailed category of out-of-scope changes.
>
> More generally, the recent spate of complaints about regressions to a
> particular coding style have to do with loss of implicit tuple splatting,
> the cure for which is a proper implementation of tuple splatting, not
> poking holes into settled parts of the type system.
>
>
> But you can’t deny that SE-0110 has also caused regressions in the use
> of Void as generic argument because Void is modelled as the empty tuple.
>

 I'm not sure I understand this statement. Void is a synonym for the
 empty tuple, and that hasn't ever changed, so it can't be the root cause of
 any regressions.


> And tuple splatting will not fix those regressions.
>

 How come? If `*` is the splat operator, then it would be legal to call
 a function `foo` that takes no arguments with `foo(*Void)`; if implicit
 tuple splatting returns in fully implemented form, then it would be legal
 to call it once again with `foo(Void)`.

 And contrary to what some people might think, this is not an
> “edge-case”. Most useful monads modelled with generics have good reasons 
> to
> use Void:
>
> *The Result monad:* Result represents the result of an
> operation with no return value
> *The Promise monad:* Promise represents the result of an
> asynchronous operation with no return value
> *The Observable monad (in functional reactive programming):*
> Observable represents a stream of events with no values
>
> I use all three monads in my code and I’ve had to modify a lot of code
> when migrating to Swift 4 beta1 because of Void.
>

 Can you give examples of the modifications needed during migration?
 From here, I can only see that the reason any code needs 

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

[Xiaodi Wu via swift-evolution]

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` takes one argument of type `()` but `bar` takes zero arguments.
The expectation that you can call a function with a single tuple of some
arity instead of the declared number of arguments is fulfilled by implicit
tuple splatting, which is intentionally removed. This has nothing to do
with what `Void` means; the single argument could be `Int` or `String` or
`Data`.


On Mon, Jun 12, 2017 at 9:44 PM, Xiaodi Wu via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>> On Mon, Jun 12, 2017 at 2:32 PM, Jérémie Girault <
>> jeremie.gira...@gmail.com> 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 argument list. Likewise `let x = `
>> will not compile.
>>
>>
>>> 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 of Void from () to “something
>>> else” that is type-compatible with SE-0110 (and splatting in the future).
>>>
>>
>> I'm not sure I understand your motivation. Void is just a typealias. If
>> tomorrow Void meant something else, all functions must still return (), and
>> there is still no implicit tuple splatting.
>>
>>
>>> If you want an example of the changes needed to migrate to swift4, just
>>> look at the 42 files of handling parenthesis PR of RxSwift needed for
>>> swift4 upgrade : https://github.com/ReactiveX/RxSwift/pull/1282/files
>>>
>>
>> Indeed, that's the result of SE-0110; these parentheses are needed
>> because there is no implicit tuple splatting. They would be required even
>> if `Void` did not exist in the language at all.
>>
>>
>>>
>>> —
>>> very short reply expected - vsre.info
>>> Jérémie Girault
>>>
>>> On 12 juin 2017 at 21:18:06, Xiaodi Wu (xiaodi...@gmail.com) wrote:
>>>
>>> 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 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 response has been that this
 falls into the ship-has-sailed category of out-of-scope changes.

 More generally, the recent spate of complaints about regressions to a
 particular coding style have to do with loss of implicit tuple splatting,
 the cure for which is a proper implementation of tuple splatting, not
 poking holes into settled parts of the type system.


 But you can’t deny that SE-0110 has also caused regressions in the use
 of Void as generic argument because Void is modelled as the empty tuple.

>>>
>>> I'm not sure I understand this statement. Void is a synonym for the
>>> empty tuple, and that hasn't ever changed, so it can't be the root cause of
>>> any regressions.
>>>
>>>
 And tuple splatting will not fix those regressions.

>>>
>>> How come? If `*` is the splat operator, then it would be legal to call a
>>> function `foo` that takes no arguments with `foo(*Void)`; if implicit tuple
>>> splatting returns in fully implemented form, then it would be legal to call
>>> it once again with `foo(Void)`.
>>>
>>> And contrary to what some people might think, this is not an
 “edge-case”. Most useful monads modelled with generics have good reasons to
 use Void:

 *The Result monad:* Result represents the result of an
 operation with no return value
 *The Promise monad:* Promise represents the result of an
 asynchronous operation with no return value
 *The Observable monad (in functional reactive programming):*
 Observable represents a stream of events with no values

 I use all three monads in my code and I’ve had to modify a lot of code
 when migrating to Swift 4 beta1 because of Void.

>>>
>>> Can you give examples of the modifications needed during migration? From
>>> here, I can only see that the reason any code needs modification is the
>>> complete removal of implicit tuple splatting. Nothing has changed about
>>> Void being a synonym for the empty tuple; even if you rename Void,
>>> functions will still return () by some other name, and unless there is
>>> tuple splatting in some form, the migration you performed is inevitable.
>>>
>>> On 

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

[Daryle Walker via swift-evolution]

> 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. 
>> 
>> https://github.com/apple/swift-evolution/pull/353
> 
> See also "[Pitch] #warning" in the mailing lists:
> 
>  (35)
> 
> 
>  (11)


 for the initial post.

> 
>  (24)

>
 for the initial post broken from the first part.

— 
Daryle Walker
Mac, Internet, and Video Game Junkie
darylew AT mac DOT com 

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Jérémie Girault via swift-evolution]

@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 function on this tuple.
Calling a function syntax was equivalent to put a tuple next to a function
name:
`foo(42, “hello")` the left-hand is `foo`, the right-hand is `(42,
“hello")` is the tuple.

The same way if I have
`func foo()`
`foo()` means calling `foo` with argument `()` and there we have our
original `Void`

That meaning changed recently due to multiple SE implementations actually.
The parenthesis around the call don't have a tuple meaning anymore.
Therefore it breaks a lot of code relying on this feature of the language,
which was quite elegant, but could not handle advanced functions features.

@john: Void can happen easily in parameters due to generics, the easiest
example that breaks with swift4 is
`typealias Callback = (T) -> Void`
here
`Callback` which is perfectly reasonable introduces Void in the
argument list and forces the caller to introduces an empty partenthesis set
when invoking:
```
let foo: Callback = { }
foo(())
```

That’s were the proposal shines in my opinion: adapting the meaning of Void
to the current context of swift4 gives back the language the elegant syntax
it had while preserving the type system

—
very short reply expected - vsre.info
Jérémie Girault

On 12 juin 2017 at 20:04:18, Xiaodi Wu (xiaodi...@gmail.com) 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 motivated by
anything to do with argument lists.

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

It has been suggested to rename Void to Unit. I do believe it’s on the
commonly rejected ideas list (and if it’s not, it ought to be).

Void, however, seem naturally fitted for the absence of argument.
>
> Should `func foo(Void)` be different from `func foo()`?
>

SE-0110 determined that the two should in fact be different.

I don’t think so. But different from `func foo(Unit)` ? Yes !
>

It sounds like your quarrel is with the name of the typealias. I don’t see
how that solves any issues with the loss of tuple splatting. Functions will
still return (), and you foo(()) is not foo().

My point here is that we probably won’t have splatting for swift4.
>
>
> But if we consider the type system as a guide, we can consider 3 simple
> set of rules and restore almost 100% source compatibility while keeping the
> improvement of SE-0110
> - Rules for swift3 tuples-arguments of cardinality zero (Void) in swift 4
> (this proposition)
> - Rules for swift3 tuples-arguments of cardinality one in swift 4
> (proposition to be done)
> - Rules for swift3 tuples-arguments of cardinality > 1 in swift 4
> (proposition to be done)
>
> —
> very short reply expected - vsre.info
> Jérémie Girault
>
> On 12 juin 2017 at 19:25:31, Xiaodi Wu (xiaodi...@gmail.com) 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.
>
>
>
> If I recall, a number of conversations have been raised about Void being a
> typealias of (), and the definitive response has been that this falls into
> the ship-has-sailed category of out-of-scope changes.
>
> More generally, the recent spate of complaints about regressions to a
> particular coding style have to do with loss of implicit tuple splatting,
> the cure for which is a proper implementation of tuple splatting, not
> poking holes into settled parts of the type system.
>
>
>
>
> On Mon, Jun 12, 2017 at 12:15 John McCall via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>>
>> On Jun 12, 2017, at 4:48 AM, Jérémie Girault via swift-evolution <
>> swift-evolution@swift.org> 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 (which make
>> sense), I wanted create a few proposal which would improve these recent
>> changes with a few simple rules.
>>
>> My propositions are based on the recent decisions and in the continuation
>> of SE-0110. The first one is about Void.
>> Void is historically defined as the type of the empty tuple. The reason
>> of this is that arguments were initially considered as tuple.
>>
>>
>> The dominant consideration here was always return types, not parameters.
>> I'm not sure there was ever much point in writing Void in a parameter list,
>> but whatever reasons there were surely vanished with 

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

[Tuur Anton via swift-evolution]

> 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 source" is providing all these 
users with a false sense of security.

Imagine if this was possible: (1) Download an "open source" app on your iPhone 
from the App Store. (2) Connect your iPhone to your Mac and extract the app 
binary to your Mac. (3) Compile the app's source code from GitHub. (4) Compare 
the SHA-256 hashes of both binaries and verify they're the same.

Wouldn't this be cool? I think so, because any user could ask a tech-savvy 
friend to verify the binary. The app's reputation would go down the tubes if 
the SHA-256 hashes would stop matching.

>From this perspective, I think bitcode, app thinning, etc. are taking us 
>backwards. I hope those never become mandatory. Developers should have the 
>option to make steps (1)-(4) possible.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Xiaodi Wu via swift-evolution]

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 argument list. Likewise `let x = ` will not
compile.


> 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 of Void from () to “something
> else” that is type-compatible with SE-0110 (and splatting in the future).
>

I'm not sure I understand your motivation. Void is just a typealias. If
tomorrow Void meant something else, all functions must still return (), and
there is still no implicit tuple splatting.


> If you want an example of the changes needed to migrate to swift4, just
> look at the 42 files of handling parenthesis PR of RxSwift needed for
> swift4 upgrade : https://github.com/ReactiveX/RxSwift/pull/1282/files
>

Indeed, that's the result of SE-0110; these parentheses are needed because
there is no implicit tuple splatting. They would be required even if `Void`
did not exist in the language at all.


>
> —
> very short reply expected - vsre.info
> Jérémie Girault
>
> On 12 juin 2017 at 21:18:06, Xiaodi Wu (xiaodi...@gmail.com) wrote:
>
> 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 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 response has been that this falls
>> into the ship-has-sailed category of out-of-scope changes.
>>
>> More generally, the recent spate of complaints about regressions to a
>> particular coding style have to do with loss of implicit tuple splatting,
>> the cure for which is a proper implementation of tuple splatting, not
>> poking holes into settled parts of the type system.
>>
>>
>> But you can’t deny that SE-0110 has also caused regressions in the use of
>> Void as generic argument because Void is modelled as the empty tuple.
>>
>
> I'm not sure I understand this statement. Void is a synonym for the empty
> tuple, and that hasn't ever changed, so it can't be the root cause of any
> regressions.
>
>
>> And tuple splatting will not fix those regressions.
>>
>
> How come? If `*` is the splat operator, then it would be legal to call a
> function `foo` that takes no arguments with `foo(*Void)`; if implicit tuple
> splatting returns in fully implemented form, then it would be legal to call
> it once again with `foo(Void)`.
>
> And contrary to what some people might think, this is not an “edge-case”.
>> Most useful monads modelled with generics have good reasons to use Void:
>>
>> *The Result monad:* Result represents the result of an
>> operation with no return value
>> *The Promise monad:* Promise represents the result of an
>> asynchronous operation with no return value
>> *The Observable monad (in functional reactive programming):*
>> Observable represents a stream of events with no values
>>
>> I use all three monads in my code and I’ve had to modify a lot of code
>> when migrating to Swift 4 beta1 because of Void.
>>
>
> Can you give examples of the modifications needed during migration? From
> here, I can only see that the reason any code needs modification is the
> complete removal of implicit tuple splatting. Nothing has changed about
> Void being a synonym for the empty tuple; even if you rename Void,
> functions will still return () by some other name, and unless there is
> tuple splatting in some form, the migration you performed is inevitable.
>
> On Mon, Jun 12, 2017 at 12:15 John McCall via swift-evolution <
>> swift-evolution@swift.org> wrote:
>>
>>>
>>> On Jun 12, 2017, at 4:48 AM, Jérémie Girault via swift-evolution <
>>> swift-evolution@swift.org> 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 (which
>>> make sense), I wanted create a few proposal which would improve these
>>> recent changes with a few simple rules.
>>>
>>> My propositions are based on the recent decisions and in the
>>> continuation of SE-0110. The first one is about Void.
>>> Void is historically defined as the type of the empty tuple. The reason
>>> of this is that arguments were initially considered as tuple.
>>>
>>>
>>> The dominant consideration here was always return types, not
>>> parameters.  I'm not sure there was ever much 

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

[Jens Persson via swift-evolution]

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 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 system?
>
>
> That's correct.  There's a lot of special structure to function calls —
> labels, overloading, default arguments, variadics, inout arguments,
> (eventually) borrowed arguments — that we do not want to introduce into the
> first-class tuple system, or at least not in the exact same way.  In some
> cases, like overloading or defaulted and inout arguments, it cannot be done
> without a major and unwanted model shift.  In other cases, like variadics,
> it could theoretically be done but would complicate the type system in ways
> we are trying to avoid.
>
> Regardless, the existence of any call-specific structure at all implies
> that generic value forwarding cannot always be sufficient to do generic
> argument forwarding.  Maybe that's an argument for not having any
> call-specific structure, but we do have that and it's not going away.
>
> John.
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Jérémie Girault via swift-evolution]

@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 of Void from () to “something else”
that is type-compatible with SE-0110 (and splatting in the future).

If you want an example of the changes needed to migrate to swift4, just
look at the 42 files of handling parenthesis PR of RxSwift needed for
swift4 upgrade : https://github.com/ReactiveX/RxSwift/pull/1282/files

—
very short reply expected - vsre.info
Jérémie Girault

On 12 juin 2017 at 21:18:06, Xiaodi Wu (xiaodi...@gmail.com) wrote:

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 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 response has been that this falls into
> the ship-has-sailed category of out-of-scope changes.
>
> More generally, the recent spate of complaints about regressions to a
> particular coding style have to do with loss of implicit tuple splatting,
> the cure for which is a proper implementation of tuple splatting, not
> poking holes into settled parts of the type system.
>
>
> But you can’t deny that SE-0110 has also caused regressions in the use of
> Void as generic argument because Void is modelled as the empty tuple.
>

I'm not sure I understand this statement. Void is a synonym for the empty
tuple, and that hasn't ever changed, so it can't be the root cause of any
regressions.


> And tuple splatting will not fix those regressions.
>

How come? If `*` is the splat operator, then it would be legal to call a
function `foo` that takes no arguments with `foo(*Void)`; if implicit tuple
splatting returns in fully implemented form, then it would be legal to call
it once again with `foo(Void)`.

And contrary to what some people might think, this is not an “edge-case”.
> Most useful monads modelled with generics have good reasons to use Void:
>
> *The Result monad:* Result represents the result of an operation
> with no return value
> *The Promise monad:* Promise represents the result of an
> asynchronous operation with no return value
> *The Observable monad (in functional reactive programming):*
> Observable represents a stream of events with no values
>
> I use all three monads in my code and I’ve had to modify a lot of code
> when migrating to Swift 4 beta1 because of Void.
>

Can you give examples of the modifications needed during migration? From
here, I can only see that the reason any code needs modification is the
complete removal of implicit tuple splatting. Nothing has changed about
Void being a synonym for the empty tuple; even if you rename Void,
functions will still return () by some other name, and unless there is
tuple splatting in some form, the migration you performed is inevitable.

On Mon, Jun 12, 2017 at 12:15 John McCall via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>>
>> On Jun 12, 2017, at 4:48 AM, Jérémie Girault via swift-evolution <
>> swift-evolution@swift.org> 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 (which make
>> sense), I wanted create a few proposal which would improve these recent
>> changes with a few simple rules.
>>
>> My propositions are based on the recent decisions and in the continuation
>> of SE-0110. The first one is about Void.
>> Void is historically defined as the type of the empty tuple. The reason
>> of this is that arguments were initially considered as tuple.
>>
>>
>> The dominant consideration here was always return types, not parameters.
>> I'm not sure there was ever much point in writing Void in a parameter list,
>> but whatever reasons there were surely vanished with SE-0066.
>>
>> Note that 'void' in C was originally exclusively a return type.  ANSI
>> gave it a new purpose it with void*, but the meaning is totally unrelated.
>>
>> John.
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
>
___
swift-evolution mailing list
swift-evolution@swift.org

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

[John McCall via swift-evolution]

> 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 understand what you mean. Do you mean that you really don't 
> want these features to require changes to the type system?

That's correct.  There's a lot of special structure to function calls — labels, 
overloading, default arguments, variadics, inout arguments, (eventually) 
borrowed arguments — that we do not want to introduce into the first-class 
tuple system, or at least not in the exact same way.  In some cases, like 
overloading or defaulted and inout arguments, it cannot be done without a major 
and unwanted model shift.  In other cases, like variadics, it could 
theoretically be done but would complicate the type system in ways we are 
trying to avoid.

Regardless, the existence of any call-specific structure at all implies that 
generic value forwarding cannot always be sufficient to do generic argument 
forwarding.  Maybe that's an argument for not having any call-specific 
structure, but we do have that and it's not going away.

John.___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Xiaodi Wu via swift-evolution]

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 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 response has been that this falls into
> the ship-has-sailed category of out-of-scope changes.
>
> More generally, the recent spate of complaints about regressions to a
> particular coding style have to do with loss of implicit tuple splatting,
> the cure for which is a proper implementation of tuple splatting, not
> poking holes into settled parts of the type system.
>
>
> But you can’t deny that SE-0110 has also caused regressions in the use of
> Void as generic argument because Void is modelled as the empty tuple.
>

I'm not sure I understand this statement. Void is a synonym for the empty
tuple, and that hasn't ever changed, so it can't be the root cause of any
regressions.


> And tuple splatting will not fix those regressions.
>

How come? If `*` is the splat operator, then it would be legal to call a
function `foo` that takes no arguments with `foo(*Void)`; if implicit tuple
splatting returns in fully implemented form, then it would be legal to call
it once again with `foo(Void)`.

And contrary to what some people might think, this is not an “edge-case”.
> Most useful monads modelled with generics have good reasons to use Void:
>
> *The Result monad:* Result represents the result of an operation
> with no return value
> *The Promise monad:* Promise represents the result of an
> asynchronous operation with no return value
> *The Observable monad (in functional reactive programming):*
> Observable represents a stream of events with no values
>
> I use all three monads in my code and I’ve had to modify a lot of code
> when migrating to Swift 4 beta1 because of Void.
>

Can you give examples of the modifications needed during migration? From
here, I can only see that the reason any code needs modification is the
complete removal of implicit tuple splatting. Nothing has changed about
Void being a synonym for the empty tuple; even if you rename Void,
functions will still return () by some other name, and unless there is
tuple splatting in some form, the migration you performed is inevitable.

On Mon, Jun 12, 2017 at 12:15 John McCall via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>>
>> On Jun 12, 2017, at 4:48 AM, Jérémie Girault via swift-evolution <
>> swift-evolution@swift.org> 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 (which make
>> sense), I wanted create a few proposal which would improve these recent
>> changes with a few simple rules.
>>
>> My propositions are based on the recent decisions and in the continuation
>> of SE-0110. The first one is about Void.
>> Void is historically defined as the type of the empty tuple. The reason
>> of this is that arguments were initially considered as tuple.
>>
>>
>> The dominant consideration here was always return types, not parameters.
>> I'm not sure there was ever much point in writing Void in a parameter list,
>> but whatever reasons there were surely vanished with SE-0066.
>>
>> Note that 'void' in C was originally exclusively a return type.  ANSI
>> gave it a new purpose it with void*, but the meaning is totally unrelated.
>>
>> John.
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Jens Persson via swift-evolution]

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

My main problem/missing feature with function types in Swift 4 is not being
able to express a generic function type as A -> B, instead I would have to
do this:
(A) -> B
(A, B) -> C
(A, B, C) -> D
...
...
Ie it is impossible to fully express something that I normally see as just
A -> B.

Another example could be describing any two function types that are
composable:
A -> B and B -> C

This also becomes impossible using Swift 4 function types:
(A) -> B and (B) -> C
(A, B) -> C and (C) -> D
(A) -> (B, C) and (B, C) -> D
...
...
... etc, etc, ...

One solution that is already possible is of course to only use functions
with one (tuple) argument in these and similar scenarios. But that's still
a bit awkward.

/Jens
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Anders Ha via swift-evolution]

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` are better as 
they statically guarantee that no instance would ever exist.



Regards,
Anders

> On 13 Jun 2017, at 3:05 AM, David Hart via swift-evolution 
>  wrote:
> 
>> 
>> 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.
>> 
>> If I recall, a number of conversations have been raised about Void being a 
>> typealias of (), and the definitive response has been that this falls into 
>> the ship-has-sailed category of out-of-scope changes.
>> 
>> More generally, the recent spate of complaints about regressions to a 
>> particular coding style have to do with loss of implicit tuple splatting, 
>> the cure for which is a proper implementation of tuple splatting, not poking 
>> holes into settled parts of the type system.
> 
> But you can’t deny that SE-0110 has also caused regressions in the use of 
> Void as generic argument because Void is modelled as the empty tuple. And 
> tuple splatting will not fix those regressions.
> 
> And contrary to what some people might think, this is not an “edge-case”. 
> Most useful monads modelled with generics have good reasons to use Void:
> 
> The Result monad: Result represents the result of an operation with 
> no return value
> The Promise monad: Promise represents the result of an asynchronous 
> operation with no return value
> The Observable monad (in functional reactive programming): 
> Observable represents a stream of events with no values
> 
> I use all three monads in my code and I’ve had to modify a lot of code when 
> migrating to Swift 4 beta1 because of Void.
> 
> David.
> 
>> On Mon, Jun 12, 2017 at 12:15 John McCall via swift-evolution 
>>  wrote:
>> 
>>> 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 could be improved. Instead of fighting these propositions (which make 
>>> sense), I wanted create a few proposal which would improve these recent 
>>> changes with a few simple rules.
>>> 
>>> My propositions are based on the recent decisions and in the continuation 
>>> of SE-0110. The first one is about Void.
>>> Void is historically defined as the type of the empty tuple. The reason of 
>>> this is that arguments were initially considered as tuple.
>> 
>> The dominant consideration here was always return types, not parameters.  
>> I'm not sure there was ever much point in writing Void in a parameter list, 
>> but whatever reasons there were surely vanished with SE-0066.
>> 
>> Note that 'void' in C was originally exclusively a return type.  ANSI gave 
>> it a new purpose it with void*, but the meaning is totally unrelated.
>> 
>> John.
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[David Hart via swift-evolution]

> 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.
> 
> If I recall, a number of conversations have been raised about Void being a 
> typealias of (), and the definitive response has been that this falls into 
> the ship-has-sailed category of out-of-scope changes.
> 
> More generally, the recent spate of complaints about regressions to a 
> particular coding style have to do with loss of implicit tuple splatting, the 
> cure for which is a proper implementation of tuple splatting, not poking 
> holes into settled parts of the type system.

But you can’t deny that SE-0110 has also caused regressions in the use of Void 
as generic argument because Void is modelled as the empty tuple. And tuple 
splatting will not fix those regressions.

And contrary to what some people might think, this is not an “edge-case”. Most 
useful monads modelled with generics have good reasons to use Void:

The Result monad: Result represents the result of an operation with no 
return value
The Promise monad: Promise represents the result of an asynchronous 
operation with no return value
The Observable monad (in functional reactive programming): Observable 
represents a stream of events with no values

I use all three monads in my code and I’ve had to modify a lot of code when 
migrating to Swift 4 beta1 because of Void.

David.

> On Mon, Jun 12, 2017 at 12:15 John McCall via swift-evolution 
> > wrote:
> 
>> 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 could be improved. Instead of fighting these propositions (which make 
>> sense), I wanted create a few proposal which would improve these recent 
>> changes with a few simple rules.
>> 
>> My propositions are based on the recent decisions and in the continuation of 
>> SE-0110. The first one is about Void.
>> Void is historically defined as the type of the empty tuple. The reason of 
>> this is that arguments were initially considered as tuple.
> 
> The dominant consideration here was always return types, not parameters.  I'm 
> not sure there was ever much point in writing Void in a parameter list, but 
> whatever reasons there were surely vanished with SE-0066.
> 
> Note that 'void' in C was originally exclusively a return type.  ANSI gave it 
> a new purpose it with void*, but the meaning is totally unrelated.
> 
> John.
> ___
> swift-evolution mailing list
> swift-evolution@swift.org 
> https://lists.swift.org/mailman/listinfo/swift-evolution 
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[John McCall via swift-evolution]

> 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 
> could affect e.g. name mangling or the type metadata hierarchy, then that 
> would be ABI-affecting. For example, proposing that all functions must only 
> take a single tuple rather than multiple arguments could affect the runtime 
> representation of function types. But even then, there are approaches to 
> mitigate this, so such a proposal would likely present an ABI migration 
> strategy.
> 
> 
> I think I understand (and understood), in very basic terms, the difference 
> between source stability and binary stability, and I was thinking something 
> like this:
> 
> What if there is a chance that the "uniform tuple concept" could be 
> redesigned and reimplemented after all, handling inout, variadic, etc in some 
> way, allowing named single element tuples, allowing A -> B to represent 
> (possibly only "pure") functions with _any_number_ of args, and not just one, 
> as in Swift 4, and so on.

We really do want to tie most of these features specifically to function calls.

John.

> 
> I'm still not entirely sure if this is ABI-affecting or not. But anyway, 
> thank you for your calming words!
> 
> (I will try to not worry that (almost) everything parentheses-related in 
> Swift will forever be stuck in a local optimum, because its current state and 
> the history that lead to it is so confusing that it will stop all attempts at 
> a substantially better solution and only allow minor changes/polishing.)
> 
> /Jens
> 
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[David Hart via swift-evolution]

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 
> > 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`
>> 
>> Void, however, seem naturally fitted for the absence of argument.
>> 
>> Should `func foo(Void)` be different from `func foo()`? I don’t think so. 
>> But different from `func foo(Unit)` ? Yes !
>> 
> To me, "Unit" is used like "a unit of length", "a unit of time", etc. I've 
> not come across it being used as analog for something like the empty tuple.
> 
> - Dave Sweeris
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Jens Persson via swift-evolution]

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 functions must only
> take a single tuple rather than multiple arguments could affect the runtime
> representation of function types. But even then, there are approaches to
> mitigate this, so such a proposal would likely present an ABI migration
> strategy.
>
>
I think I understand (and understood), in very basic terms, the difference
between source stability and binary stability, and I was thinking something
like this:

What if there is a chance that the "uniform tuple concept" could be
redesigned and reimplemented after all, handling inout, variadic, etc in
some way, allowing named single element tuples, allowing A -> B to
represent (possibly only "pure") functions with _any_number_ of args, and
not just one, as in Swift 4, and so on.

I'm still not entirely sure if this is ABI-affecting or not. But anyway,
thank you for your calming words!

(I will try to not worry that (almost) everything parentheses-related in
Swift will forever be stuck in a local optimum, because its current state
and the history that lead to it is so confusing that it will stop all
attempts at a substantially better solution and only allow minor
changes/polishing.)

/Jens
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Xiaodi Wu via swift-evolution]

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 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 via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>
> On Jun 12, 2017, at 10:44, Jérémie Girault via swift-evolution <
> swift-evolution@swift.org> 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`
>
> Void, however, seem naturally fitted for the absence of argument.
>
> Should `func foo(Void)` be different from `func foo()`? I don’t think so.
> But different from `func foo(Unit)` ? Yes !
>
> To me, "Unit" is used like "a unit of length", "a unit of time", etc. I've
> not come across it being used as analog for something like the empty tuple.
>
> - Dave Sweeris
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Xiaodi Wu via swift-evolution]

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 consider the empty tuple to be an argument, then the type for the
> type of empty tuple should be `Unit`
>

It has been suggested to rename Void to Unit. I do believe it’s on the
commonly rejected ideas list (and if it’s not, it ought to be).

Void, however, seem naturally fitted for the absence of argument.
>
> Should `func foo(Void)` be different from `func foo()`?
>

SE-0110 determined that the two should in fact be different.

I don’t think so. But different from `func foo(Unit)` ? Yes !
>

It sounds like your quarrel is with the name of the typealias. I don’t see
how that solves any issues with the loss of tuple splatting. Functions will
still return (), and you foo(()) is not foo().

My point here is that we probably won’t have splatting for swift4.
>
>
> But if we consider the type system as a guide, we can consider 3 simple
> set of rules and restore almost 100% source compatibility while keeping the
> improvement of SE-0110
> - Rules for swift3 tuples-arguments of cardinality zero (Void) in swift 4
> (this proposition)
> - Rules for swift3 tuples-arguments of cardinality one in swift 4
> (proposition to be done)
> - Rules for swift3 tuples-arguments of cardinality > 1 in swift 4
> (proposition to be done)
>
> —
> very short reply expected - vsre.info
> Jérémie Girault
>
> On 12 juin 2017 at 19:25:31, Xiaodi Wu (xiaodi...@gmail.com) 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.
>
>
>
> If I recall, a number of conversations have been raised about Void being a
> typealias of (), and the definitive response has been that this falls into
> the ship-has-sailed category of out-of-scope changes.
>
> More generally, the recent spate of complaints about regressions to a
> particular coding style have to do with loss of implicit tuple splatting,
> the cure for which is a proper implementation of tuple splatting, not
> poking holes into settled parts of the type system.
>
>
>
>
> On Mon, Jun 12, 2017 at 12:15 John McCall via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>>
>> On Jun 12, 2017, at 4:48 AM, Jérémie Girault via swift-evolution <
>> swift-evolution@swift.org> 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 (which make
>> sense), I wanted create a few proposal which would improve these recent
>> changes with a few simple rules.
>>
>> My propositions are based on the recent decisions and in the continuation
>> of SE-0110. The first one is about Void.
>> Void is historically defined as the type of the empty tuple. The reason
>> of this is that arguments were initially considered as tuple.
>>
>>
>> The dominant consideration here was always return types, not parameters.
>> I'm not sure there was ever much point in writing Void in a parameter list,
>> but whatever reasons there were surely vanished with SE-0066.
>>
>> Note that 'void' in C was originally exclusively a return type.  ANSI
>> gave it a new purpose it with void*, but the meaning is totally unrelated.
>>
>> John.
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[David Waite via swift-evolution]

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

>> 
>> Ah, right. So a String.Index is actually something similar to
>> 
>> public struct Index {
>>public var encodedOffset: Int
>>private var byteOffset: Int // UTF-8 offset into the UTF-8 code unit
>> }
> 
> Similar.  I'd write it this way:
> 
> public struct Index {
>   public var encodedOffset: Int
> 
>   // Offset into a UnicodeScalar represented in an encoding other
>   // than the String's underlying encoding
>   private var transcodedOffset: Int 
> }

I *think* the following is what the proposal is saying, but let me walk through 
it:

My understanding would be:
- An index manipulated at the string level points to the start a grapheme 
cluster which is also a particular code point and to a code unit of the 
underlying string backing data
- The unicodeScalar view can be intra-grapheme cluster, pointing at a code point
- The utf-16 index can be intra-codepoint, since some code points are 
represented by two code units
- The uff-8 index can be intra-codepoint as well,  since code points are 
represented by up to four code units

So is the idea of the Index struct is that the encodedOffset is an offset in 
the native representation of the string (byte offset, word offset, etc) to the 
start of a grapheme, and transcodedOffset is data for Unicode Scalar, UTF-16 
and UTF-8 views to represent an offset within a grapheme to a code point or 
code unit?

My feeling is that ‘encoded’ is not enough to distinguish whether encodedOffset 
is meant to indicate an offset in graphemes, code points, or code units, or to 
specify that an index to the same character in two normalized strings may be 
different if one is backed by UTF-8 and the other UTF-16. 
“encodedCharacterOffset” may be better.

This index struct does limit some sorts of imagined string implementations, 
such as a string maintained piecewise across multiple allocation units or 
strings using a stateful character encoding like ISO/IEC 2022.

-DW

P.S. I’m also curious why the methods are optional failing vs retaining the 
current API and having them fatal error.___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Robert Bennett via swift-evolution]

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 via swift-evolution 
>  wrote:
> 
> 
> 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`
>> 
>> Void, however, seem naturally fitted for the absence of argument.
>> 
>> Should `func foo(Void)` be different from `func foo()`? I don’t think so. 
>> But different from `func foo(Unit)` ? Yes !
>> 
> To me, "Unit" is used like "a unit of length", "a unit of time", etc. I've 
> not come across it being used as analog for something like the empty tuple.
> 
> - Dave Sweeris
> ___
> swift-evolution mailing list
> swift-evolution@swift.org 
> https://lists.swift.org/mailman/listinfo/swift-evolution 
> 
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[David Sweeris via swift-evolution]

> 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`
> 
> Void, however, seem naturally fitted for the absence of argument.
> 
> Should `func foo(Void)` be different from `func foo()`? I don’t think so. But 
> different from `func foo(Unit)` ? Yes !
> 
To me, "Unit" is used like "a unit of length", "a unit of time", etc. I've not 
come across it being used as analog for something like the empty tuple.

- Dave Sweeris___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Jérémie Girault via swift-evolution]

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 different from `func foo()`? I don’t think so.
But different from `func foo(Unit)` ? Yes !


My point here is that we probably won’t have splatting for swift4.


But if we consider the type system as a guide, we can consider 3 simple set
of rules and restore almost 100% source compatibility while keeping the
improvement of SE-0110
- Rules for swift3 tuples-arguments of cardinality zero (Void) in swift 4
(this proposition)
- Rules for swift3 tuples-arguments of cardinality one in swift 4
(proposition to be done)
- Rules for swift3 tuples-arguments of cardinality > 1 in swift 4
(proposition to be done)

—
very short reply expected - vsre.info
Jérémie Girault

On 12 juin 2017 at 19:25:31, Xiaodi Wu (xiaodi...@gmail.com) 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.



If I recall, a number of conversations have been raised about Void being a
typealias of (), and the definitive response has been that this falls into
the ship-has-sailed category of out-of-scope changes.

More generally, the recent spate of complaints about regressions to a
particular coding style have to do with loss of implicit tuple splatting,
the cure for which is a proper implementation of tuple splatting, not
poking holes into settled parts of the type system.




On Mon, Jun 12, 2017 at 12:15 John McCall via swift-evolution <
swift-evolution@swift.org> wrote:

>
> On Jun 12, 2017, at 4:48 AM, Jérémie Girault via swift-evolution <
> swift-evolution@swift.org> 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 (which make
> sense), I wanted create a few proposal which would improve these recent
> changes with a few simple rules.
>
> My propositions are based on the recent decisions and in the continuation
> of SE-0110. The first one is about Void.
> Void is historically defined as the type of the empty tuple. The reason of
> this is that arguments were initially considered as tuple.
>
>
> The dominant consideration here was always return types, not parameters.
> I'm not sure there was ever much point in writing Void in a parameter list,
> but whatever reasons there were surely vanished with SE-0066.
>
> Note that 'void' in C was originally exclusively a return type.  ANSI gave
> it a new purpose it with void*, but the meaning is totally unrelated.
>
> John.
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Jérémie Girault via swift-evolution]

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 point of view.

This is a consequence of
1/ SE-0110 specifying that function arguments-as-tuple exist no more and
are differentiated from tuple-as-arguments
2/ the fact that Void is historically a tuple

This new proposition tries to address regressions happening when arguments
are “Void” only.

—
very short reply expected - vsre.info
Jérémie Girault

On 12 juin 2017 at 19:15:18, John McCall (rjmcc...@apple.com) wrote:


On Jun 12, 2017, at 4:48 AM, Jérémie Girault via swift-evolution <
swift-evolution@swift.org> 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 (which make
sense), I wanted create a few proposal which would improve these recent
changes with a few simple rules.

My propositions are based on the recent decisions and in the continuation
of SE-0110. The first one is about Void.
Void is historically defined as the type of the empty tuple. The reason of
this is that arguments were initially considered as tuple.


The dominant consideration here was always return types, not parameters.
I'm not sure there was ever much point in writing Void in a parameter list,
but whatever reasons there were surely vanished with SE-0066.

Note that 'void' in C was originally exclusively a return type.  ANSI gave
it a new purpose it with void*, but the meaning is totally unrelated.

John.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Xiaodi Wu via swift-evolution]

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 response has been that this falls into
the ship-has-sailed category of out-of-scope changes.

More generally, the recent spate of complaints about regressions to a
particular coding style have to do with loss of implicit tuple splatting,
the cure for which is a proper implementation of tuple splatting, not
poking holes into settled parts of the type system.


On Mon, Jun 12, 2017 at 12:15 John McCall via swift-evolution <
swift-evolution@swift.org> wrote:

>
> On Jun 12, 2017, at 4:48 AM, Jérémie Girault via swift-evolution <
> swift-evolution@swift.org> 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 (which make
> sense), I wanted create a few proposal which would improve these recent
> changes with a few simple rules.
>
> My propositions are based on the recent decisions and in the continuation
> of SE-0110. The first one is about Void.
> Void is historically defined as the type of the empty tuple. The reason of
> this is that arguments were initially considered as tuple.
>
>
> The dominant consideration here was always return types, not parameters.
> I'm not sure there was ever much point in writing Void in a parameter list,
> but whatever reasons there were surely vanished with SE-0066.
>
> Note that 'void' in C was originally exclusively a return type.  ANSI gave
> it a new purpose it with void*, but the meaning is totally unrelated.
>
> John.
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Jérémie Girault via swift-evolution]

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 natural way to approach the code.
This could be addressed by another proposition (not on this topic)

—
very short reply expected - vsre.info
Jérémie Girault

On 12 juin 2017 at 19:03:51, Jens Persson (j...@bitcycle.com) wrote:

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
foo(fnB) // Compiles in both Swift 3 and Swift 4
foo(fnC) // Compiles in Swift 3, error in Swift 4

From what I read in your proposal, I assume that you want foo(fnA) to
compile in both.
But if so, don't you think foo(fnC) should also compile in both?

/Jens


On Mon, Jun 12, 2017 at 10:48 AM, Jérémie Girault via swift-evolution <
swift-evolution@swift.org> 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 (which make
> sense), I wanted create a few proposal which would improve these recent
> changes with a few simple rules.
>
> My propositions are based on the recent decisions and in the continuation
> of SE-0110. The first one is about Void.
> Void is historically defined as the type of the empty tuple. 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.
>
> I think that by having a few rules around tuples of cardinality 0 and 1
> and also arguments list, we could greatly improve source compatibility and
> keep a lot of what makes swift great when using functional style and
> generics.
>
> I drafted a proposal that would allow more source compatibility and type
> consistency and would enjoy discussing it with you, in order to improve it
> :
>
> https://github.com/jeremiegirault/swift-evolution/blob/master/
> proposals/-flatten-void.md
>
> Let me know what you think about it,
>
> —
> very short reply expected - vsre.info
> Jérémie Girault
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[John McCall via swift-evolution]

> 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 could be improved. Instead of fighting these propositions (which make 
> sense), I wanted create a few proposal which would improve these recent 
> changes with a few simple rules.
> 
> My propositions are based on the recent decisions and in the continuation of 
> SE-0110. The first one is about Void.
> Void is historically defined as the type of the empty tuple. The reason of 
> this is that arguments were initially considered as tuple.

The dominant consideration here was always return types, not parameters.  I'm 
not sure there was ever much point in writing Void in a parameter list, but 
whatever reasons there were surely vanished with SE-0066.

Note that 'void' in C was originally exclusively a return type.  ANSI gave it a 
new purpose it with void*, but the meaning is totally unrelated.

John.___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Michael Ilseman via swift-evolution]

> 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 the current 
> simpler and more uniform rule set for parameter labels are obviously better. 
> It was possible to escape the ugly special case of the first parameter, after 
> all.
> 
> Similarly, I wonder if the parentheses-related mess actually can be simpler 
> and more uniform, after all. I remember a lot of discussions in which people 
> argued that Swift couldn't and/or shouldn't get rid of the special first 
> parameter label rules.
> 
> I'm not a compiler hacker and I have no idea exactly what aspects of the 
> language is easy/hard/impossible to change once Swift is binary stable.
> 
> My concrete concerns are that the messy parentheses-related parts of the 
> language will continue to be messy for ever.
> I have no idea if there is any actual reason to worry about that, but ABI 
> stability was originally intended for Swift 3, and then it was postponed 
> because some stuff needed to be done before ABI stability. Now I'm just 
> worried that solving the parentheses situation is something that needs to be 
> done before ABI stability. Please correct/enlighten me!
> 

Ah, rest assured that ABI stability (likely*) has little to do with your 
concerns. In theory, some post-ABI-stability Swift version could rename every 
single keyword and replace curly braces with “begin/end” and parens with emoji 
without affecting the ABI. Similarly, syntactic sugar and destructuring tuples 
shouldn’t affect ABI*. Source stability is what you’re likely confusing this 
with, which can be a little nebulous.


* 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 functions must only take a 
single tuple rather than multiple arguments could affect the runtime 
representation of function types. But even then, there are approaches to 
mitigate this, so such a proposal would likely present an ABI migration 
strategy.


> /Jens
> 
> 
> 
> On Sat, Jun 10, 2017 at 12:50 AM, Michael Ilseman  > wrote:
> 
> 
> On Jun 9, 2017, at 2:10 PM, Jens Persson via swift-evolution 
> > wrote:
> 
>> The point of exercise 1 is to show that it is impossible (in Swift 4) to 
>> write a generic function composition operator (or function) which works as 
>> expected for any reasonable functions.
>> This was possible in Swift 3, but in Swift 4 it will only work for functions 
>> with exactly one parameter. You'd have to special-case it for every 
>> combination of parameter counts of f and g that it should be able to handle.
>> 
>> The following program demonstrates how it can be done in Swift 3.1 and 3.2:
>> 
>> func compose(_ g: @escaping (U) -> V, _ f: @escaping (T) -> U) -> 
>> (T) -> V {
>> return { x in g(f(x)) }
>> }
>> func sum(_ a: Int, _ b: Int) -> Int { return a + b }
>> func square(_ a: Int) -> Int { return a * a }
>> let squaredSum = compose(square, sum)
>> let result = squaredSum((3, 4)) // A bit unexepected with a tuple here but 
>> ok ...
>> print(result) // 49
>> // Well, it worked, not flawlessly but we did manage to write
>> // a function composition function and we composed sum
>> // and square, and we could call it and get a correct result.
>> 
>>  
>> And this program demonstrates what happens if you try it in Swift 4:
>> 
>> func compose(_ g: @escaping (U) -> V, _ f: @escaping (T) -> U) -> 
>> (T) -> V {
>> return { x in g(f(x)) }
>> }
>> func sum(_ a: Int, _ b: Int) -> Int { return a + b }
>> func square(_ a: Int) -> Int { return a * a }
>> // let squaredSum = compose(square, sum) // Error! (without the 
>> compose-variant below)
>> 
>> // The error message is:
>> // Cannot convert value of type `(Int, Int) -> Int` to
>> // expected argument type `(_) -> _`
>> 
>> // That's it, it is simply not possible!
>> 
>> // You'd have to write special variants of the compose func for every 
>> combination
>> // of parameter counts! For example, in order to get this sum and square
>> // example working, this specific variant must be written:
>> func compose(_ g: @escaping (V) -> W, _ f: @escaping (T, U) -> 
>> V) -> (T, U) -> W {
>> return { (x, y) in g(f(x, y)) }
>> }
>> // Now it will work:
>> let squaredSum = compose(square, sum)
>> // But only thanks to that awfully specific compose func variant ...
>> // We would have to write a lot more variants for it to be practically 
>> usable on pretty much any common function.
>> 
>> I'm sure some will say:
>> "no regular developers use function composition anyway so why ..."
>> or
>> "It's not 

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

[Jens Persson via swift-evolution]

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
foo(fnB) // Compiles in both Swift 3 and Swift 4
foo(fnC) // Compiles in Swift 3, error in Swift 4

From what I read in your proposal, I assume that you want foo(fnA) to
compile in both.
But if so, don't you think foo(fnC) should also compile in both?

/Jens


On Mon, Jun 12, 2017 at 10:48 AM, Jérémie Girault via swift-evolution <
swift-evolution@swift.org> 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 (which make
> sense), I wanted create a few proposal which would improve these recent
> changes with a few simple rules.
>
> My propositions are based on the recent decisions and in the continuation
> of SE-0110. The first one is about Void.
> Void is historically defined as the type of the empty tuple. 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.
>
> I think that by having a few rules around tuples of cardinality 0 and 1
> and also arguments list, we could greatly improve source compatibility and
> keep a lot of what makes swift great when using functional style and
> generics.
>
> I drafted a proposal that would allow more source compatibility and type
> consistency and would enjoy discussing it with you, in order to improve it
> :
>
> https://github.com/jeremiegirault/swift-evolution/blob/master/
> proposals/-flatten-void.md
>
> Let me know what you think about it,
>
> —
> very short reply expected - vsre.info
> Jérémie Girault
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[David Hart via swift-evolution]

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

func foo(_ a: T) {}
func foo() {}

foo() // are we calling foo() or foo()

> On 12 Jun 2017, at 10: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 (which make 
> sense), I wanted create a few proposal which would improve these recent 
> changes with a few simple rules.
> 
> My propositions are based on the recent decisions and in the continuation of 
> SE-0110. The first one is about Void.
> Void is historically defined as the type of the empty tuple. 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.
> 
> I think that by having a few rules around tuples of cardinality 0 and 1 and 
> also arguments list, we could greatly improve source compatibility and keep a 
> lot of what makes swift great when using functional style and generics.
> 
> I drafted a proposal that would allow more source compatibility and type 
> consistency and would enjoy discussing it with you, in order to improve it : 
> 
> https://github.com/jeremiegirault/swift-evolution/blob/master/proposals/-flatten-void.md
> 
> Let me know what you think about it,
> 
> —
> very short reply expected - vsre.info
> Jérémie Girault
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Jérémie Girault via swift-evolution]

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 convoluted (but
could happen easily in generics case).

I do not propose that implicit Void should be removed, it’s more of a
sample of the “magic” around Void. My proposition consist to “extend" this
magic a bit using given rules and in consequence, allow more
source-compatibility, readability.

I just read the SE-0066 and don’t see any conflicting point (nor relation)
with this proposition.
https://github.com/apple/swift-evolution/blob/master/proposals/0066-standardize-function-type-syntax.md
If you see any conflicting point, I would be interested to know which one
specifically.

—
very short reply expected - vsre.info
Jérémie Girault

On 12 juin 2017 at 13:21:24, Vladimir.S (sva...@gmail.com) wrote:

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 (which make sense), I
wanted
> create a few proposal which would improve these recent changes with a few
simple rules.
>
> My propositions are based on the recent decisions and in the continuation
of SE-0110.
> The first one is about Void.
> Void is historically defined as the type of the empty tuple. 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.

Could you clarify, do yo propose to change meaning of this code:
func foo() {}
from "implicitly returns Void" to "returns nothing" ?

So, this valid Swift 3 and Swift 4 code will be invalid:

func foo(){}
let x : Void = foo()
?

In this case I believe your proposal introduces new source breaking change
that makes
transition from Swift 3 to Swift 4 even more difficult for some code.

There were short discussions in this list if implicit Void return should
also be
removed and IIRC was rejected by common opinion or by some one's
authoritative opinion.

Also, I'd like to suggest you to read text of SE-0066 proposal, where you
can see
that it clearly separated functions accepting Void parameter and accepting
no
parameters. So, IMO you should also refer to SE-0066 proposal in your text
and it
seems(correct me if I understood your proposal incorrectly) you should
propose to
revisit SE-0066 in this detail.


Vladimir.

>
> I think that by having a few rules around tuples of cardinality 0 and 1
and also
> arguments list, we could greatly improve source compatibility and keep a
lot of what
> makes swift great when using functional style and generics.
>
> I drafted a proposal that would allow more source compatibility and type
consistency
> and would enjoy discussing it with you, in order to improve it :
>
>
https://github.com/jeremiegirault/swift-evolution/blob/master/proposals/-flatten-void.md
>
> Let me know what you think about it,
>
> —
> very short reply expected - vsre.info 
> Jérémie Girault
>
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Introduction of OrderedSet

[Douglas Gregor via swift-evolution]

> 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 source 
> breaking changes like this in Swift 5 (I think we’re probably out of runway 
> for Swift 4 at this point).

Definitely too late for Swift 4. 

Whether we should do it in Swift 5 depends on the source-compatibility story. 
The Swift 4 compiler has the ability to present imported types to Swift 3.2 
differently from Swift 4, which we used to stage in (e.g.) subclass 
existentials and SDK changes. We could conceivably do the same for NSOrderedSet 
<-> OrderedSet bridging, suppressing bridging of NSOrderedSet in imported APIs 
for Swift <= 4.

> We would want to bridge this in from the SDK, but if it follows the pattern 
> of our value types, we need to make API changes from the ref type to make it 
> fit in correctly with Swift-only concepts like the Collection protocols.

Sure, we’d need to design it to fit well with the standard library and provide 
the APIs people expect from NSOrderedSet.

- Doug

> - Tony
> 
>> On Jun 9, 2017, at 4:28 PM, Douglas Gregor via swift-evolution 
>> > wrote:
>> 
>>> 
>>> On Jun 9, 2017, at 10:19 AM, Xiaodi Wu via swift-evolution 
>>> > wrote:
>>> 
>>> Let me try to redirect this conversation, if I may.
>>> 
>>> As far as I can tell, SE-0069 states plainly that the plan of record is to 
>>> offer a value type called OrderedSet in Foundation, but resources to design 
>>> and implement were not then available.
>>> 
>>> So, little point in having a vote as to whether one is in favor of 
>>> OrderedSet or not. In my view, the questions to be answered are:
>>> 
>>> For the core team–
>>> 
>>> * Is it still the plan to offer value types postponed from SE-0069 as a 
>>> future addition to Foundation?
>> 
>> *I* think it’s still a good idea, and I suspect that others on the core team 
>> will agree.
>> 
>>> * If so, is that a priority in the Swift 5 timeframe, and how can the 
>>> community help to bring about this addition?
>> 
>> I wouldn’t consider it a “priority”, in the sense that I can’t imagine 
>> anything in Swift 5 that would absolutely require us to introduce this 
>> functionality in that time frame. It’s a bit of a nice-to-have-at-any-point, 
>> noting of course that bridging NSOrderedSet in existing APIs is a nontrivial 
>> source-breaking change.
>> 
>> Having a proposed API and implementation on hand makes it easier to add this 
>> functionality, of course.
>> 
>>> If not, for the whole community–
>>> 
>>> * Is it wise to implement such a type in the standard library? Should we 
>>> simply bring over the native implementation from Swift Package Manager? 
>>> What are the implications for bridging?
>> 
>> Obviously, we’d want an efficient copy-on-write, native implementation; the 
>> Swift Package Manager implementation is a bit more bare-bones than we’d 
>> want: absolute performance matters, so having a separate Set + Array in the 
>> struct probably isn’t good enough. Bridging performance matters, so we’d 
>> probably want the one-pointer representation like array uses where the 
>> pointer can be vended directly to Objective-C.
>> 
>>  - Doug
>> 
>>> On Fri, Jun 9, 2017 at 11:38 Remy Demarest via swift-evolution 
>>> > wrote:
>>> +1 for ordered set and dictionary, and please add ordered dictionary in 
>>> ObjC as well.
>>> 
>>> Envoyé de mon iPhone
>>> 
>>> Le 9 juin 2017 à 03:11, Robert Bennett via swift-evolution 
>>> > a écrit :
>>> 
 +1, and would also like to see OrderedDictionary as well.
 
 On Jun 9, 2017, at 12:50 AM, Jeff Kelley via swift-evolution 
 > wrote:
 
> I would be in favor of it; there have been a few times (including Core 
> Data, as you mentioned) where I would have used it had it been available.
> 
> 
> Jeff Kelley
> 
> slauncha...@gmail.com  | @SlaunchaMan 
>  | jeffkelley.org 
> 
>> On Jun 7, 2017, at 2:10 PM, Maik Koslowski via swift-evolution 
>> > wrote:
>> 
>> Hello,
>> 
>> in the past there have been a few requests for an OrderedSet 
>> implementation in Swift. In the proposal 
>> https://github.com/apple/swift-evolution/blob/master/proposals/0069-swift-mutability-for-foundation.md
>>  
>> 

Re: [swift-evolution] Guard let

[Vladimir.S via swift-evolution]

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


obj.methodWithCallback() {(foo, bar) in
guard let foo = foo else {
return
}

foo.prop = “new”
}
  
OR


obj.methodWithCallback() {(foo, bar) in
guard foo != nil else {
return
}

foo!.prop = “new”
}


I propose the following option:

obj.methodWithCallback() {(foo, bar) in
guard foo else {
return
}

foo.prop = “new”
}

This reduces the seemingly redundant "guard let foo = foo” statement and 
removes the unnecessary forced optional unwrapping.



There was a discussion about similar subject in the list and was decided IIRC that 
shadowing is not a good practice so it doesn't worth a special syntactic sugar. 
(correct me if I'm missing something)


Personally, I believe shadowing already (and will be) used very often(usually because 
we already have a good name for variable, and it is hard to invent one more) and 
*good* syntactic sugar for it will make Swift code more clean. But I like the 
suggestion with 'let' keyword for such shadowing to make it clear that 'foo' is 
shadowed(re-declared) with its unwrapped version :


obj.methodWithCallback() {(someMeaningfulName, bar) in
guard let someMeaningfulName else {
return
}

someMeaningfulName.prop = “new”
}

Note that if it's 'foo' - it seems not a problem to write
guard let foo = foo else {..},
but when we have
guard let someMeaningfulName = someMeaningfulName else {..}
, we have to parse each variable to check if the same name declared or probably 
different name. Plus DRY principle.


if let someMeaningfulName {
  // unwrapped someMeaningfulName here
}

instead of

if let someMeaningfulName = someMeaningfulName {
}


- Justin


___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Guard let

[Gmail via swift-evolution]

Yes, this is the proper channel to discuss this kind of proposal. 

What you’re proposing has been brought up before, or as Chris Lattner put it:
“Yes, this has thoroughly been beaten to death. It is also outside the scope of 
Swift 4 stage 1. That said, it is such a glaring problem that we’ll have to 
deal with it at some point.”
https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20161024/028448.html
 
<https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20161024/028448.html>

I don’t recall if there was a conclusion other than that it was out of scope.

This message from 26 October 2016 seems to be the start of the longest 
discussion of it that I could find: 
https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20161024/028440.html
 
<https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20161024/028440.html>

Also, Erica Sadun drafted a proposal for it:
https://gist.github.com/erica/db9ce92b3d23cb20799460f603c0ae7c 
<https://gist.github.com/erica/db9ce92b3d23cb20799460f603c0ae7c>

Unfortunately, given how close to release it is, I would guess that it’s still 
out of scope for Swift 4. 
If it’s out of scope, Ted Kremenek 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 06:07, Justin Oroz via swift-evolution 
> <swift-evolution@swift.org> 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
> 
> 
> obj.methodWithCallback() {(foo, bar) in
>   guard let foo = foo else { 
>   return
>   }
>   
>   foo.prop = “new”
> }
> 
> OR
> 
> obj.methodWithCallback() {(foo, bar) in
>   guard foo != nil else { 
>   return
>   }
>   
>   foo!.prop = “new”
> }
> 
> 
> I propose the following option:
> 
> obj.methodWithCallback() {(foo, bar) in
>   guard foo else { 
>   return
>   }
>   
>   foo.prop = “new”
> }
> 
> This reduces the seemingly redundant "guard let foo = foo” statement and 
> removes the unnecessary forced optional unwrapping. 
> 
> - Justin
> 
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Tony Parker via swift-evolution]

> 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]
> 
> 
> 
> 
> When the `sortedKeys` option is available, can it be used **by default** in 
> the `JSONEncoder`?
> 
> Otherwise, can the `JSONEncoder.OutputFormatting` enum have extra cases?
> 

We intend to make this option available to JSONEncoder as well, but since the 
underlying feature was tied to the OS release we couldn’t pre-announce it.

One nit pick: I don’t think default is the right answer, because sorting has a 
performance cost and we think it’s better to opt-in to the more expensive 
operations.

- Tony

> case compact
> case compactWithSortedKeys
> case prettyPrinted
> case prettyPrintedWithSortedKeys
> 
> 
> 
> -- Ben
> 
>> On 16 Mar 2017, at 22:47, Itai Ferber  wrote:
>> 
>> The sorted order of keys is an implementation detail of 
>> PropertyListSerialization which JSONSerialization does not share.
>> This would require a change in JSONSerialization, which is possible, but out 
>> of scope for this work specifically. It would have to go through review.
>> 
>> [FWIW, the key ordering isn’t changing at random; JSONSerialization writes 
>> keys in the order that it receives them (sorted in the order that 
>> NSDictionary stores them, based on hash). If you want this to not interfere 
>> with your Git repo (on a more immediate timescale), you can probably do 
>> something like adding a pre-commit Git hook to lint the file as needed. But 
>> I digress, this is totally off-topic.]
>> 
>>> On 16 Mar 2017, at 14:57, Ben Rimmington wrote:
>>> 
>>> Sorry, I actually meant that keys would be ordered **alphabetically** (as 
>>> they are with PropertyListSerialization).
>>> 
>>> I'm storing output from JSONSerialization in a git repository, and when I 
>>> add/remove a single key-value the entire file changes, due to keys being 
>>> reordered (seemingly at random).
>>> 
>>> -- Ben
>>> 
 Itai Ferber wrote:
 
 By stable ordering, you mean dictionaries with keys being output in the 
 order that they were encoded?
 Potentially, but this would require additional work as neither Swift 
 dictionaries nor NSMutableDictionary support this (reasonable seeing as 
 dictionaries are by definition not sorted), and the current implementation 
 uses JSONSerialization as the concrete serializer. Certainly not 
 impossible, though.
 
> On 16 Mar 2017, at 8:49, Ben Rimmington wrote:
> 
> 
> 
> Could the `JSONEncoder.OutputFormatting.prettyPrinted` case include the 
> **stable ordering** of keys?
> 
> -- Ben
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

[swift-evolution] Guard let

[Justin Oroz via swift-evolution]

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 { 
return
}

foo.prop = “new”
}
 
OR

obj.methodWithCallback() {(foo, bar) in
guard foo != nil else { 
return
}

foo!.prop = “new”
}


I propose the following option:

obj.methodWithCallback() {(foo, bar) in
guard foo else { 
return
}

foo.prop = “new”
}

This reduces the seemingly redundant "guard let foo = foo” statement and 
removes the unnecessary forced optional unwrapping. 

- Justin


___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

[swift-evolution] Introducing synthesized locks

[Erik Aigner via swift-evolution]

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 struct/class 
objects that automatically synthesize a semaphore variable on the object and 
use it to lock said method. Here is an example of how that would work

Without the synchronized attribute (code written in mail, not compiled):

class Obj {

 private let sema = DispatchSemaphore(value: 1)

func synchronizedMethod() {
sema.wait()
defer {
sema.signal()
}
// do something...
}
}

With synchronized attribute (the semaphore/wait/deferred-signal is synthesized 
by Swift automatically)

class Obj {

synchronized func method() {
// semaphore is synthesized automatically, do something…
}
}


Cheers,
Erik
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Jérémie Girault via swift-evolution]

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 issues we can avoid the
regressions of the language and greatly improve swift4

> > Le 9 juin 2017 à 10:07, Mark Laceymailto:mark.la...@apple.com'>
mailto:mark.la...@apple.com )>a écrit :
> >
> > I’m not trying to argue that it’s impossible to do. I don’t think it’s
a good idea at all. That’s subjective. Me saying “that really should be an
error” is a subjective statement. I don’t have to say “This is a subjective
statement” to make a subjective statement.
> Yes, sorry: It's so easy to sound assertive even when we just want to
share and communicate opinions.
>
> > > I *do* suggest a specific handling of { _ ... }. I have shown how it
can be implemented in a non-ambiguous fashion.
> >
> > Your own comment says this should be considered ambiguous. It’s
unambiguous now. What I am asking is how is that an improvement?
> I suggest { _ in ... } is ambiguous only in case of function overloading.
In this case, you have { (_) in ... } and { (_,_) in ... } for
disambiguation:
>
> funcoverloaded(_closure: (Int,Int) ->Int) ->String{return"overloaded 1"}
> funcoverloaded(_closure: ((lhs:Int, rhs:Int)) ->Int)
->String{return"overloaded 2"}
>
>
>
>
> overloaded {_in1}// error: ambiguous use of ‘overloaded'
>
>
>
>
>
> overloaded { (_)in1}// "overloaded 1”
>
>
>
>
>
>
>
>
>
>
> overloaded { (_, _)in1}// "overloaded 2”
>
>
>
>
>
>
>
>
>
>
>
> When a function is not overloaded, then { _ in ... } would always mean "I
don't care", and is always accepted except for closures that take no
argument at all:
>
> funcf1(_closure: () ->Int) ->String{return"f1"}
> funcf2(_closure: (Int) ->Int) ->String{return"f2"}
> funcf3(_closure: (Int,Int) ->Int) ->String{return"f3"}
> funcf4(_closure: ((lhs:Int, rhs:Int)) ->Int) ->String{return"f4"}
>
> f1 {_in1}// error
>
> f2 {_in1}//OK, you don't care
>
> f3 {_in1}// OK, you don't care
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> f3 {(_,_)in1}// OK, just what I expected!
>
> f4 {_in1}// OK, you don't care
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> f4 {(_)in1}// OK,just what I expected!
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> f4 {(_,_)in1}// OK, maybe you use tuple splatting somewhere else and want
to be consistent
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> All this is *possible*. And I don't see how it breaks anything. On the
other side, it eases everyday life, reduces clutter, and avoids useless
punctuation.
> Gwendal
>
>
>
>

—
very short reply expected - vsre.info
Jérémie Girault
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Roope Kangas via swift-evolution]

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

  print(_:separator:terminator:)
  Writes the textual representations of the given items into the standard
output.

  ...

This means some kind of nice textual version of what I find here:
https://developer.apple.com/documentation/swift/1541053-print

I see that in the source code this information is available
(
https://github.com/apple/swift/blob/master/stdlib/public/core/Print.swift#L13
).

And that in the playgrounds I can get this quick help. Would be really nice
to access this from the REPL too.


KR,

--
Roope Kangas
http://fi.linkedin.com/in/roopekangas
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Ben Rimmington via swift-evolution]

The new `JSONSerialization.WritingOptions.sortedKeys` option was mentioned at 
WWDC.

"What's New in Cocoa" [33:03 ... 33:33]




When the `sortedKeys` option is available, can it be used **by default** in the 
`JSONEncoder`?

Otherwise, can the `JSONEncoder.OutputFormatting` enum have extra cases?

case compact
case compactWithSortedKeys
case prettyPrinted
case prettyPrintedWithSortedKeys



-- Ben

> On 16 Mar 2017, at 22:47, Itai Ferber  wrote:
> 
> The sorted order of keys is an implementation detail of 
> PropertyListSerialization which JSONSerialization does not share.
> This would require a change in JSONSerialization, which is possible, but out 
> of scope for this work specifically. It would have to go through review.
> 
> [FWIW, the key ordering isn’t changing at random; JSONSerialization writes 
> keys in the order that it receives them (sorted in the order that 
> NSDictionary stores them, based on hash). If you want this to not interfere 
> with your Git repo (on a more immediate timescale), you can probably do 
> something like adding a pre-commit Git hook to lint the file as needed. But I 
> digress, this is totally off-topic.]
> 
>> On 16 Mar 2017, at 14:57, Ben Rimmington wrote:
>> 
>> Sorry, I actually meant that keys would be ordered **alphabetically** (as 
>> they are with PropertyListSerialization).
>> 
>> I'm storing output from JSONSerialization in a git repository, and when I 
>> add/remove a single key-value the entire file changes, due to keys being 
>> reordered (seemingly at random).
>> 
>> -- Ben
>> 
>>> Itai Ferber wrote:
>>> 
>>> By stable ordering, you mean dictionaries with keys being output in the 
>>> order that they were encoded?
>>> Potentially, but this would require additional work as neither Swift 
>>> dictionaries nor NSMutableDictionary support this (reasonable seeing as 
>>> dictionaries are by definition not sorted), and the current implementation 
>>> uses JSONSerialization as the concrete serializer. Certainly not 
>>> impossible, though.
>>> 
 On 16 Mar 2017, at 8:49, Ben Rimmington wrote:
 
 
 
 Could the `JSONEncoder.OutputFormatting.prettyPrinted` case include the 
 **stable ordering** of keys?
 
 -- Ben
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Charles Srstka via swift-evolution]

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 @objc broadly 
available would be a more elegant solution.

> On Jun 10, 2017, at 11:47 AM, Charles Srstka via swift-evolution 
>  wrote:
> 
> INTRODUCTION:
> 
> This pitch proposes to allow the @objc keyword on all property declarations, 
> even ones whose type cannot be represented in Objective-C.
> 
> MOTIVATION:
> 
> You’re thinking, “But that’s crazy. Why would you ever want to do that?” But 
> hear me out:
> 
> - In Swift 4, barring cases where it’s required for technical reasons, 
> properties are exposed to Objective-C only if there’s an actual @objc keyword 
> present. This keyword represents a clear statement of intent that this 
> protocol is meant to be visible to Objective-C, and means that expanding the 
> scope of the @objc keyword will not increase code size anywhere other than 
> where a deliberate decision has been made to do so.
> 
> - Since Swift 3, all Swift types are in fact bridgeable to Objective-C, and 
> an ‘Any’ is bridged to an ‘id’.
> 
> - While it’s true that Objective-C will generally get an opaque object that 
> it won’t know what to do with, that doesn’t mean that there aren’t cases 
> where this can still be useful, such as:
> 
> - Value transformers. Even if a type is completely opaque to Objective-C, 
> that doesn’t mean a value transformer can’t convert it into something that 
> Objective-C can use. There are some quite useful general-purpose value 
> transformers that could be written for this task, such as:
> 
> class CustomStringConvertibleValueTransformer: ValueTransformer {
> override class func transformedValueClass() -> AnyClass { return 
> NSString.self }
> override class func allowsReverseTransformation() -> Bool { return false }
> 
> override func transformedValue(_ value: Any?) -> Any? {
> return (value as? CustomStringConvertible)?.description
> }
> }
> 
> With this value transformer, an enum like this one from the Swift manual 
> could be exposed to Objective-C and bound to a UI element in Interface 
> Builder, resulting in a meaningful value being shown in the UI:
> 
> enum Suit: CustomStringConvertible {
> case spades, hearts, diamonds, clubs
> var description: String {
> switch self {
> case .spades:
> return "spades"
> case .hearts:
> return "hearts"
> case .diamonds:
> return "diamonds"
> case .clubs:
> return "clubs"
> }
> }
> }
> 
> Once we have generalized existentials, we could write this value transformer 
> as well, which would be able to handle all Swift enums backed by 
> ObjC-representable types without any special hacks:
> 
> class RawRepresentableValueTransformer: ValueTransformer {
> override class func transformedValueClass() -> AnyClass { return 
> AnyObject.self }
> override class func allowsReverseTransformation() -> Bool { return false }
> 
> override func transformedValue(_ value: Any?) -> Any? {
> return (value as? RawRepresentable)?.rawValue
> }
> }
> 
> - KVO dependencies. Even without a value transformer, a property of a 
> non-ObjC-representable type may be a dependency of other properties which 
> *are* ObjC-representable, as in this example:
> 
> class PlayingCard: NSObject {
> @objc dynamic var suit: Suit // currently an error
> 
> init(suit: Suit) {
> self.suit = suit
> super.init()
> }
> 
> @objc private static let keyPathsForValuesAffectingSuitName: Set 
> = [#keyPath(suit)]
> @objc var suitName: String { return self.suit.description }
> }
> 
> Although the ‘suit’ property is not representable in Objective-C, the 
> ‘suitName’ property is, and it would behoove us to allow it to be updated 
> when ‘suit’ changes. Currently, we have to resort to various hacks to 
> accomplish this. One can manually send the KVO notifications on the original 
> property instead of near the dependent ones, which can be error-prone:
> 
> class ErrorPronePlayingCard: NSObject {
> var suit: Suit {
> willSet { self.willChangeValue(for: \.suitName) }
> didSet { self.didChangeValue(for: \.suitName) }
> }
> 
> init(suit: Suit) {
> self.suit = suit
> super.init()
> }
> 
> @objc var suitName: String { return self.suit.description }
> }
> 
> Formerly, one could simply use arbitrary strings as key paths, which was ugly 
> since it required a separate override of value(forKey:) to avoid exceptions 
> if someone actually tried to acquire a value using the key. Also, it doesn’t 
> seem to work anymore in Swift 4, since the will/didChangeValue methods now 
> expect a KeyPath object 

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

[Xiaodi Wu via swift-evolution]

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 together a
good collection of links to the very extensive past conversations.
Unfortunately, I can’t do that for you today, but I’d highly recommend
taking a look at those conversations.

if you’re serious about this idea, putting in the hard but necessary work
of finding, digesting, and summarizing prior discussions for those who come
afterward is, I would argue, a key step. Admittedly, the mailing list
format is not at all easy to search, but one of the delights of the written
medium is that we’re called to engage past conversations in the present.


On Mon, Jun 12, 2017 at 07:20 Daryle Walker via swift-evolution <
swift-evolution@swift.org> wrote:

> 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 equivalent to C++’s
> “static_assert” after someone querying me about “constexpr” in one of my
> array threads. Using these expressions during a generic where clause is
> like using C++ static-assert during template instantiation. Using them
> during an #if/#elseif/#else surrounding an #error directive (explained in a
> separate post a couple days ago) acts like using C++ static-asserts in
> non-template contexts. (This is what inspired the #error proposal.)
>
> Arbitrary Compiler Constant Expressions
>
>- Proposal: SE-
>- Authors: Daryle Walker , Author 2
>
>- Review Manager: TBD
>- Status: *Awaiting review*
>
> *During the review process, add the following fields as needed:*
>
>- Decision Notes: Rationale
>, Additional
>Commentary 
>- Bugs: SR- , SR-
>
>- Previous Revision: 1
>
> 
>- Previous Proposal: SE-
>
> Introduction
>
> This proposal adds compile-time constant expressions, and how to generate
> them, to the language
>
> Swift-evolution thread: Discussion thread topic for that proposal
> 
> Motivation
>
> Conditional compilation blocks can shape the design of code based on
> criteria known at compile time. Generic where clauses do the same for
> limiting which generics can get instantiated. The criteria for either is
> extremely limited; Boolean combinations of environment state for
> conditional compilation blocks, and type equivalence, inheritance, or
> conformance for generic where clauses.
>
> Other languages, like C++, allow values computed from specially-marked ("
> constexpr") objects and functions. Adding this to Swift permits user-side
> generated tests today, and is a first step to non-Boolean compile-time
> values, like value-based generic parameters or static-sized array extents.
> Proposed solution
>
>1. Define a new declaration attribute that can mark off data and code
>as being compatible with compile-time expressions (CTE). The definitions of
>the marked items may have restrictions to ensure realization at
>compile-time.
>2. Designate parts of certain constructs that they can only take CTEs.
>Expressions outside of those constructs are evaluated at run-time as usual.
>3. Specify the compile-time realization engine.
>4. Speculate on what parts of the existing standard library should be
>updated to support CTEs.
>
> (I have no concrete examples here. But I do think about if we had
> something like C++'s type-traits library, then we could replace direct
> type-testing generic where clauses with ones that check the desired traits
> from our type-traits equivalent structure.)
> Detailed designComputation
>
> The language to process the Swift source file for CTEs before compilation
> is... the compiler itself! The Swift compiler can translate Swift as a
> compiled language or an interpreted language. CTEs are computed in an
> interpreted pass of the source code. If the translation is a Swift
> interpretation, then the translation goes over the CTE directly instead of
> a second interpreter.
>
> There cannot be any recursion. If the CTE is within a statement or part of
> a generic where clause, then the CTE cannot refer either directly or
> indirectly to the function its modifying. If the CTE is within an
> initializer, then it cannot refer to the object being initialized. A fatal

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

[Adrian Kashivskyy via swift-evolution]

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 ABI 
Stability Dashboard.

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

Considering the nature of open-source projects and that most of them are 
compiled by users (either manually or by a package manager) on their own 
machines, the environment and configuration may vary so you won’t prove what 
you want to, based on your description.

If you want to distribute pre-built binaries and are afraid of malicious 
modifications of them, you should use code signing. It is designed to prove 
that binaries have not been tampered with and came from a trusted, original 
source.

——
adrian kashivskyy

On 12 Jun 2017, 11:38 +0200, Tuur Anton via swift-evolution 
, wrote:
> 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 should be possible to do. To get the same conditions, a VM (or just the 
> same cleanly installed Mac) could be used. If the compiler adds a timestamp, 
> an option to remove the timestamp could be added. Etc.
>
>
> Bitcoin Core does this using Gitian: https://gitian.org
>
> Debian Linux is making progress: https://wiki.debian.org/ReproducibleBuilds
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Daryle Walker via swift-evolution]

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 equivalent to C++’s “static_assert” 
after someone querying me about “constexpr” in one of my array threads. Using 
these expressions during a generic where clause is like using C++ static-assert 
during template instantiation. Using them during an #if/#elseif/#else 
surrounding an #error directive (explained in a separate post a couple days 
ago) acts like using C++ static-asserts in non-template contexts. (This is what 
inspired the #error proposal.)

Arbitrary Compiler Constant Expressions
Proposal: SE- 
Authors: Daryle Walker , Author 2 

Review Manager: TBD
Status: Awaiting review
During the review process, add the following fields as needed:

Decision Notes: Rationale , 
Additional Commentary 
Bugs: SR- , SR- 

Previous Revision: 1 

Previous Proposal: SE- 
Introduction
This proposal adds compile-time constant expressions, and how to generate them, 
to the language

Swift-evolution thread: Discussion thread topic for that proposal 

Motivation
Conditional compilation blocks can shape the design of code based on criteria 
known at compile time. Generic where clauses do the same for limiting which 
generics can get instantiated. The criteria for either is extremely limited; 
Boolean combinations of environment state for conditional compilation blocks, 
and type equivalence, inheritance, or conformance for generic where clauses.

Other languages, like C++, allow values computed from specially-marked 
("constexpr") objects and functions. Adding this to Swift permits user-side 
generated tests today, and is a first step to non-Boolean compile-time values, 
like value-based generic parameters or static-sized array extents.

Proposed solution
Define a new declaration attribute that can mark off data and code as being 
compatible with compile-time expressions (CTE). The definitions of the marked 
items may have restrictions to ensure realization at compile-time.
Designate parts of certain constructs that they can only take CTEs. Expressions 
outside of those constructs are evaluated at run-time as usual.
Specify the compile-time realization engine.
Speculate on what parts of the existing standard library should be updated to 
support CTEs.
(I have no concrete examples here. But I do think about if we had something 
like C++'s type-traits library, then we could replace direct type-testing 
generic where clauses with ones that check the desired traits from our 
type-traits equivalent structure.)

Detailed design
Computation

The language to process the Swift source file for CTEs before compilation is... 
the compiler itself! The Swift compiler can translate Swift as a compiled 
language or an interpreted language. CTEs are computed in an interpreted pass 
of the source code. If the translation is a Swift interpretation, then the 
translation goes over the CTE directly instead of a second interpreter.

There cannot be any recursion. If the CTE is within a statement or part of a 
generic where clause, then the CTE cannot refer either directly or indirectly 
to the function its modifying. If the CTE is within an initializer, then it 
cannot refer to the object being initialized. A fatal diagnostic shall be 
emitted. One shall also be emitted if CTE evaluation reaches a nonreturning 
function, an uncaught exception, or dereferenced nil optional or similar.

Floating-point operations of the interpreter do not have to exactly match the 
ones from the compiler. The interpreter will make its best interpolation to a 
value supported by the compiler.

The directly-referred symbols of a CTE (the ones seen at the CTE-accepting 
construct) can only be constant declarations and/or routines that do not have 
inout parameters or mutating self. Constants have to be literals, top-level 
objects, or type-level properties. A type-level variable computed property can 
be used if it's getter-only.

Complier implementations may place restrictions on the complexity, resource 
usage, time taken, etc., of CTE evaluation. (Put reasonable minimal limits 
here.)

Attribute

The define attribute shall indicate its owning declaration can be included in 
CTEs. The corresponding definition must be available through the source code; 
the attribute is ignored for items with their realization only as binary code.

Such items still have their run-time realization, 

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

[Ben Rimmington via swift-evolution]

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

 (35)


 (11)


 (24)

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Vladimir.S via swift-evolution]

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 (which make sense), I wanted 
create a few proposal which would improve these recent changes with a few simple rules.


My propositions are based on the recent decisions and in the continuation of SE-0110. 
The first one is about Void.
Void is historically defined as the type of the empty tuple. 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.


Could you clarify, do yo propose to change meaning of this code:
func foo() {}
from "implicitly returns Void" to "returns nothing" ?

So, this valid Swift 3 and Swift 4 code will be invalid:

func foo(){}
let x : Void = foo()
?

In this case I believe your proposal introduces new source breaking change that makes 
transition from Swift 3 to Swift 4 even more difficult for some code.


There were short discussions in this list if implicit Void return should also be 
removed and IIRC was rejected by common opinion or by some one's authoritative opinion.


Also, I'd like to suggest you to read text of SE-0066 proposal, where you can see 
that it clearly separated functions accepting Void parameter and accepting no 
parameters. So, IMO you should also refer to SE-0066 proposal in your text and it 
seems(correct me if I understood your proposal incorrectly) you should propose to 
revisit SE-0066 in this detail.



Vladimir.



I think that by having a few rules around tuples of cardinality 0 and 1 and also 
arguments list, we could greatly improve source compatibility and keep a lot of what 
makes swift great when using functional style and generics.


I drafted a proposal that would allow more source compatibility and type consistency 
and would enjoy discussing it with you, in order to improve it :


https://github.com/jeremiegirault/swift-evolution/blob/master/proposals/-flatten-void.md

Let me know what you think about it,

—
very short reply expected - vsre.info 
Jérémie Girault


___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Tuur Anton via swift-evolution]

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 should be possible to do. To get the same conditions, a VM (or just the 
same cleanly installed Mac) could be used. If the compiler adds a timestamp, an 
option to remove the timestamp could be added. Etc.

Bitcoin Core does this using Gitian: https://gitian.org
Debian Linux is making progress: https://wiki.debian.org/ReproducibleBuilds___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Tino Heth via swift-evolution]

> 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 standpoint is more moderate:
At least it's time to question Void as an empty tuple, and I appreciate 
discussions about cleaning up fundamentals of the language (hope that I can add 
something later this week).___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

[swift-evolution] [Proposal] Change Void meaning

[Jérémie Girault via swift-evolution]

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 improve these recent
changes with a few simple rules.

My propositions are based on the recent decisions and in the continuation
of SE-0110. The first one is about Void.
Void is historically defined as the type of the empty tuple. 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.

I think that by having a few rules around tuples of cardinality 0 and 1 and
also arguments list, we could greatly improve source compatibility and keep
a lot of what makes swift great when using functional style and generics.

I drafted a proposal that would allow more source compatibility and type
consistency and would enjoy discussing it with you, in order to improve it
:

https://github.com/jeremiegirault/swift-evolution/blob/master/proposals/-flatten-void.md

Let me know what you think about it,

—
very short reply expected - vsre.info
Jérémie Girault
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Riley Testut via swift-evolution]

> 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 the 
> initializer as `factory`. However, it does look like Objective-C initializers 
> will have to be a special case, in order for non-factory initializers in 
> Swift to be able to override them.

IIRC, there is already special logic for handling Objective-C initializers from 
Swift; they are effectively implemented as if they were factory initializers. I 
still don’t think we need to explicitly mark them as factory though, as that 
would certainly be confusing to newcomers (and would mess with the 
convenience/required initializer chain).

> We could just drop factory initializers in classes for now and start by only 
> adding them to protocols (which is incomparably easier) and see where this 
> goes first.

I believe factory initializers are most powerful with classes, and since this 
would need to be solved anyway, I think we should move forward with it for all 
types + protocol extensions


> On Jun 12, 2017, at 12:43 AM, Gor Gyolchanyan  wrote:
> 
> I have thought of `static init`, but there are two problems with it:
> * The `static`-ness of it is purely an implementational detail and is not 
> related to the purpose of these initializers.
> * The term "static initializer" has another meaning in Objective-C (and other 
> languages) that initializes the type itself once at the start of the process.
> 
> 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 the 
> initializer as `factory`. However, it does look like Objective-C initializers 
> will have to be a special case, in order for non-factory initializers in 
> Swift to be able to override them.
> 
> *OR*
> 
> The way initializers worked in Objective-C is the opposite of how they work 
> in Swift: `self = [super init]; self.member = value;` (not counting the NULL 
> checks). This allowed overriding them and delegating to them even though 
> they're essentially factory methods. The problem with this was that with 
> Objective-C's poor type safety, it was easy to forget to initialize the 
> members, but with Swift, there's a strong type system for that. What we could 
> do is to make Objective-C's factory initializers create the dynamic type 
> using NSObject's `init()` and have the subclass's factory initializer 
> initialize all its members *after" the  instance is created.
> 
> *OR*
> 
> We could just drop factory initializers in classes for now and start by only 
> adding them to protocols (which is incomparably easier) and see where this 
> goes first.
> 
>> On Jun 12, 2017, at 12:30 AM, Xiaodi Wu > > wrote:
>> 
>> On Sun, Jun 11, 2017 at 3:49 PM, Riley Testut > > wrote:
>> Some thoughts on updated proposal:
>> 
>> • I strongly believe factory initializers should follow the progressive 
>> disclosure pattern, and importing all Objective-C initializers as factory 
>> initializers breaks this. While there is precedent for this because of the 
>> "open" access control, I'd prefer if maybe we compromised and any @objc 
>> initializer is assumed to have the same performance characteristics as a 
>> factory initializer, without having to prepend the factory keyword.
>> 
>> I'm not expert enough on Obj-C interop issues to make insightful comments on 
>> this, but my naive impression here is that changing how _all_ Obj-C 
>> initializers are imported by default seems...risky? Perhaps a summary of how 
>> the compiler currently handles the issue is in order for this proposal, so 
>> as to enable readers to evaluate this change.
>>  
>> • While I did initially propose the factory keyword, I'm still not entirely 
>> sure "factory" is the right choice. Though if the consensus that is the 
>> right keyword, then I'll happily accept that.
>> • Having "self" refer to the dynamic type of the returned instance 
>> seems...weird. While technically correct for a static method, I'd expect 
>> self to be an instance and Self to be the dynamic type just like any other 
>> initializer.
>> 
>> Agree: `self` referring to a type is unprecedented when it's not a static 
>> method--this feels weird. If this is essential for the whole design, have 
>> you considered maybe just calling it `static init`? (This raises a 
>> potentially interesting thought about whether it'd make sense to also have a 
>> `class init`...)
>> 
>> • Factory initializers should be used for any initializer that returns a 
>> value. 

Re: [swift-evolution] Introduction of OrderedSet

[Maik Koslowski via swift-evolution]

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 having a NSorderedSset from CoreData will definitely an usual 
case and CoreData is written in objective-c. So in a lot of use cases having a 
NSOrderedSet or an (Swift-)OrderedSet without bridging won’t make a difference. 
So it doesn’t make sense for me to implement it without bridging.

I don’t know whats planned for swift 5 and later but source breaking changes 
will most likely be worse when waiting.

- Maik

> Am 10.06.2017 um 17:42 schrieb Tony Parker :
> 
> 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 source 
> breaking changes like this in Swift 5 (I think we’re probably out of runway 
> for Swift 4 at this point).
> 
> We would want to bridge this in from the SDK, but if it follows the pattern 
> of our value types, we need to make API changes from the ref type to make it 
> fit in correctly with Swift-only concepts like the Collection protocols.
> 
> - Tony
> 
>> On Jun 9, 2017, at 4:28 PM, Douglas Gregor via swift-evolution 
>> > wrote:
>> 
>>> 
>>> On Jun 9, 2017, at 10:19 AM, Xiaodi Wu via swift-evolution 
>>> > wrote:
>>> 
>>> Let me try to redirect this conversation, if I may.
>>> 
>>> As far as I can tell, SE-0069 states plainly that the plan of record is to 
>>> offer a value type called OrderedSet in Foundation, but resources to design 
>>> and implement were not then available.
>>> 
>>> So, little point in having a vote as to whether one is in favor of 
>>> OrderedSet or not. In my view, the questions to be answered are:
>>> 
>>> For the core team–
>>> 
>>> * Is it still the plan to offer value types postponed from SE-0069 as a 
>>> future addition to Foundation?
>> 
>> *I* think it’s still a good idea, and I suspect that others on the core team 
>> will agree.
>> 
>>> * If so, is that a priority in the Swift 5 timeframe, and how can the 
>>> community help to bring about this addition?
>> 
>> I wouldn’t consider it a “priority”, in the sense that I can’t imagine 
>> anything in Swift 5 that would absolutely require us to introduce this 
>> functionality in that time frame. It’s a bit of a nice-to-have-at-any-point, 
>> noting of course that bridging NSOrderedSet in existing APIs is a nontrivial 
>> source-breaking change.
>> 
>> Having a proposed API and implementation on hand makes it easier to add this 
>> functionality, of course.
>> 
>>> If not, for the whole community–
>>> 
>>> * Is it wise to implement such a type in the standard library? Should we 
>>> simply bring over the native implementation from Swift Package Manager? 
>>> What are the implications for bridging?
>> 
>> Obviously, we’d want an efficient copy-on-write, native implementation; the 
>> Swift Package Manager implementation is a bit more bare-bones than we’d 
>> want: absolute performance matters, so having a separate Set + Array in the 
>> struct probably isn’t good enough. Bridging performance matters, so we’d 
>> probably want the one-pointer representation like array uses where the 
>> pointer can be vended directly to Objective-C.
>> 
>>  - Doug
>> 
>>> On Fri, Jun 9, 2017 at 11:38 Remy Demarest via swift-evolution 
>>> > wrote:
>>> +1 for ordered set and dictionary, and please add ordered dictionary in 
>>> ObjC as well.
>>> 
>>> Envoyé de mon iPhone
>>> 
>>> Le 9 juin 2017 à 03:11, Robert Bennett via swift-evolution 
>>> > a écrit :
>>> 
 +1, and would also like to see OrderedDictionary as well.
 
 On Jun 9, 2017, at 12:50 AM, Jeff Kelley via swift-evolution 
 > wrote:
 
> I would be in favor of it; there have been a few times (including Core 
> Data, as you mentioned) where I would have used it had it been available.
> 
> 
> Jeff Kelley
> 
> slauncha...@gmail.com  | @SlaunchaMan 
>  | jeffkelley.org 
> 
>> On Jun 7, 2017, at 2:10 PM, Maik Koslowski via swift-evolution 
>> > wrote:
>> 
>> Hello,
>> 
>> in the past there have been a few requests for an OrderedSet 
>> implementation in Swift. In the proposal 
>> 

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

[Ted Kremenek via swift-evolution]

> 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 "bring forward to Swift 4" and obvious that 
> was never going to happen for them.

I think perhaps this was obvious in hindsight, but in fairness we **all** were 
still figuring out how swift-evolution worked at all in the Swift 3 timeframe 
and we are **still** figuring things out (as evident by this thread).  When it 
is clear that something isn’t in scope for the current release we aren’t always 
omniscient about how it aligns with the next release.  Swift 5, for example, 
hasn’t been scoped yet.  There are certainly ideas, but it’s hard to say what 
the scoping should be for the next release until we see how the current active 
release shapes up.

A lot of ideas have merit, and I know it is frustrating to not get active 
discussion on them as quickly as we all would like.  Establishing focus for 
discussions is really key not only to have themes for a release (as Ben Cohen 
has eloquently summarized in the past) but also just prioritization.  Beyond 
prioritizing design points that are possibly the most pressing in Swift’s 
usability/success as a language, there’s only so much that can be done at once. 
 Thus there is a real balancing act between scheduling time to talk about 
things and actually implementing them.  I mentioned this in another reply, but 
SE-0155 is an example of this.  We discussed it, but nobody had adequate enough 
time to implement it so now it isn’t in scope for Swift 4.  It still probably 
was the right thing to discuss in in the Swift 4 timeframe, but the time we did 
spend on it was at a direct cost to other things we could have been doing.

> 
> I think having a queue to submit "proposals for eventually", written when the 
> inspiration is there, and having a core team review (say once a month or even 
> once a quarter) of their viability for future Swift directions would be 
> amazingly valuable.

This is a good point.  I think the concern about a queue is that ideas in it 
may still be subject to starvation if the queue gets too long.  Ideas also can 
atrophy in their relevance as the language evolves but proposals stay in the 
queue.  It then becomes a delicate matter when closing out old proposals.   
Having the Core Team review proposals in the queue on a regular basis may be 
the solution, but I wonder how tenable that would be in practice.  The current 
thinking behind closing out proposals that are out-of-scope is NOT to 
demoralize community participation in the evolution process, but to engage 
everyone in thinking about what is in scope for the release and to advocate for 
an idea when it makes sense for the community — and not just the Core Team — to 
actively engage on thinking about a proposal.  If an idea doesn’t make sense 
for the current release but does for a later one, then (hopefully) that idea 
will be brought up again, and possibly incorporating new context.  If anything, 
having a queue of a bunch of written proposals (each which can take significant 
effort to write) not getting much traction would possibly be even more 
demoralizing both for authors of the proposal but also everyone else.

The point about understanding “viable for future Swift directions” is key here. 
 Viability really comes down to trajectory for the language.  None of us are 
fully omniscient about what is coming in future releases, but we do have a 
sense of some of the priorities for the language that we need to tackle, 
balanced with what **kind** of changes are still acceptable to take into the 
language depending on the kind of disruption they cause for users, the tools we 
have to mitigate any pain with those changes, etc.  Discussion on 
swift-evolution does help shape those priorities in both specific ways and in 
broad strokes.  However, it is hard for me to tell if all or any of the ideas 
you are sitting on are viable — as I don’t know what they are.  I know that’s 
your point about having a queue of proposals.  But I am skeptical that such a 
thing would scale or leave you thinking the process worked any better.  What it 
sounds like to me is we need a better way to both air your ideas for 
consideration as well as a better understanding of the current thinking about 
future Swift releases.  I don’t have specific ideas yet on either, although at 
least for the former there has been some interesting ideas mentioned on this 
thread.___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution