Re: [swift-evolution] #pragma

[David Owens II via swift-evolution]

The context of comments should clearly not be ignored by IDEs. If you did that, 
the entire feature set of doc comments would go away. 

-David

Sent from my iPhone

> On Sep 4, 2016, at 5:15 PM, Félix Cloutier via swift-evolution 
>  wrote:
> 
> There is a *lot* more to `#pragma` than `#pragma mark`, but it's unclear to 
> me what other pragma anyone would bring over from C. Given that, I'm not in 
> favor of a new language construct for just one thing that's not horribly out 
> of place as a comment.
> 
> Félix
> 
>> Le 4 sept. 2016 à 15:53:46, isidoro carlo ghezzi via swift-evolution 
>>  a écrit :
>> 
>> Hi all,
>> 
>> I think the "old style" `#pragma` is necessary in Swift.
>> Exactly in the same way it is available in C/C++ or Objective-C/C++, or in 
>> something else portable way.
>> 
>> Because `#pragma` is not handled in Swift, in Xcode they overloaded the 
>> semantic of comments, giving to the comment `// MARK:` the semantic of 
>> `#pragma mark`
>> 
>> But my point of view is that, I would like that what it is written in a 
>> source comment (what it is written after a // or between /* */ ) should be 
>> fully ignore by compiler or IDE.
>> 
>> I understand that maybe a compiler shouldn't lose time handling `#pragma 
>> options`, but giving semantics to source comment, I think it can be 
>> dangerous and misunderstood.
>> 
>> The implementation in Swift compiler should be simple, ignoring any line 
>> beginning with `#pragma` (ok I know It is not simple)
>> The IDE will handle the `#pragma`
>> 
>> That's why they invented `#pragma`in C/C++ Objective-C/C++ right?
>> 
>> Thanks for your attention, and sorry for my bad english: I am Italian native 
>> spoke language.
>> 
>> #pragma mark - sign
>> Best Regards,
>> Isidoro Ghezzi
>> 
>> 
>> ___
>> 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] [Swift4] Mailing list vs. Forum

[David Owens II via swift-evolution]

But does it already surpass the limits?

>   • There is a bandwidth limit of 100k monthly page views, equivalent to 
> our Standard hosting plan.
>   • If you exceed our bandwidth limit – which is very unlikely, unless 
> your project is enormous – you have two options:
>   • We’ll help you move to self-hosting, either on your own 
> server or any Docker compatible cloud (a $20/month Digital Ocean droplet 
> should suffice).
>   • Upgrade to our Business hosting plan at 50% off.

I wouldn’t be surprised if it’s close if not passed 100k monthly views already. 

The big unknown is also around the mailing list support. Is it super robust and 
work as well for communicating as the mailing currently does? I don’t know. 
I’ve not been involved with large projects on discourse.

-David

> On Aug 3, 2016, at 1:34 PM, Jacob Bandes-Storch via swift-evolution 
>  wrote:
> 
> As I mentioned at the top of this thread, Discourse provides free hosting for 
> community-friendly open-source projects 
> 
>  which I suspect would include Swift. If not, that would indeed throw a 
> wrench in the idea.
> 
> On Wed, Aug 3, 2016 at 1:30 PM, Daniel Duan via swift-evolution 
> mailto:swift-evolution@swift.org>> wrote:
> I’d rather the core team work on the language, stdlib and the compiler. 
> Wouldn’t you agree?
> 
> > On Aug 3, 2016, at 12:59 PM, Brandon Knope via swift-evolution 
> > mailto:swift-evolution@swift.org>> wrote:
> >
> > I wasn't expecting someone else to do it! This would need to be supported 
> > by the core team 100%
> >
> > Brandon
> >
> >> On Aug 3, 2016, at 3:42 PM, David Owens II  >> > wrote:
> >>
> >>
> >>> On Aug 3, 2016, at 5:21 AM, Brandon Knope via swift-evolution 
> >>> mailto:swift-evolution@swift.org>> wrote:
> >>>
> >>> I still think it is worth doing a test to see how everyone likes it:
> >>
> >> Even if it is better, someone if going to have to either maintain the 
> >> server and install of discourse _or_ pay discourse to host it. Until 
> >> someone on the core team agrees to those terms, what’s the point really?
> >>
> >> Has anyone looked into the possibility of extending discourse’ mail 
> >> support to feed into discourse instead? Then discourse would be the view 
> >> layer instead of trying to the the truth of the data.
> >>
> >> -David
> > ___
> > 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] [Swift4] Mailing list vs. Forum

[David Owens II via swift-evolution]

> On Aug 3, 2016, at 5:21 AM, Brandon Knope via swift-evolution 
>  wrote:
> 
> I still think it is worth doing a test to see how everyone likes it:

Even if it is better, someone if going to have to either maintain the server 
and install of discourse _or_ pay discourse to host it. Until someone on the 
core team agrees to those terms, what’s the point really?

Has anyone looked into the possibility of extending discourse’ mail support to 
feed into discourse instead? Then discourse would be the view layer instead of 
trying to the the truth of the data.

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

Re: [swift-evolution] [Swift4] Mailing list vs. Forum

[David Owens II via swift-evolution]

And you go back to a single point of failure, requirement to host and maintain 
a server, or to pay them to host it for you.

Discourse is probably the best alternative, but it still has drawbacks as well.

-David


> On Aug 2, 2016, at 11:28 AM, Shawn Erickson via swift-evolution 
>  wrote:
> 
> Exactly. If you utilize a forum solution like Discourse you often will also 
> still be able to support folks that want to deal with email.
> 
> -Shawn
> 
> On Tue, Aug 2, 2016 at 11:17 AM Tim Vermeulen via swift-evolution 
> mailto:swift-evolution@swift.org>> wrote:
> For what it’s worth: Discourse has a Mailing List mode, which will send you 
> an email every time someone makes a new topic or replies to an existing topic 
> (apart from the topics you muted). You can then reply to that email to post a 
> reply in that topic, just like in a mailing list.
> 
> > On 8/2/16 13:15, Karl Wagner via swift-evolution wrote:
> > > There's no guarantee we would have to give it up entirely - many forum
> > > platforms have apps with caching for offline viewing.
> > >
> > > Besides, im not sure these discussions are always so important that you
> > > really need to download the entire list and save it all offline.
> > >
> > > Karl
> > >
> > > > On Aug 2, 2016 at 6:05 pm, > > >  > > > >>wrote:
> > > >
> > > > On 8/2/16 12:21, Erica Sadun via swift-evolution wrote:
> > > > > It is an instructive example of why remaining with a mailing list, 
> > > > > flaws and all, is probably the best answer for Swift Evolution.
> > > >
> > > > Whatever keeps a mailing list as bottom implementation gets my +1.
> > > > Forums and other browser-based things may be more convenient _if_ you're
> > > > in a place with 24/7 connectivity, which is not true for many.
> > > >
> > > > FWIW I'm using Thunderbird off the gmane group because threading doesn't
> > > > work well with other email clients.
> > A scenario I often have to follow, both at home and on trips, is
> > connect, download everything new, disconnect, read entire threads later
> > offline.
> >
> > --
> > Rainer Brockerhoffmailto:rai...@brockerhoff.net>>
> > Belo Horizonte, Brazil
> > "In the affairs of others even fools are wise
> > In their own business even sages err."
> > http://brockerhoff.net/blog/ 
> >
> >
> >
> >
> ___
> 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] [swift-evolution-announce] [Accepted with Revision] SE-0177: Allow distinguishing between public access and public overridability

[David Owens II via swift-evolution]

> On Jul 27, 2016, at 8:52 PM, Xiaodi Wu  wrote:
> 
> On Wed, Jul 27, 2016 at 10:30 PM, David Owens II via swift-evolution 
> mailto:swift-evolution@swift.org>> wrote:
> 
> > On Jul 27, 2016, at 7:18 PM, John McCall  > <mailto:rjmcc...@apple.com>> wrote:
> >
> >
> >> On Jul 27, 2016, at 6:55 PM, David Owens II via swift-evolution 
> >> mailto:swift-evolution@swift.org>> wrote:
> >>
> >> Yes, it’s per file. It’s also added in the initial template that Xcode 
> >> creates with your project. In addition, it’s recommended by many that talk 
> >> about “how to unit test in Swift.” So, to someone that is not paying 
> >> scrupulous attention, there is no mechanism to prevent against this today.
> >
> > Perhaps we're not doing a good job of messaging this.
> >
> > The Xcode template is the way it is because @testable imports are the right 
> > default for a *program* written in Swift.  A lot of the code in an 
> > application or command-line program isn't really suitable for independent, 
> > in-process black-box testing, because it isn't really presenting an 
> > integrated API.  If you break it down into components that can be 
> > independently tested, that's awesome, and at that point you can switch the 
> > imports in your tests over to non-@testable.  But we don't want the test 
> > template to create any obstacles to testing, because as you say, people 
> > already don't write enough tests.
> 
> My primary concern is that it’s easy to think you’ve done the right thing and 
> push out a release because all of your testing shows it’s good, only to find 
> you messed up in a way that it’s easy for a tool to validate. Writing new 
> code is probably not going to be the primary source of this, but refactoring 
> a `public` class to an `open` one, where there are already existing tests for 
> that class, probably in a single file and using `@testable`, it’s easy to 
> say, “looks good, tests passed, integrations look good.”
> 
> If you're refactoring `public` classes into `open` ones, though, you'd be 
> more likely to have forgotten to open a method you intend to make 
> overridable, no? And there's no way to change the rules here to have 
> `@testable` pick that up…

Yes, `@testable` does exactly that. It basically treats the imported module as 
being part of the module it’s being imported into and gives the type all of the 
same access levels. So I’d be able to override a method that is *not* marked as 
open with no issues.

I see nothing in the proposal that restricts a class within the same module 
from subclassing and overriding `public` methods within the *same* module that 
it’s defined in.

So you need to have test cases that have *no* `@testable import ModuleToTest` 
to ensure the API contracts are being tested well. This is John’s point, that 
proper public API (e.g. “black box”) test cases would alleviate this issue from 
happening.

-David

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

Re: [swift-evolution] [swift-evolution-announce] [Accepted with Revision] SE-0177: Allow distinguishing between public access and public overridability

[David Owens II via swift-evolution]

> On Jul 27, 2016, at 7:18 PM, John McCall  wrote:
> 
> 
>> On Jul 27, 2016, at 6:55 PM, David Owens II via swift-evolution 
>>  wrote:
>> 
>> Yes, it’s per file. It’s also added in the initial template that Xcode 
>> creates with your project. In addition, it’s recommended by many that talk 
>> about “how to unit test in Swift.” So, to someone that is not paying 
>> scrupulous attention, there is no mechanism to prevent against this today.
> 
> Perhaps we're not doing a good job of messaging this.
> 
> The Xcode template is the way it is because @testable imports are the right 
> default for a *program* written in Swift.  A lot of the code in an 
> application or command-line program isn't really suitable for independent, 
> in-process black-box testing, because it isn't really presenting an 
> integrated API.  If you break it down into components that can be 
> independently tested, that's awesome, and at that point you can switch the 
> imports in your tests over to non-@testable.  But we don't want the test 
> template to create any obstacles to testing, because as you say, people 
> already don't write enough tests.

My primary concern is that it’s easy to think you’ve done the right thing and 
push out a release because all of your testing shows it’s good, only to find 
you messed up in a way that it’s easy for a tool to validate. Writing new code 
is probably not going to be the primary source of this, but refactoring a 
`public` class to an `open` one, where there are already existing tests for 
that class, probably in a single file and using `@testable`, it’s easy to say, 
“looks good, tests passed, integrations look good.”

> In contrast, a library developer needs to be more conscientious about the 
> difference between black-box and white-box testing.  In fact, they should 
> really be leaning towards making black-box tests whenever that's reasonably 
> practical.  We don't currently have Xcode templates around making Swift 
> libraries, though; I think we all agree that there's a lot of room for tools 
> improvement there.

Just FYI: The default Frameworks target also uses @testable for the Swift unit 
tests.

Regardless, there are mitigations that can turn this potential (maybe it’s not 
even an issue in practice) test-time error into a near compile-time error 
(using a linter).

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

Re: [swift-evolution] [swift-evolution-announce] [Accepted with Revision] SE-0177: Allow distinguishing between public access and public overridability

[David Owens II via swift-evolution]

Yes, it’s per file. It’s also added in the initial template that Xcode creates 
with your project. In addition, it’s recommended by many that talk about “how 
to unit test in Swift.” So, to someone that is not paying scrupulous attention, 
there is no mechanism to prevent against this today.

This also assumes that people write tests… which, well, we know is not the case 
at all.

I guess time will tell if this should be a warning/error or not depending on 
the usage of the various Swift linters that I’m sure will start to become 
prevalent. I know it’s something I’ll be enabling in my code.

It seems this design is acceptable and by-design.

-David


> On Jul 27, 2016, at 6:36 PM, Brent Royal-Gordon  
> wrote:
> 
>> On Jul 27, 2016, at 4:41 PM, David Owens II via swift-evolution 
>>  wrote:
>> 
>> I brought this up in review, but there seems to be a serious testability 
>> problem here because of how special @testable is.
>> 
>> // This class is not subclassable outside of ModuleA.
>> public class NonSubclassableParentClass {
>>// This method is not overridable outside of ModuleA.
>>public func foo() {}
>> 
>>// This method is not overridable outside of ModuleA because
>>// its class restricts its access level.
>>// It is not invalid to declare it as `open`.
>>open func bar() {}
>> 
>>// The behavior of `final` methods remains unchanged.
>>public final func baz() {}
>> }
>> 
>> In a unit test, I *can* subclass `NonSubclassableParentClass`, the access 
>> level of `NonSubclassableParentClass` is irrelevant. There’s now no 
>> programatic way to ensure that I’m actually testing the contract that I had 
>> intended to provide to the consumers of my framework (that my class is 
>> subclassable). Is this really the intention?
> 
> I could be wrong, but isn't `@testable import` applied per-file? So if you 
> keep code users should actually be able to write in one file with a 
> non-`@testable` import, and mocks and other testing hacks in a different file 
> with an `@testable` import, the first file should fail to compile if you use 
> anything that's not normally permitted.
> 
> In a future version of Swift, we might consider refining this by requiring 
> people to apply `@testable` directly to declarations which treat something 
> closed as if it's open, but it seems like even the current feature set does 
> not make testing impossible.
> 
> -- 
> Brent Royal-Gordon
> Architechies
> 

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

Re: [swift-evolution] [swift-evolution-announce] [Accepted with Revision] SE-0177: Allow distinguishing between public access and public overridability

[David Owens II via swift-evolution]

While arguably true, that's a philosophical debate. There are plenty of reasons 
to use @testable, and if that's what people are using, then I think there is a 
valid concern here. 

Sent from my iPhone

> On Jul 27, 2016, at 5:22 PM, John McCall  wrote:
> 
>> On Jul 27, 2016, at 4:41 PM, David Owens II via swift-evolution 
>>  wrote:
>> I brought this up in review, but there seems to be a serious testability 
>> problem here because of how special @testable is.
>> 
>> // This class is not subclassable outside of ModuleA.
>> public class NonSubclassableParentClass {
>> // This method is not overridable outside of ModuleA.
>> public func foo() {}
>> 
>> // This method is not overridable outside of ModuleA because
>> // its class restricts its access level.
>> // It is not invalid to declare it as `open`.
>> open func bar() {}
>> 
>> // The behavior of `final` methods remains unchanged.
>> public final func baz() {}
>> }
>> 
>> In a unit test, I *can* subclass `NonSubclassableParentClass`, the access 
>> level of `NonSubclassableParentClass` is irrelevant. There’s now no 
>> programatic way to ensure that I’m actually testing the contract that I had 
>> intended to provide to the consumers of my framework (that my class is 
>> subclassable). Is this really the intention?
> 
> A "black box" unit test emulating consumer behavior has no business using a 
> @testable import.  It should just use the external API of the library.
> 
> John.
> 
>> 
>> The “fix”, on the authors end, is to create another target that consumes the 
>> output framework to ensure my contract is actually what I wanted (and make 
>> sure that it’s not a special test target!). No one is going to do this.
>> 
>> Sure, maybe a code review might catch it. Or I can write a custom linter to 
>> validate for this. Do we really want `open` members in non `open` types? The 
>> issue with `public` members on `internal` types is much less concerning as 
>> the `internal` type isn’t being exposed to others to begin with.
>> 
>> -David
>> 
>> 
>>> On Jul 27, 2016, at 3:18 PM, Scott James Remnant via swift-evolution 
>>>  wrote:
>>> 
>>> I realize that there’s no review needed, but I actually wanted to give a 
>>> hearty 👏 to the authors and commenters of this proposal, because I 
>>> genuinely think we’ve reached something good in the result.
>>> 
>>> The selling point for me is this:
>>> 
>>> // This is allowed since the superclass is `open`.
>>> class SubclassB : SubclassableParentClass {
>>> // This is invalid because it overrides a method that is
>>> // defined outside of the current module but is not `open'.
>>> override func foo() { }
>>> 
>>> // This is allowed since the superclass's method is overridable.
>>> // It does not need to be marked `open` because it is defined on
>>> // an `internal` class.
>>> override func bar() { }
>>> }
>>> 
>>> This feels super-clean; it gives Library developers `open` for their APIs, 
>>> without confusing app developers, and still requires that sub-classing 
>>> Library developers think about `open`.
>>> 
>>> Good job, everyone!
>>> 
>>> Scott
>>> ___
>>> 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] [swift-evolution-announce] [Accepted with Revision] SE-0177: Allow distinguishing between public access and public overridability

[David Owens II via swift-evolution]

I brought this up in review, but there seems to be a serious testability 
problem here because of how special @testable is.

// This class is not subclassable outside of ModuleA.
public class NonSubclassableParentClass {
// This method is not overridable outside of ModuleA.
public func foo() {}

// This method is not overridable outside of ModuleA because
// its class restricts its access level.
// It is not invalid to declare it as `open`.
open func bar() {}

// The behavior of `final` methods remains unchanged.
public final func baz() {}
}

In a unit test, I *can* subclass `NonSubclassableParentClass`, the access level 
of `NonSubclassableParentClass` is irrelevant. There’s now no programatic way 
to ensure that I’m actually testing the contract that I had intended to provide 
to the consumers of my framework (that my class is subclassable). Is this 
really the intention?

The “fix”, on the authors end, is to create another target that consumes the 
output framework to ensure my contract is actually what I wanted (and make sure 
that it’s not a special test target!). No one is going to do this.

Sure, maybe a code review might catch it. Or I can write a custom linter to 
validate for this. Do we really want `open` members in non `open` types? The 
issue with `public` members on `internal` types is much less concerning as the 
`internal` type isn’t being exposed to others to begin with.

-David


> On Jul 27, 2016, at 3:18 PM, Scott James Remnant via swift-evolution 
>  wrote:
> 
> I realize that there’s no review needed, but I actually wanted to give a 
> hearty 👏 to the authors and commenters of this proposal, because I genuinely 
> think we’ve reached something good in the result.
> 
> The selling point for me is this:
> 
> // This is allowed since the superclass is `open`.
> class SubclassB : SubclassableParentClass {
> // This is invalid because it overrides a method that is
> // defined outside of the current module but is not `open'.
> override func foo() { }
> 
> // This is allowed since the superclass's method is overridable.
> // It does not need to be marked `open` because it is defined on
> // an `internal` class.
> override func bar() { }
> }
> 
> This feels super-clean; it gives Library developers `open` for their APIs, 
> without confusing app developers, and still requires that sub-classing 
> Library developers think about `open`.
> 
> Good job, everyone!
> 
> Scott
> ___
> 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-evolution-announce] [Review #3] SE-0117: Allow distinguishing between public access and public overridability

[David Owens II via swift-evolution]

What is your evaluation of the proposal?
I think the philosophical direction of the proposal is good, though I still 
don’t like the actual implementation details. There are two concepts here:
the ability to subclass
the ability to override members

Having both of these concepts annotated with `open` is confusing as they do 
different things. Marking a class as open does **not** provide the ability to 
override. However, marking a member as `open` would provide the ability to 
override. These are two related but different concepts.

I see no reason why `virtual` should not be used to mark members that are 
inheritable and overridable. That concept is what is taught in schools, that 
concept is what is easily searchable, and that term is well known in the 
computer science field for this very concept. Just do a Google search between 
“open function” and “virtual function”. Deviating from this seems to be counter 
to one of Swift goals of being approachable. Having to learn `open` here is 
just mental noise that makes the coder have to think, “right… this is just a 
virtual method”.

To me, the better approach is:
change `open` to `virtual`
`virtual` is only allowed on inheritable and overridable members (i.e. `var`, 
`func`, and `subscript`)
`virtual` is not permitted on declarations that are explicitly `final` or 
`dynamic`. (Note that it's okay if one or both of the modifiers are implicitly 
inferred.)
A class is made inheritable outside of the module the **only** when the class 
is marked as both `public` and one or members are marked as `virtual` 

Lastly, it’s almost certainly a bug in your code if you mark a member as `open` 
on your public class but forget to annotate your class also with `open`. Worse, 
this error will **only** be caught if you attempt to use this type **outside** 
the context of tests because `@testable` will grant your module the `open` 
class state because `@testable` is special.

The only scenario that this change doesn’t allow would be the ability to 
subclass a class that has no virtual members. In my opinion, this scenario is 
better handled via extensions anyway.

However, **if** this scenario really was desirable, this could later be added 
by allowing `virtual` (or `inheritable` or `open`...) on a class definition. 
However, I would still make the argument that once you have a `virtual` member 
on a type, that the class is implicitly marked as `virtual` as well (see 
reasoning above).

Is the problem being addressed significant enough to warrant a change to Swift?
Yes

Does this proposal fit well with the feel and direction of Swift?
Yes

If you have used other languages or libraries with a similar feature, how do 
you feel that this proposal compares to those?
Yes, many. This proposal’s philosophical direction is more resilient by default.

How much effort did you put into your review? A glance, a quick reading, or an 
in-depth study?
I’ve read the posts, thought about it, experimented, blogged about it.

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

Re: [swift-evolution] [swift-evolution-announce] [Review #2] SE-0117: Default classes to be non-subclassable publicly

[David Owens II via swift-evolution]

> On Jul 19, 2016, at 11:37 AM, L. Mihalkovic via swift-evolution 
>  wrote:
> 
> 
> 
> Regards
> (From mobile)
> 
> On Jul 19, 2016, at 8:19 PM, Goffredo Marocchi via swift-evolution 
> mailto:swift-evolution@swift.org>> wrote:
> 
>> 
>> Sent from my iPhone
>> 
>>> 
>>> Cocoa currently hides the boilerplate for all of these wonderful constructs 
>>> behind amazingly effective runtime acrobatics. This fits perfectly into 
>>> Objective-C, and it also works very well in Swift. But such features could 
>>> be in better harmony with Swift's unique set of language constructs if 
>>> their boilerplate was hidden behind amazingly effective **compile-time** 
>>> acrobatics instead.
>>> 
>>> Such compile-time acrobatics are hard to perform today, and it is possible 
>>> that the ability to create such systems will forever remain an advanced 
>>> skill, just like forging runtime magic requires advanced skills in 
>>> Objective-C.
>> 
>> ... rantish...
>> 
>> I am still not convinced that even the best compiler can fully replace what 
>> a powerful runtime can provide no matter the acrobatics you put in in terms 
>> of compiler introduced utility code/constructs or the code analysis efforts 
>> you can put in at compile time
> 
> That is a fact back by some interesting papers. By it is also true that one 
> cannot always be used in place of the other.

While it is true that the compiler cannot fully replace everything, it can help 
with many types of errors that are hard to catch at runtime.

I’ll reiterate this again: this proposal does *not* prevent Swift from building 
language mechanism to allow for this type of behavior though. The fact is, 
Swift APIs are heavily value or value semantics so the lack of inheritance on 
classes is not going to be the primary reason you cannot monkey patch something.

What this proposal does say is this: there is no “safe” way to achieve this 
type of behavior that the API authors either intentionally left out or left out 
because of an omission. 

If you are subclassing a class in Swift, under this proposal, you can be sure 
of one thing: the author explicitly made it so you’d be able to. We can argue 
if they did so with diligence, but that’s mostly immaterial to the discussion.

The fact is, in order to allow monkey patching, Swift is going to need to 
answer many questions that it still has yet to answer, such as how reflection 
is really going to work. However, with these more restrictive defaults, it’s 
possible to extend the language to provide runtime monkey patching that can be 
more easily audited both in source code and at runtime. Instead of API authors 
just seeing crashes in their libraries and not realizing that someone swizzled 
a method, we would now be able to mark who did the swizzling and which 
functions were actually swizzled.

An example of how this *could* look would be something like this:

struct Person { /* This is defined in module A */
// a bunch of fields
var birthDate: Date { get set }

func calculateAge() -> Int { return 12; }
}

Obviously there is a bug in `calculateAge`. How could we fix it? Well, in your 
app framework (or some other target as needed) as we don’t have the ability to 
fix module A directly:

extension Person {
@replaceMethodImplementation func calculateAge() -> Int { /* better 
implementation */ }
}

This would require support within the Swift language and tooling. For one, we’d 
need the non-optimized code to be distributed so that code within module A used 
this new implementation of `calculateAge`. However, this is the direction I’d 
much rather see Swift go. The ability to annotate code properly as monkey 
patches so we can audit them, track them, version them, and identify them 
clearly both at compile time and runtime.

I’m all for Swift getting the right underlying model. After that, we can 
address a better way to provide the necessary means to monkey patch and change 
behavior, but first the fundamentals need to be nailed properly.

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

Re: [swift-evolution] [swift-evolution-announce] [Review #2] SE-0101: Reconfiguring sizeof and related functions into a unified MemoryLayout struct

[David Owens II via swift-evolution]

What is your evaluation of the proposal?
I’m not in favor of the majority of this proposal (I do support getting rid of 
the *Value versions of the functions). Of the motivations, I find this one to 
be the most awkward:

> Refactoring this proposal to use a single namespace increases 
> discoverability, provides a single entry point for related operations, and 
> enables future expansions without introducing further freestanding functions.

While technically storing stuff under a new type creates a level of indirection 
that we may refer to a namespace, it does so in a way that I’m not terribly 
convinced is even conceptually correct. A new MemoryLayout struct implies there 
is actually a type we are creating here, but that’s not the case: we are simply 
using the type as a hack to get a namespace because Swift lacks support for 
that notion. 

If we must have a struct to achieve this, than at the very least, can’t we move 
all of the generics onto the function call itself?

public struct MemoryLayout {
public static func sizeof(_ x: T.Type) -> Int { return Swift.sizeof(x) }
// ...
}

Further, I find this change to just make readability suffer. Here’s is a random 
snippet found from a GitHub search:

let data = NSData(bytes: &bytes, length:sizeof(CChar) * bytes.count)
let data = NSData(bytes: &bytes, length:MemoryLayout.size * bytes.count)

That’s a lot more typing for what? 

let data = NSData(bytes: &bytes, length:MemoryLayout.sizeof(CChar) * 
bytes.count)

The above actually satisfies the concern, which seems to be primarily that the 
functions are top-level functions instead of namespaced.

Is the problem being addressed significant enough to warrant a change to Swift?
No. Like mentioned in the proposal, these are already low-use terms. As such, 
there is a much prior art for these to turn up search results easily for them 
and their concept apply across multiple languages.

Does this proposal fit well with the feel and direction of Swift?
No. The heart of the proposal seems to be a workaround for the lack of 
namespacing in Swift.

If you have used other languages or libraries with a similar feature, how do 
you feel that this proposal compares to those?
Yes, those languages have better readability around these terms.

How much effort did you put into your review? A glance, a quick reading, or an 
in-depth study?
I’ve read the proposal, looked up code snippets, and tested my own 
implementation within playgrounds.

-David

> On Jul 12, 2016, at 4:53 PM, Chris Lattner  wrote:
> 
> Hello Swift community,
> 
> The second review of "SE-0101: Reconfiguring sizeof and related functions 
> into a unified MemoryLayout struct" begins now and runs through July 19. The 
> proposal is available here:
> 
>   
> https://github.com/apple/swift-evolution/blob/master/proposals/0101-standardizing-sizeof-naming.md
> 
> Reviews are an important part of the Swift evolution process. All reviews 
> should be sent to the swift-evolution mailing list at
> 
>   https://lists.swift.org/mailman/listinfo/swift-evolution
> 
> or, if you would like to keep your feedback private, directly to the review 
> manager.
> 
> What goes into a review?
> 
> The goal of the review process is to improve the proposal under review 
> through constructive criticism and contribute to the direction of Swift. When 
> writing your review, here are some questions you might want to answer in your 
> review:
> 
>   * What is your evaluation of the proposal?
>   * Is the problem being addressed significant enough to warrant a change 
> to Swift?
>   * Does this proposal fit well with the feel and direction of Swift?
>   * If you have used other languages or libraries with a similar feature, 
> how do you feel that this proposal compares to those?
>   * How much effort did you put into your review? A glance, a quick 
> reading, or an in-depth study?
> 
> More information about the Swift evolution process is available at
> 
>   https://github.com/apple/swift-evolution/blob/master/process.md
> 
> Thank you,
> 
> -Chris Lattner
> Review Manager
> 
> 
> ___
> swift-evolution-announce mailing list
> swift-evolution-annou...@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution-announce

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

Re: [swift-evolution] [Review] SE-0117: Default classes to be non-subclassable publicly

[David Owens II via swift-evolution]

> I believe no programmer, least of which myself, can be trusted with the 
> decision to reliably decide ahead of time that this or that class cannot or 
> will not be subclassed.
> So strong -1 for me.

I just don’t get this line of reasoning. Can a programmer be trusted with 
determining if a type should be declared as a struct vs. a class? If I choose 
to implement an API construct with a struct, you’ll be the exact same position 
that this proposal puts you in with classes as well.

I’m a big +1 for this proposal. The default annotations on types should set up 
code to be as future-proof as possible without putting someone in a bad spot 
resilience-wise simply because they forgot to add the restriction before 
shipping.

This proposal also does *not* disallow language features that allow unsafe 
constructs to be added later. Even with this proposal, it’s still possible to 
add the __unsafe_really_subclass_even_though_its_bad construct. It requires 
additional metadata to be kept around by the compiler so that any optimizations 
that may have removed the dynamic dispatching of functions calls through the 
inheritance chain to be kept, but it’s still possible.

-David 


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

Re: [swift-evolution] [Accepted] SE-0111: Remove type system significance of function argument labels

[David Owens II via swift-evolution]

Sent from my iPhone

> On Jul 10, 2016, at 11:24 PM, Austin Zheng  wrote:
> 
> 
>> On Jul 10, 2016, at 11:16 PM, David Owens II  wrote:
>> 
>> Unless you really want to try and get parameter name syntax changed to match 
>> your example:
>> 
>> func doResizeB(image: Image, completed(original:resized:): (Image, Image) -> 
>> Void)
> 
> This is what I had in mind. You would be able to name a value of function 
> type (whether it be a local variable, function argument, or property) with 
> either a simple name (in which case there would be no labels at all), or a 
> compound name with as many semicolons as arguments. Would you have any 
> objection to this?

Would this compound name also affect how functions are referenced? I would 
assume no. 

Also, how do typealiases work then? It's still desirable to not have to couple 
the labels there with the labels within the function declaration. So if:

typealias MyCallback = (original: Image, resized: Image) -> Void

Meant that these were equivalent:

func doResizeB(image: Image, completed(original:resized:): (Image, Image) -> 
Void)

func doResizeB(image: Image, completed: MyCallback)

I probably wouldn't have any real objection. 

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

Re: [swift-evolution] [Accepted] SE-0111: Remove type system significance of function argument labels

[David Owens II via swift-evolution]

> On Jul 10, 2016, at 11:09 PM, Mark Lacey  wrote:
> 
> In the meantime one option here would be to define a nested function that 
> invokes the callback. It results in boilerplate, which is unfortunate, but 
> would work:
> 
> func doResize
> (
>   image: Image,
>   completed completedParam: (original: Image, resized: Image) -> Void
> ) {
>   func completed(original: Image, resized: Image) {
> completedParam(original, resized)
>   }
> 
>   // do lots of work
> 
>   completed(original: image, resized: Image(data: newData, size: newSize))
> }

That doesn’t solve anything; you still have to write the nested function, which 
means you still need to know what the order is. That’s only going to come 
through the documentation or non-compiler verified labels.

It also doesn’t help the call site for `doResize` - you’ll still get the 
non-descript `(Image, Image)` values.

-David

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

Re: [swift-evolution] [Accepted] SE-0111: Remove type system significance of function argument labels

[David Owens II via swift-evolution]

> On Jul 10, 2016, at 10:53 PM, Austin Zheng  wrote:
> 
> 
>> On Jul 10, 2016, at 10:30 PM, David Owens II > > wrote:
 
 I wish the core team or the author of the proposal came to this thread and 
 engaged again with the community. 
>>> 
>>> I'm not inclined to spend time engaging with people who couldn't be 
>>> bothered to give feedback during the week-long official review period.
>> 
>> Not all people "couldn’t be bothered” but had life events, such as moving 
>> across states with four kids, that prevented them from being able to engage 
>> during the official review period. 
> 
> I hope your move went smoothly. More generally, there will always be people 
> with good reasons for not being able to participate in the review process, 
> but the procedure is set: one week of formal discussion, followed by a 
> decision by the core team. If a proposal should be re-reviewed or amended, 
> someone should submit (or at least draft) a follow-up proposal; none of the 
> other proposals that have been accepted have been taken up for re-review by 
> the core team based merely on reviews that were submitted after the review 
> period ended (and there have been at least a few whose acceptance was very 
> controversial).

Sure, the review period is fine. I think it’s unreasonable to say that 
questions, clarifications, or feedback should simply be ignored because it’s 
outside of the review window. If the feature is implemented and checked in, 
fine, but we’re still aways from there.

Regardless, my feedback was more about clarification on what is actually being 
changed for the workflow because I found no real answers in the proposal or the 
thread. I found where some concerns were made, but no real solutions to those 
concerns. Maybe I just overlooked them.

>> I’ve read through all of the posts that I see in my mailbox regarding this 
>> topic and I’ve yet to see any real answer to the concerns of tooling, 
>> typealias usage, closures, and code readability and maintainability concerns 
>> under this new proposal. This is the closest I’ve seen (from Douglas Gregor 
>> a few days ago):
>> 
>>> The core team’s intent is that one can add cosmetic labels to function 
>>> types, but that those labels are not (cannot be) used at the call site, 
>>> e.g.,
>> 
>> Do you have specific post in mind that addresses the these concerns? Maybe 
>> I’m just missing them, but I really don’t see those addressed and they are 
>> not mentioned in the proposal at all.
>> 
>> Let’s say I want to model a problem regarding some library functions that 
>> work with resizing some image type. Today, if I did that, the tooling would 
>> give me auto-completion for all of the parameter labels and the code is very 
>> legible. 
>> 
>> Note that both `original` and `resized` get auto-completed for us here. This 
>> provides great code clarity and insights. This is also self-documenting code.
>> 
>> However, under this proposal as accepted (as I understand it), we are left 
>> with this:
>> 
>> func doResizeC(image: Image, completed: (Image, Image) -> Void) {
>> let newData = image.data
>> let newSize = image.size
> 
> You can still have labels in the type: `completed: (original: Image, resized: 
> Image)`.

Labels that aren’t enforced or checked by the compiler are effectively 
worthless; they may as well be comments. This makes those labels allowed on 
typealiases equally as effective.

I also find it extremely strange that these labels will be allowed as source 
code that can never be verified or used in other places. It seems we are simply 
trading one set of inconsistencies for another.

> 
>> 
>> // do some work that's really slow...
>> 
>> completed(image, Image(data: newData, size: newSize))
> 
> This is definitely a problem. I am considering writing a follow-up proposal 
> that would allow for compound naming of values of function type, which would 
> alleviate this problem: `let foo(x:y:) : (Int, Int) -> Void`, which was 
> brought up a couple of times during the review thread. (This was going to be 
> part of the original proposal, but was removed for various reasons.)

Which just gets you back to this syntax for closures:

func doResizeB(image: Image, completed: (original: Image, resized: Image) -> 
Void)

Unless you really want to try and get parameter name syntax changed to match 
your example:

func doResizeB(image: Image, completed(original:resized:): (Image, Image) -> 
Void)

Or maybe something else… I guess I will have to wait for the proposal.

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

Re: [swift-evolution] [Accepted] SE-0111: Remove type system significance of function argument labels

[David Owens II via swift-evolution]

> On Jul 9, 2016, at 9:08 AM, Austin Zheng via swift-evolution 
>  wrote:
> 
>> On 9 Jul 2016, at 00:53, Jon Shier > > wrote:
>> 
>>> While I can see why removing the labels from the type system would be a 
>>> good idea, I don’t see why calling the functions with labels would be 
>>> actively prohibited. That’s useful information for the developer to have, 
>>> and if the compiler doesn’t know them in some way, you can be assured 
>>> Xcode’s autocomplete won’t see them. 
>> 
>> I wish the core team or the author of the proposal came to this thread and 
>> engaged again with the community. 
> 
> I'm not inclined to spend time engaging with people who couldn't be bothered 
> to give feedback during the week-long official review period.

Not all people "couldn’t be bothered” but had life events, such as moving 
across states with four kids, that prevented them from being able to engage 
during the official review period. 

I’ve read through all of the posts that I see in my mailbox regarding this 
topic and I’ve yet to see any real answer to the concerns of tooling, typealias 
usage, closures, and code readability and maintainability concerns under this 
new proposal. This is the closest I’ve seen (from Douglas Gregor a few days 
ago):

> The core team’s intent is that one can add cosmetic labels to function types, 
> but that those labels are not (cannot be) used at the call site, e.g.,

Do you have specific post in mind that addresses the these concerns? Maybe I’m 
just missing them, but I really don’t see those addressed and they are not 
mentioned in the proposal at all.

Let’s say I want to model a problem regarding some library functions that work 
with resizing some image type. Today, if I did that, the tooling would give me 
auto-completion for all of the parameter labels and the code is very legible. 

struct Size {
var x: Int
var y: Int
}

struct Image {
var data: Data
var size: Size
// lots more properties...
}

typealias ImageResizedCallback = (original: Image, resized: Image) -> Void

func doResizeA(image: Image, completed: ImageResizedCallback) {
let newData = image.data
let newSize = image.size

// do some work that's really slow...

completed(original: image, resized: Image(data: newData, size: newSize))
}

func doResizeB(image: Image, completed: (original: Image, resized: Image) -> 
Void) {
let newData = image.data
let newSize = image.size

// do some work that's really slow...

completed(original: image, resized: Image(data: newData, size: newSize))
}

In either approach, `doResizeA` with a named callback or `doResizeB` with an 
explicit parameter type offer benefits that are lost under this proposal.

let someAsset = Image(data: Data(), size: Size(x: 100, y: 100))

doResizeA(image: someAsset, completed: { (original, resized) in
print("doResizeA - original: \(original), resized: \(resized)")
})

doResizeB(image: someAsset, completed: { (original, resized) in
print("doResizeB - original: \(original), resized: \(resized)")
})

Note that both `original` and `resized` get auto-completed for us here. This 
provides great code clarity and insights. This is also self-documenting code.

However, under this proposal as accepted (as I understand it), we are left with 
this:

func doResizeC(image: Image, completed: (Image, Image) -> Void) {
let newData = image.data
let newSize = image.size

// do some work that's really slow...

completed(image, Image(data: newData, size: newSize))
}

This code is no longer self-documenting. I have no idea at looking at the call 
signature which order the images to `completed` should be.

Further, I get no help here when trying to use it:

doResizeC(image: someAsset) { (<#Image#>, <#Image#>) in
<#code#>
}

What do I label for the two images? This is a workflow regression. Yes, maybe 
the underlying model is more correct. However, this comes at a burden to 
actually authoring and maintaining the code. To me, that’s a truly unfortunate 
cost.

So now I probably write this:

doResizeC(image: someAsset) {
print("doResizeC1 - original: \($0), resized: \($1)")
}

Or, if I happen to know or look-up the order, I can fill in the labels myself:

doResizeC(image: someAsset, completed: { (original, resized) in
print("doResizeC2 - original: \(original), resized: \(resized)")
})

Further, we are able to turn runtime errors into compile-time checks when 
refactoring the signatures in the `doResizeA` and `doResizeB` functions - e.g. 
change the order of `original` and `resized` and you’ll get the compiler 
errors. This no longer happens under this proposal because the labels are 
erased. One way around that is to use types to solve this problem, but Swift 
provides no convenient way to have two `Image` types that share the same 
implementation but are considered as different types (sure, I could box them…).

I can get these benefits back, but now I need 

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0098: Lowercase didSet and willSet for more consistent keyword casing

[David Owens II via swift-evolution]

+1.

If Swift is going to state that keywords need to be lowercased, conjoined 
words, then there should be no exceptions to that rule without some fairly 
significant gain. 

It’s also a fairly low-impact change for any fixit to be run.

-David


> On May 24, 2016, at 11:21 AM, Joe Groff via swift-evolution 
>  wrote:
> 
> didSet and willSet are already contextual rather than formal keywords, and 
> there's a conceivable future where didSet and willSet are no longer keywords 
> at all if we run with the "property behaviors" feature again in the future. 
> If we think that's likely, I'm not sure this intermediate churn is really 
> worth it.
> 
> -Joe
> 
>> On May 24, 2016, at 11:07 AM, Chris Lattner  wrote:
>> 
>> Hello Swift community,
>> 
>> The review of "SE-0098: Lowercase didSet and willSet for more consistent 
>> keyword casing" begins now and runs through May 30. The proposal is 
>> available here:
>> 
>>  
>> https://github.com/apple/swift-evolution/blob/master/proposals/0098-didset-capitalization.md
>> 
>> Reviews are an important part of the Swift evolution process. All reviews 
>> should be sent to the swift-evolution mailing list at
>> 
>>  https://lists.swift.org/mailman/listinfo/swift-evolution
>> 
>> or, if you would like to keep your feedback private, directly to the review 
>> manager.
>> 
>> What goes into a review?
>> 
>> The goal of the review process is to improve the proposal under review 
>> through constructive criticism and contribute to the direction of Swift. 
>> When writing your review, here are some questions you might want to answer 
>> in your review:
>> 
>>  * What is your evaluation of the proposal?
>>  * Is the problem being addressed significant enough to warrant a change 
>> to Swift?
>>  * Does this proposal fit well with the feel and direction of Swift?
>>  * If you have used other languages or libraries with a similar feature, 
>> how do you feel that this proposal compares to those?
>>  * How much effort did you put into your review? A glance, a quick 
>> reading, or an in-depth study?
>> 
>> More information about the Swift evolution process is available at
>> 
>>  https://github.com/apple/swift-evolution/blob/master/process.md
>> 
>> Thank you,
>> 
>> -Chris Lattner
>> Review Manager
>> 
>> 
>> ___
>> swift-evolution-announce mailing list
>> swift-evolution-annou...@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution-announce
> 
> ___
> 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] SE-0084 spinoff: Newlines as item separators

[David Owens II via swift-evolution]

Agreed with all of these points.

I’d personally like to see the ‘,’ disappear altogether, but not piece-wise 
like this.

-David

> On May 18, 2016, at 1:28 AM, David Hart via swift-evolution 
>  wrote:
> 
> -1 I see one big downside. Contrary to statements, which rarely appear on the 
> same line, other list elements are more frequently reformatted, from one line 
> to multiple lines and back. For example, I'll try to find function 
> declarations with too many arguments (formatted on multiple lines) and 
> refactor them to reduce the number of arguments and reformat them on one 
> line. This style refactoring would be made more difficult because it would 
> force me to re-introduce commas if they had been removed. Summary: I'm 
> against this proposal because element lists can be frequently reformatted 
> from one to multiple lines.
> 
> On 17 May 2016, at 20:06, Tino Heth via swift-evolution 
> mailto:swift-evolution@swift.org>> wrote:
> 
>> [Due to popular demand ;-) in the discussion of SE-0084: Allow trailing 
>> commas in parameter lists and tuples]
>> 
>> The option to skip semicolons for statements followed by a newline is only a 
>> tiny convinience, yet it is one of the most favored differences to C (and 
>> one of the most annoying things to remember when you have to switch from 
>> Swift to do some coding in Objective-C).
>> While lists of statements don't need a special separator character anymore, 
>> other lists still rely on commas to separate items:
>> - method parameters
>> - array and dictionary literals
>> - tuples
>> [anything else?]
>> 
>> SE-0084 targets to make it easier to reorder list elements by allowing an 
>> additional comma after the last element; afaics, the same can be achieved by 
>> making all of those commas optional, as long as there is a newline to 
>> separate the next item (without those newlines, SE-0084 makes less sense as 
>> well).
>> 
>> This change is not incompatible with SE-0084, but imho it doesn't make much 
>> sense to combine those features (at least in actual source code).
>> 
>> So, first question:
>> What are the downsides of this change? (question zero is "are there any 
>> other places where comma-separeted lists could be turned into 
>> newline-separated lists?"...)
>> 
>> Tino
>> 
>> ___
>> 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] [Review] SE-0084: Allow trailing commas in parameter lists and tuples

[David Owens II via swift-evolution]

What is your evaluation of the proposal?
+1. Commas are already redundant syntax to provide additional clarity over 
spaces in nearly all use cases. Being strict on this provides no material 
benefit. On the other hand, being super strict about this does have measurable, 
real-world impacts. I can provide examples of days of build time and breaking 
change back-outs because C++ lacks this very feature.

Is the problem being addressed significant enough to warrant a change to Swift?
Yes.

Does this proposal fit well with the feel and direction of Swift?
Yes

If you have used other languages or libraries with a similar feature, how do 
you feel that this proposal compares to those?
Yes. It scales well to large team sizes as well, especially within the context 
of merging code together. The code that used trailing commas never has 
potentially build breaking merges in this same context. However, when merging C 
or C++ code, this is often a headache to deal with this.

How much effort did you put into your review? A glance, a quick reading, or an 
in-depth study?
I’ve read the proposal and used languages both with and without this feature.

-David

> On May 10, 2016, at 11:53 AM, Chris Lattner via swift-evolution 
>  wrote:
> 
> Hello Swift community,
> 
> The review of "SE-0084: Allow trailing commas in parameter lists and tuples" 
> begins now and runs through May 16. The proposal is available here:
> 
>   
> https://github.com/apple/swift-evolution/blob/master/proposals/0084-trailing-commas.md
> 
> Reviews are an important part of the Swift evolution process. All reviews 
> should be sent to the swift-evolution mailing list at
> 
>   https://lists.swift.org/mailman/listinfo/swift-evolution
> 
> or, if you would like to keep your feedback private, directly to the review 
> manager.
> 
> What goes into a review?
> 
> The goal of the review process is to improve the proposal under review 
> through constructive criticism and contribute to the direction of Swift. When 
> writing your review, here are some questions you might want to answer in your 
> review:
> 
>   * What is your evaluation of the proposal?
>   * Is the problem being addressed significant enough to warrant a change 
> to Swift?
>   * Does this proposal fit well with the feel and direction of Swift?
>   * If you have used other languages or libraries with a similar feature, 
> how do you feel that this proposal compares to those?
>   * How much effort did you put into your review? A glance, a quick 
> reading, or an in-depth study?
> 
> More information about the Swift evolution process is available at
> 
>   https://github.com/apple/swift-evolution/blob/master/process.md
> 
> Thank you,
> 
> -Chris Lattner
> Review Manager
> 
> ___
> 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] [Pitch] Including yes/no in stdlib as aliases for true/false

[David Owens II via swift-evolution]

Agreed. -1. 

Sent from my iPhone

> On May 4, 2016, at 1:35 PM, Jordan Rose via swift-evolution 
>  wrote:
> 
> -1 from me. We should not introduce two equivalent spellings for the same 
> thing.
> 
> (Yes, there are sometimes multiple ways to accomplish something, but they are 
> not nearly this close.)
> 
> Jordan
> 
> 
>> On May 4, 2016, at 12:04, Erica Sadun via swift-evolution 
>>  wrote:
>> 
>> I propose adding yes and no to the standard library as aliases for true and 
>> false Boolean values. When answering the questions posed by Boolean 
>> properties and methods, "yes" and "no" may provide better fits than "true" 
>> and "false".  "Should this view be hidden?" "Yes!" "Does this collection 
>> contain the number 2?" "No!". Objective-C solved this by adding macro 
>> equivalents, admittedly with some attendant fuzziness because boolean 
>> implementation details allowed non 0/1 truth values. 
>> 
>> Swift on the other hand has very firm ideas about true and false. Adding yes 
>> and no literal aliases would enhance code readability with little cost. 
>> There's minimal historic support among languages for yes/no but Swift is an 
>> Apple-y kind of language and yes/no is an Apple-y kindness to developers.
>> 
>> I performed a gmane search and did not find a previous thread on this 
>> subject.
>> 
>> -- E
>> 
>> ___
>> 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] #if os(Windows) and MSVC/Cygwin Compatibility

[David Owens II via swift-evolution]

Historically, that's been true. However, I wonder if the new Linux subsystem 
work for Windows changes this. 

https://blogs.msdn.microsoft.com/wsl/2016/04/22/windows-subsystem-for-linux-overview/

And further, will we need a check for this on Windows?

-David

Sent from my iPhone

> On May 3, 2016, at 9:07 AM, Michael Buckley via swift-evolution 
>  wrote:
> 
> I wouldn't personally use a Cygwin or MinGW target these days, but I can see 
> why a Cygwin target would be useful in a Swift context. I suspect most Swift 
> code is either going to be written for iOS/Mac, or Linux server code, 
> including third-party libraries. Lots of Swift code will probably have some 
> POSIX calls that wouldn't otherwise be available on Windows.
> 
>> On Tue, May 3, 2016 at 2:44 AM, hitstergtd+swiftevo--- via swift-evolution 
>>  wrote:
>> Why is there a need to support Cygwin/MingW and their variants as a
>> build target for Windows? MSVC is practically free these days.
>> 
>> Doesn't supporting multiple different ABI targets on Windows just
>> complicate matters unnecessarily? Isn't MSVC enough as a build target?
>> 
>> I am not dejecting; rather, just wondering the actual need.
>> 
>> On 3 May 2016 at 06:00, Sangjin Han via swift-evolution
>>  wrote:
>> > Hello swift-evolution,
>> >
>> > This is continued from PR #2351(https://github.com/apple/swift/pull/2351).
>> >
>> > Here is the brief history. (To avoid confusion, I used MSVC refer to
>> > *-*-windows-msvc and Cygwin refer to *-*-windows-cygnus in LLVM.)
>> >
>> > I needed the #if method to distinct MSVC from Cygwin, for mapping the Int 
>> > to
>> > CLongLong not CLong on MSVC.
>> > In PR #2351, I simply added 'os(Cygwin)' and restrict 'os(Windows)' to
>> > *-*-windows-msvc from *-*-windows-*, this solved my problem.
>> >
>> > Jake(@jakepetroules) pointed out that Cygwin is not an OS and it will never
>> > fixed to avoid breaking user applications.
>> > There is more  participants and opinions, briefly,
>> > - introduce another new one such as 'env(cygnus)' or 'triple(Cygwin)'
>> > - the usability of the common condition 'os(Windows)' for *-*-windows-*
>> > - fundamentally, what do we gain from asking which os() is in use?
>> > - 'env()' is too vague
>> > - what the right questions?
>> >
>> > Forgive me the poor quotations of valuable opinions.
>> >
>> >
>> > I hope we find out the solution or method everybody satisfied.
>> >
>> >
>> > -Han Sangjin
>> >
>> > ___
>> > 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] [Review] SE-0066: Standardize function type argument syntax to require parentheses

[David Owens II via swift-evolution]

You forgot that parentheses are required for labeled closures with type 
information:

x.sorted { (x: Int, y: Int) in x > y }

You'd have to handle that case as well.


x.sorted { x: Int, y: Int in x > y }

I think the above leads to potentially ambiguous parsing constructs. 

Sent from my iPhone

> On Apr 27, 2016, at 1:18 PM, Thorsten Seitz via swift-evolution 
>  wrote:
> 
> 
>> Am 27.04.2016 um 14:16 schrieb Vladimir.S via swift-evolution 
>> :
>> 
>> > But keep away from closure expressions, please! There is nothing ambiguous
>> > there.
>> 
>> Really?
> 
> Ok, you got me there :-)
> I have to clarify: no ambiguity if parentheses would be prohibited around 
> parameter lists in closure expressions like I suggested. 
> Furthermore the current implementation seems to do some auto-(un)splatting 
> which should go away.
> 
>> 
>> func z1(block: (Int,Int) -> Void) {
>>block(1,2)
>> }
>> 
>> z1 { x, y in print(x,y)} //
> 
> (Int, Int) is a parameter list, so this is ok
> 
>> z1 { x in print(x.0, x.1)} // ???
> 
> This should not work IMO as the type is (Int, Int) -> Void where (Int, Int) 
> is a parameter list and not a tuple.
> Seems to be tuple unsplatting at work here.
> 
>> z1 { (x, y) in print(x, y)} //
> 
> This should not work for the given definition of z1 as (x, y) is a tuple.
> 
>> func z2(block: ((Int,Int)) -> Void) {
>>block((1,2))
>> }
>> 
>> z2 { x, y in print(x,y)} // ???
> 
> This should not work IMO (tuple splatting at work here)
> 
>> z2 { x in print(x.0, x.1)}
> 
> Fine, as x is a tuple.
> 
>> z2 { (x, y) in print(x, y)} // ???
> 
> Fine, as (x, y) is a tuple. This raises another issue, though: this is using 
> pattern matching without having to write `let` or `case let`. That’s probably 
> a good thing and I’d rather like to get rid of `let` for bindings in pattern 
> matching in other places.
> 
>> //z2 { ((x, y)) in print(x, y)}  // compilation error
> 
> This should not work IMO as parentheses should not be allowed around argument 
> lists in closure expressions.
> 
>> 
>> // this will compile, but
>> runtime error
>> let ft : (Int,Int) -> Void = { x in print(x)} // hm..
>> ft(1, 2)
> 
> There is no runtime error in my playground.
> The result printed is (1, 2)
> 
> This should not work IMO as the type is (Int, Int) -> Void where (Int, Int) 
> is a parameter list and not a tuple.
> You would have to write
> let ft : (Int,Int) -> Void = { x, y in print(x, y) } // 1 2
> or
> let ft : ((Int,Int)) -> Void = { x in print(x) } // (1, 2)
> 
> 
> To rehash:
> 
> Rules for function type definitions:
> - parentheses are required around argument lists of more than one argument, 
> i.e. (Int, Int) -> Void (same as in SE-0066)
> - parentheses are required around argument lists with a single tuple 
> argument, i.e. ((Int, Int)) -> Void (same as in SE-0066)
> - parentheses are prohibited around single non-tuple arguments, i.e. Int -> 
> Void (different from SE-0066)
> 
> Rule for argument lists in closure expressions:
> - parentheses are prohibited around the argument list (as it is clearly 
> enclosed by `{ … in`, therefore parentheses can only be used for tuples 
> (different from current state)
> 
> This would result in nice unambiguous code without unnecessary parentheses.
> 
> -Thorsten
> 
> 
>> 
>>> On 27.04.2016 11:53, Thorsten Seitz via swift-evolution wrote:
>>> I am strictly against requiring parentheses in closure expressions.
>>> Parentheses are visual clutter if not really needed and for a closure
>>> expression there is no need for parentheses as the parameter list is
>>> already nicely bracketed by `{ ... in`.
>>> Actually I would argue that parentheses around parameter lists in closure
>>> expressions should be prohibited for that reason.
>>> 
>>> I'm not fond of requiring parentheses around single non-tuple parameters in
>>> type declarations either but I could probably grudgingly live with that 
>>> change.
>>> But keep away from closure expressions, please! There is nothing ambiguous
>>> there.
>>> 
>>> -Thorsten
>>> 
>>> 
>>> Am 27. April 2016 um 00:07 schrieb David Owens II via swift-evolution
>>> :
>>> 
>>>> 
>>>>> On Apr 26, 2016, at 1:31 PM, Chris Lattner >>>> <mailto:clatt...@apple.com>> wrote:
>>>>> 
>>>>> 
>>>>>> On Apr 25, 2016, at 11:28 PM, David Owens II via s

Re: [swift-evolution] [Review] SE-0066: Standardize function type argument syntax to require parentheses

[David Owens II via swift-evolution]

> On Apr 26, 2016, at 1:31 PM, Chris Lattner  wrote:
> 
> 
>> On Apr 25, 2016, at 11:28 PM, David Owens II via swift-evolution 
>> mailto:swift-evolution@swift.org>> wrote:
>> 
>> What is your evaluation of the proposal?
>> I reluctantly agree with the proposal with the following caveat: I do not 
>> agree with the rationale to support being able to choose to omit the () for 
>> the parameter list of the closure declaration.
>> 
>> I see no cohesive argument that says that the parens should be required in 
>> some cases but not in others when talking about parameter lists.
>> 
>> I believe the proposal should be amended that the following should be the 
>> only allowable forms:
> 
> Hi David,
> 
> To be clear, this proposal is not about changing closure expressions, it was 
> just a FAQ, and the section at the end is simply my personal opinion.  
> Changing closure expression syntax would be a separate proposal.

My argument is changing the parameter list in one context but not the other is 
only solving one of the potentially ambiguous use cases instead of the general 
case. My opinion is they should be changed as the same time if they are going 
to be changed at all.

-David

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

Re: [swift-evolution] [Review] SE-0066: Standardize function type argument syntax to require parentheses

[David Owens II via swift-evolution]

What is your evaluation of the proposal?
I reluctantly agree with the proposal with the following caveat: I do not agree 
with the rationale to support being able to choose to omit the () for the 
parameter list of the closure declaration.

I see no cohesive argument that says that the parens should be required in some 
cases but not in others when talking about parameter lists.

I believe the proposal should be amended that the following should be the only 
allowable forms:

y = x.sorted { (lhs : Int, rhs : Int) -> Bool in rhs < lhs }
y = x.sorted { (lhs, rhs) in rhs < lhs }
y = x.sorted { $1 < $0 }

I’ve bolded the change above, today this is allowable:

y = x.sorted { lhs, rhs in rhs < lhs }

I’ve read the argument about why it’s ok to elide the parens here, I simply 
disagree with the author’s premise that this is a structurally significant 
different form. Not requiring the parens for this parameter list begs the 
question why other forms require them and provides a similar ambiguity of 
whether the closure takes two parameters or a single tuple parameter from both 
of these valid syntaxes today:

y = x.sorted { lhs, rhs in rhs < lhs }
y = x.sorted { (lhs, rhs) in rhs < lhs }

I don’t see how this is fundamentally different than the example in the 
“Motivation” section:

(Int, Float) -> Int // Takes two arguments, or takes one two-argument tuple?

While I will concede that `(lhs, rhs)` is not a valid tuple declaration, I’d 
still argue that it’s too subtle of a difference to be used a primary means of 
justification. If we are going to remove the ambiguity, let’s remove it for all 
parameter list scenarios.

Is the problem being addressed significant enough to warrant a change to Swift?
Potentially.

Does this proposal fit well with the feel and direction of Swift?
Yes.

How much effort did you put into your review? A glance, a quick reading, or an 
in-depth study?
I participated in the original discussion thread as well as tested out many 
different combinations function and closure syntax in the Swift Playground.

-David



> On Apr 25, 2016, at 9:22 PM, Douglas Gregor via swift-evolution 
>  wrote:
> 
> Hello Swift community,
> 
> The review of SE-0066 "Standardize function type argument syntax to require 
> parentheses" begins now and runs through May 2, 2016. The proposal is 
> available here:
> 
> https://github.com/apple/swift-evolution/blob/master/proposals/0066-standardize-function-type-syntax.md
>  
> 
> Reviews are an important part of the Swift evolution process. All reviews 
> should be sent to the swift-evolution mailing list at
> 
> https://lists.swift.org/mailman/listinfo/swift-evolution 
> 
> or, if you would like to keep your feedback private, directly to the review 
> manager. When replying, please try to keep the proposal link at the top of 
> the message:
> 
> Proposal link:
> 
> https://github.com/apple/swift-evolution/blob/master/proposals/0066-standardize-function-type-syntax.md
>  
> 
> Reply text
> 
> Other replies
>  What 
> goes into a review?
> 
> The goal of the review process is to improve the proposal under review 
> through constructive criticism and, eventually, determine the direction of 
> Swift. When writing your review, here are some questions you might want to 
> answer in your review:
> 
> What is your evaluation of the proposal?
> Is the problem being addressed significant enough to warrant a change to 
> Swift?
> Does this proposal fit well with the feel and direction of Swift?
> If you have used other languages or libraries with a similar feature, how do 
> you feel that this proposal compares to those?
> How much effort did you put into your review? A glance, a quick reading, or 
> an in-depth study?
> More information about the Swift evolution process is available at
> 
> https://github.com/apple/swift-evolution/blob/master/process.md 
> 
> Thank you,
> 
> Doug Gregor
> 
> Review Manager
> 
> 
> ___
> 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] [Discussion] Enforce argument labels on tuples

[David Owens II via swift-evolution]

> On Apr 20, 2016, at 4:47 PM, Chris Lattner  wrote:
> 
> On Apr 20, 2016, at 12:31 PM, David Owens II via swift-evolution 
> mailto:swift-evolution@swift.org>> wrote:
>> This is similar to another concern I raised with functions and being able to 
>> essentially erase the function argument names and apply two different named 
>> parameters just because their types match.
>> 
>> It seems reasonable to me that you can go from (x: Int, y: Int) => (Int, 
>> Int). However, going from (x: Int, y: Int) => (a: Int, b: Int) feels 
>> somewhat odd. Yes, the types can obviously slot in there fine, but how much 
>> importance do the labels for the types bring to the table?
>> 
>> Similarly, should this (Int, Int) => (x: Int, y: Int) be allowed through an 
>> implicit means? If so, then it's really just an intermediate step for (x: 
>> Int, y: Int) => (a: Int, b: Int) working.
> 
> I completely agree, I think it makes sense to convert from unlabeled to 
> labeled (or back) but not from “labeled" to "differently labeled”.
> 
>> So what matters more, type signatures or label names?
>> 
>> Here's an example:
>> 
>> typealias Functor = (left: Int, right: Int) -> Int
>> 
>> func hi(x: Int, y: Int, fn: Functor) -> Int {
>> return fn(left: x, right: y)
>> }
>> 
>> hi(1, y: 2, fn: +)
>> hi(1, y: 2, fn: *)
>> 
>> If we say that the parameter names are indeed vital, then the above code 
>> cannot work as the operators that match the type signature are defined as: 
>> 
>> public func +(lhs: Int, rhs: Int) -> Int
>> 
>> Obviously, given a name to the parameter brings clarity and can be self 
>> documenting, but if we want the above to work while making names just as 
>> vital as the type signature, then we need to declare `Functor` as such:
>> 
>> typealias Functor = (_ left: Int, _ right: Int) -> Int
>> 
>> However, that's not even legal code today, and even if it were, is that 
>> really better?
> 
> I don’t think this follows, since operator parameters are always unlabeled.  
> I suspect we don’t reject it, but I’d be in favor of rejecting:
> 
> func +(lhs xyz: Int, rhs abc: Int) -> Int { }

So maybe I think about this incorrectly, but I always think of any parameter 
without an explicit label to have one that is equal to the parameter name. So 
these two functions signatures would be equivalent:

func sum1(lhs: Int, rhs: Int) -> Int
func sum2(lhs lhs: Int, rhs rhs: Int) -> Int

It’s only when you explicit “erase” the label where there is none:

func sum(_ lhs: Int, _ rhs: Int) -> Int

So back to the example above, it’s still somewhat odd that all of these are 
valid:

hi(1, y: 2, fn: sum1)
hi(1, y: 2, fn: sum2)
hi(1, y: 2, fn: sum)   // makes the most sense, no label to labeled promotion

But if we did reject the differently labeled version, that would mean that we 
would need to declare the `Functor` above as:

typealias Functor = (Int, Int) -> Int

Is that better? I’m not terribly convinced that it is.

If `Functor` keeps the labels, I suspect it would just lead to additional 
boiler-plate code that would look like:

typealias Functor = (left: Int, right: Int) -> Int

hi(1, y: 2, fn: { left, right in sum1(lhs: left, rhs: right) })

While it does seem technically correct, is that really the kind of code we want 
in Swift? 

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

Re: [swift-evolution] [Discussion] Enforce argument labels on tuples

[David Owens II via swift-evolution]

This is similar to another concern I raised with functions and being able to 
essentially erase the function argument names and apply two different named 
parameters just because their types match.

It seems reasonable to me that you can go from (x: Int, y: Int) => (Int, Int). 
However, going from (x: Int, y: Int) => (a: Int, b: Int) feels somewhat odd. 
Yes, the types can obviously slot in there fine, but how much importance do the 
labels for the types bring to the table?

Similarly, should this (Int, Int) => (x: Int, y: Int) be allowed through an 
implicit means? If so, then it's really just an intermediate step for (x: Int, 
y: Int) => (a: Int, b: Int) working.

So what matters more, type signatures or label names?

Here's an example:

typealias Functor = (left: Int, right: Int) -> Int

func hi(x: Int, y: Int, fn: Functor) -> Int {
return fn(left: x, right: y)
}

hi(1, y: 2, fn: +)
hi(1, y: 2, fn: *)

If we say that the parameter names are indeed vital, then the above code cannot 
work as the operators that match the type signature are defined as: 

public func +(lhs: Int, rhs: Int) -> Int

Obviously, given a name to the parameter brings clarity and can be self 
documenting, but if we want the above to work while making names just as vital 
as the type signature, then we need to declare `Functor` as such:

typealias Functor = (_ left: Int, _ right: Int) -> Int

However, that's not even legal code today, and even if it were, is that really 
better?

So I'm mixed on the idea. I think the idea that type coercions happening for 
matching type signatures is very powerful, and this just happens to be one of 
the example manifestations of that.

-David

> On Apr 20, 2016, at 6:23 AM, Adrian Zubarev via swift-evolution 
>  wrote:
> 
> I would like to discuss about the following topic.
> 
> Wouldn't it be better to enforce argument labels on tuples types, if the 
> tuple type defines them?
> 
> ```swift
> 
> func foo(tuple: (a: Int, b: Int)) { /* do something */ }
> 
> let test1 = (10, 100)
> let test2: (a: Int, c: Int) = test
> let test3: (Int, Int) = test2
> 
> foo(test1)
> foo(test3)
> 
> /*
> cannot convert value of type '(a: Int, c: Int)' 
> to expected argument type '(a: Int, b: Int)'
> */
> foo(test2) 
> 
> ```
> 
> Function `foo` awaits a tuple of type `(a: Int, b: Int)` but `test1` and 
> `test3` are both just of type `(Int, Int)`.
> As expected `test2` will raise an error because it has indeed a wrong type 
> `(a: Int, c: Int)`.
> 
> I'd suggest to enforce argument labeling on tuple types for better 
> readability, because wasn't it the idea behind labels inside tuples?
> 
> `foo(test1)` should raise an error `cannot convert value of type '(Int, Int)' 
> to expected argument type '(a: Int, b: Int)'` as long as `test1` is not 
> written like `let test1 = (a: 10, b: 100)` or `let test1: (a: Int, b: Int) = 
> (a: 10, b: 100)`
> 
> This will impact current codebase if you used labels but provided tuples 
> without labels like the example above. The migrator could solve this by 
> providing labels automatically to tuples where this error occurs.
> 
> I'm not good at writing proposals for the GitHub repository at all, so if the 
> community likes this idea, I'd be glad to see some help for this little 
> proposal.
> 
> -- 
> Adrian Zubarev
> Sent with Airmail
> ___
> 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] [pitch] Eliminate the "T1 -> T2" syntax, require "(T1) -> T2"

[David Owens II via swift-evolution]

I have a different read of the proposal I guess... I actually find that this:

(Int, Int) -> (Int, Int)

Naturally reads take a single pair (e.g. tuple) of (Int, Int) and return a 
single pair of (Int, Int)

This actually looks and feels like the right implementation to me:

let tx: (Int, Int) -> (Int, Int) = { ($0.1, $0.0) }

And I am saying that this would be explicitly wrong:

let tx: (Int, Int) -> (Int, Int) = { ($1, $0) }

If I wanted a type signature of that took two Int params, I would expect to 
write this:

let tx: Int, Int -> (Int, Int) = { ($1, $0) }

That reads, a type signature that takes two Int values and returns a single 
(Int, Int) pair.

The problem, to me at least, is that the function declaration overloads the 
meaning of () as "start of parameter list for function declaration".

func tx((Int, Int)) -> (Int, Int) { return ($0.1, $0.0) }

So now you have this mess to say the same thing: take a single pair of Int and 
return a pair of Int.

Similarly, if the () are going to required for parameter lists in function 
declarations, I really struggle to see why these two forms should mean the same 
thing:

y = x.sorted { (lhs, rhs) in rhs < lhs }
y = x.sorted { lhs, rhs in rhs < lhs }

Dropping the type signatures because that can be inferred is one thing, but 
changing the structure of the parameter list seems like an orthogonal 
optimization.

y = x.sorted { (lhs : Int, rhs : Int) -> Bool in rhs < lhs }
y = x.sorted { (lhs, rhs) in rhs < lhs }
{ $1 < $0 }

This process keeps the structural elements while dropping all of the type 
pieces and maintains the consistency that in function types (regardless of how 
they are defined), the () denotes a parameter list. If you actually want a 
tuple within the parameter list, you need to do `((lhs, rhs))`.

-David

> On Apr 19, 2016, at 9:24 AM, Erica Sadun via swift-evolution 
>  wrote:
> 
> 
>> On Apr 19, 2016, at 9:44 AM, David Rönnqvist > > wrote:
>> 
>> Would this also affect the syntax for naming closure arguments? For example, 
>> would this (taken from "The Swift Programming Language (Swift 2.2)”):
>>   reversed = names.sort( { s1, s2 in return s1 > s2 } )
>> have to be written like this:
>>   reversed = names.sort( { (s1, s2) in return s1 > s2 } )
>> or is that a different syntax?
>> 
>> As a developer focused on _writing_ and _reading_ code like this, I don’t 
>> see the real benefits of this change. It only feels natural to me that I 
>> would be able to omit the parentheses when there is only one type, but that 
>> I would need them to group multiple arguments or to label arguments.
>> 
>> That said, I don’t feel strongly about it and the work of transitioning our 
>> code would be minimal. If this change provides other engineering benefits 
>> that aren’t noticeable on the surface, then I’m positive to the change for 
>> those reasons.
>> 
>> - David
> 
> It would not affect the closure syntax. To paraphrase Chris:
> No. Swift’s syntactic shortcuts in its closure parameter lists benefit simple 
> functional algorithms. Few people would choose to write fully specified 
> long-form declarations when, for example, reverse-sorting an array of 
> integers:
> 
> y = x.sorted { (lhs : Int, rhs : Int) -> Bool in rhs < lhs }
> Compare the long form with this simpler form:
> 
> y = x.sorted { lhs, rhs in rhs < lhs }
> You can use the even shorter form of { $1 < $0 }. 
> 
> Closures offer a structurally distinct class of syntactic sugar: 
> 
> You may elide parentheses (even with multiple arguments)
> You may omit the return type
> You may omit types
> You may omit the parameter list in its entirety
> Short of a complete rethink of closure syntax, requiring parentheses there 
> would not improve the language in any measurable way.
> 
> ___
> 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] [pitch] Eliminate the "T1 -> T2" syntax, require "(T1) -> T2"

[David Owens II via swift-evolution]

> On Apr 19, 2016, at 7:49 AM, Erica Sadun via swift-evolution 
>  wrote:
> 
> 
>> On Apr 18, 2016, at 4:31 PM, Dave Abrahams via swift-evolution 
>> mailto:swift-evolution@swift.org>> wrote:
>> 
>> 
>> on Fri Apr 15 2016, Brent Royal-Gordon > > wrote:
>> 
 Given all this, I think it makes sense to go for syntactic
 uniformity between parameter list and function types, and just
 require parenthesis on the argument list.  The types above can be
 trivially written as:
 
 (Int) -> Float
 (String) -> ()
 
 Thoughts?
>>> 
>>> While it's technically correct, I agree with John's assessment that
>>> this is "fussy". `T -> U` doesn't confuse people 
>> 
>> Do we have any data on this (in either direction)?
>> 
>> Personally, it has always seemed obvious that T -> U being a function
>> type would be quite novel to some people, considering the number of
>> times I've seen in Haskell texts that (surprise!) you don't need
>> parentheses to invoke functions.  I guess those are invocations and
>> we're talking about declarations here, but declaration-follows-use is a
>> kind of principle the language tries to uphold.
>> 
>> But that's just intuition.  Data would be very interesting.
> 
> Apart from intuition and confusion, parentheses are used at call sites
> and declarations. It seems out of line that they can be removed in types 
> but only in one degenerate case.
> 
> This goes against the Swift core design goal of consistency.

For the sake of consistency, would you also support the requirement of `-> 
Void` on functions that return nothing? There are a few different ways to 
declare function signatures, one of which requires the return type, the other 
can default one for, in the "degenerate case".

Example:

typealias Callback = () -> Void // return type required
let f: () -> Void = {}  // return type required

func g() {} // return type optional
func h() -> Void {} // should this be required?

I think it's clear from this example, that consistency is not always the most 
important thing.

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

Re: [swift-evolution] [pitch] Eliminate the "T1 -> T2" syntax, require "(T1) -> T2"

[David Owens II via swift-evolution]

> On Apr 15, 2016, at 1:07 PM, Chris Lattner  wrote:
> 
> 
>> On Apr 15, 2016, at 11:27 AM, David Owens II > > wrote:
>> 
>> Hmm... I don't think this is clearer:
>> 
>> let fn: (Int) -> (Int) -> Int
>> 
>> I think it's much less readable and really, the () are syntactically 
>> redundant: the -> is really what distinguishes this as a function.
>> 
>> Also, this would look like a error now:
>> 
>> let fn: (Int) -> ()
>> 
>> Did the user mean that it returns nothing, or did they forget the rest of 
>> the function signature?
> 
> Hi David,
> 
> I’m not sure what you’re saying here.  The two types above are already valid, 
> and this proposal doesn’t affect that.
> 
> -Chris

At the core, I guess it’s just a dislike of the different behaviors for 
function declarations in the system in general. Your propose just exposes a 
weirdness with empty parameter lists and the typealias for void: ().

It’s a bit odd that the () mean different things depending on the side of the 
“->” they are on. The left side is an empty parameter list, the right side is a 
void type.

Now, I get your argument is to get rid of the difference between:

let f: Int -> ()
let g: (Int, Int) -> ()

I guess I’m more of the opinion of David Hart, this change should also remove 
the typealias for () being void.

let f: (Int) -> Void
let g: (Int, Int) -> Void


Overall, I think the change is ok, but doesn’t really add any significant 
clarity to function declarations. I feel like there are already a lot of 
weirdness in general around them.

See:

typealias Functor = (to: Int, from: Int) -> Int
let g: (hi: Int, bye: Int) -> Int = { $0 - $1 }

func sum(x: Int, y: Int) -> Int {
return x + y
}

func mult(x: Int, y: Int) -> Int {
return x * y
}

func f(n: Int, _ m: Int, _ c: Functor) -> Int {
return c(to: n, from: m)
}


f(1, 2, sum)// output: 3
f(1, 2, mult)   // output: 2
f(1, 2, g)  // output: -1

It’s weird to me that we can essentially erase the parameter names and fallback 
to just the type signatures, but that can be a talk for another day.

-David

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

Re: [swift-evolution] [pitch] Eliminate the "T1 -> T2" syntax, require "(T1) -> T2"

[David Owens II via swift-evolution]

Hmm... I don't think this is clearer:

let fn: (Int) -> (Int) -> Int

I think it's much less readable and really, the () are syntactically redundant: 
the -> is really what distinguishes this as a function.

Also, this would look like a error now:

let fn: (Int) -> ()

Did the user mean that it returns nothing, or did they forget the rest of the 
function signature?

I'd like to see more consistency and less redundancy, including special cases, 
in the language in general, but this change just seems to make it different in 
another way, but still not consistent throughout the language constructs.

-David


> On Apr 14, 2016, at 9:57 PM, Chris Lattner via swift-evolution 
>  wrote:
> 
> We currently accept function type syntax without parentheses, like:
> 
>  Int -> Float
>  String -> ()
> 
> etc.  The original rationale aligned with the fact that we wanted to treat 
> all functions as taking a single parameter (which was often of tuple type) 
> and producing a tuple value (which was sometimes a tuple, in the case of void 
> and multiple return values).  However, we’ve long since moved on from that 
> early design point: there are a number of things that you can only do in a 
> parameter list now (varargs, default args, etc), implicit tuple splat has 
> been removed, and  the compiler has long ago stopped modeling function 
> parameters this way.  Beyond that, it eliminates one potential style war.
> 
> Given all this, I think it makes sense to go for syntactic uniformity between 
> parameter list and function types, and just require parenthesis on the 
> argument list.  The types above can be trivially written as:
> 
>  (Int) -> Float
>  (String) -> ()
> 
> Thoughts?
> 
> -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] [Proposal] Invert the order of pattern match operator

[David Owens II via swift-evolution]

It would be nice to know the rationale behind the choice of the current syntax. 
I agree that these seem more natural:

@warn_unused_result
public func ~=(value: I, pattern: 
Range) -> Bool

@warn_unused_result
public func ~=(value: I.Bound, pattern: I) -> Bool

I would not change from `~=` to `=~` though.

So you have this:

let x = 4

switch x {
case let v where x ~= 0...5: print("matched: \(v)")
default: print("nothing!!")
}

-David

> On Apr 7, 2016, at 4:57 AM, David Rodrigues via swift-evolution 
>  wrote:
> 
> Hi all,
> 
> Swift has a pattern match operator, ~=, which is unknown to many (like me 
> until a few weeks ago), that performs a match between a value and a certain 
> pattern, e.g. checking if an integer value is contained in a range of 
> integers.
> 
> This operator may be little known, but it plays a key role in the language 
> since it's used behind the scenes to support expression patterns in `switch` 
> statement case labels, which we all know are extremely popular.
> 
> let point = (2, 4)
> switch point {
> case (0, 0):
> print("The point is at the origin")
> case (0...4, 0...4):
> print("The point is in the subregion")
> default:
> break
> }
> 
> Most of the time we don't use the operator directly but it is available and 
> can be handy in certain conditions.
> 
> let point = (2, 4)
> switch point {
> case (let x, let y) where 0...4 ~= x && 0...4 ~= y:
> print("The point is in the subregion")
> default:
> break
> }
> 
> However the current syntax is not ideal (in my opinion). We're not really 
> declaring the operation that we want to do, and that has an impact in the 
> expressivity and readability of the code. Currently we're doing matches like 
> "if blue is the ocean" instead of "if the ocean is blue" or "if the ocean 
> contains the whale" instead of "if the whale is in the ocean".
> 
> For that reason, I would like to suggest inverting the order of the operator 
> to match more closely our logical thought.
> 
> case (let x, let y) where x =~ 0...4 && y =~ 0...4: // Proposed
> // vs
> case (let x, let y) where 0...4 ~= x && 0...4 ~= y: // Current
> 
> I have an ongoing proposal to suggest this change and it contains a little 
> more context. It is available here: 
> 
> https://github.com/dmcrodrigues/swift-evolution/blob/proposal/invert-order-of-pattern-match-operator/proposals/-invert-order-of-pattern-match-operator.md
>  
> .
> 
> Any feedback is very welcome.
> 
> Thank you.
> 
> David Rodrigues
> ___
> 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] Revisiting 0004 etc. - Swift deprecations

[David Owens II via swift-evolution]

The C99 spec changed the scoping rules to address the very issue you are asking 
about having any "real-world impact".

Yes, the variable outside does matter. It's why you see some code like this, 
even with C++ because it used to not scope locally there too with all compilers:

{for (int i= 0; i<10; i++) { ... }}

And as fully explained in the previous threads on the topic, the defer pattern 
is an insufficient mechanism to generically be used for all c-style for loop 
constructs. 

-David

Sent from my iPad

> On Apr 2, 2016, at 7:35 PM, David Sweeris via swift-evolution 
>  wrote:
> 
> 
>> On Apr 2, 2016, at 20:49, Charles Srstka via swift-evolution 
>>  wrote:
>> 
>> While this style works, and definitely can substitute for a classical for 
>> loop, it is not quite as nice, because it cannot limit i’s scope to the 
>> loop. The variable will be visible outside of the loop body.
> 
> I agree it's not as nice aesthetically, but does the loop variable being 
> visible outside the loop cause any real-world problems?
> 
> - 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] SE-0025: Scoped Access Level, next steps

[David Owens II via swift-evolution]

> On Mar 29, 2016, at 10:18 AM, Jordan Rose  wrote:
> 
> A good handful of people already enumerated several cases where file-based 
> scoping is useful, and I very much agree. Leaking helper operations across an 
> entire module just because they can't be lexically scoped, or don't make 
> sense to, doesn't seem like a good answer to me.

I know, I'm one of them.

However, this thread is fairly disconcerting about how granular many of the 
suggestions are heading towards. We can try to solve for all of the cases or we 
can provide mechanism that works well for the majority of cases. I'm actually 
in the camp of keeping the levels as they are. There is always going to be some 
level of leakage unless you provide a mechanism to provide very explicit access 
control modifiers.

The question at the heart of this proposal is how "correct" is Swift really 
going to be in defining access control modifiers?

One can argue that file-based access control is required, for many use cases, 
because it's not possible to limit usage to be "more correct". If I want to 
expose the private details of my type to an extension, how do I do that? Today, 
file-based, but tomorrow, is there a `protected` for this? What about only to 
all extensions within the module? Is that `protected internal`? Is there a way 
to limit the extensions that can have access to the privates, because there are 
real scenarios for that as well?

Then we need to go down the rabbit-hole for type-based access control modifiers 
as well, though maybe that's already alluded to with the extensions example, so 
we get `protected` and `protected internal` there as well.

So this gives us public, internal, private, file-based, protected 
(protocol/extension based), protected (inheritance based), protected internal 
(protocol/extension based), and protected internal (inheritance based). 

And let's not forget the desire to share privates with others that are not in 
our access control scope, so we're back to needing something like `friend` to 
essentially merge other types into the same access control scope.

I really feel like I'm watching the evolution of C++ access modifiers in Swift. 
If that's the route the language and community wants to go, then ok. However, 
if Swift is really going to re-look at access levels, just looking at scoped 
access levels does not seem sufficient; it solves one, very narrow case, while 
ignoring many of the other cases. 

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

Re: [swift-evolution] SE-0025: Scoped Access Level, next steps

[David Owens II via swift-evolution]

> Additionally, we think we can get away with renaming "private" because most 
> current uses of "private" (file-scoped) declarations are within the same 
> (brace-bound) scope anyway;

A quick look through my code bases verifies that this is true with my small 
sample of code. The only outliers are private members on types accessed by 
extensions, but those are fairly rare in my use cases, and arguably, those 
should be changed to internal. Maybe that varies for others.

Honestly, if the assertion is already that most of the current private use 
cases are for lexically scoped uses anyway, is it really worth trying to add a 
file-based private as well that essentially pops out of the lexical scope only 
up to the file level? For those use cases, just use `internal`. Using `private` 
would still be available for top-level declarations on the file.

We would end up with just this:

`public` - publicly exported for use by all code that uses the library
`internal` - only allowed for use within the current module
`private` - the new, lexically scoped modifier

If file-based is really required for a small set of cases, use `private 
internal`.

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

Re: [swift-evolution] SE-0025: Scoped Access Level, next steps

[David Owens II via swift-evolution]

I have types where I declare their members (some public, some private) and use 
extensions to provide the API implementations of protocols. 

These implementations use data that is not public to the type. A file-based 
access level is the only one that works for me. 

This is actually the common case for me. 

Sent from my iPhone

> On Mar 25, 2016, at 10:11 AM, Erica Sadun via swift-evolution 
>  wrote:
> 
> 
>> On Mar 25, 2016, at 10:57 AM, Tino Heth via swift-evolution 
>>  wrote:
>> 
>> 
>>> These are special cases — both file-private and module-private is something 
>>> that is fairly unusual
>> 
>> afaics this is the third time someone mentions that "file-private" is 
>> uncommon — so I think it's time someone dissents:
>> That statement is at least subjective… right now, "file-private" is one of 
>> three access levels, and I wouldn't dare to say either is more or less 
>> important than the others.
>> 
>> I never encountered situations with the current model where I missed a new 
>> "private"-level, and maybe "private" will become fairly unusual for the code 
>> I'll be writing.
>> 
>> In my existing code, the new meaning of private wouldn't break much, but the 
>> current meaning doesn't hurt me, and there are cases where "file-private" is 
>> needed.
>> 
>> None the less, I don't care much about the "ugliness" of "fileprivate" — but 
>> not because I perceive it as unusual:
>> I just expect that code completion will do the typing for me, so maybe "f" 
>> will be all I have to write (half the characters of "pr" ;-)
> 
> I cannot come up with a single use-case in my code for fileprivate and would 
> love
> some real world examples where you'd want visibility in a single file but not 
> across
> an entire module.
> 
> The fileprivate behavior has been a bugaboo of mine for some time, 
> particularly in 
> playground use. 
> 
> As far as I'm concerned, the control I really want is public,  intra-modular, 
> private, and 
> private-even-to-extensions-and-subclasses. I assume the latter is a no-go.
> 
> -- E
> 
> 
> 
> 
> ___
> 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] SE-0025: Scoped Access Level, next steps

[David Owens II via swift-evolution]

> On Mar 25, 2016, at 9:15 AM, Jordan Rose via swift-evolution 
>  wrote:
> 
> 
>> On Mar 24, 2016, at 16:20 , Erica Sadun via swift-evolution 
>> mailto:swift-evolution@swift.org>> wrote:
>> 
>>> 
>>> On Mar 24, 2016, at 5:13 PM, Brent Royal-Gordon >> > wrote:
>>> 
 I think it does. `module` could mean many things related to how Swift 
 creates and consumes modules. 
 `moduleprivate` combines something about access levels (public/private) 
 and scope (module), is easy to 
 Google, offers few "wrong" interpretations. By using a longer keyword, it 
 is less flexible in meaning and 
 more fixed in purpose.
>>> 
>>> Sure, but is that worth 7 to 9 extra characters at every single use site 
>>> for something that's actually pretty common? Is it worth the muddled mess 
>>> of an all-lowercase keyword with no obvious break, or the 
>>> attention-grabbing of a capital letter or an underscore?
>>> 
>>> `module` and `file` are not going to be obscure corners of the language. 
>>> Most people will probably learn about them at the same time they learn 
>>> about `public` and `private`. 
>>> 
>>> (Actually, if `module` continues to be the default, you probably won't see 
>>> it *that* often. You *will* see `file`, but that's the one that can't be as 
>>> easily confused with a declaration.)
>>> 
>>> Obviousness for new users is great, but you can take it too far. We call 
>>> the type `Int32`, not 
>>> `SignedIntegerBetweenNegative2ToThe31stPowerAnd2ToThe31stPowerMinus1`—and 
>>> if we did, it's not clear the longer name would really be more obvious, 
>>> because it would be such a pain to read.
>> 
>> 
>> `moduleprivate` is the default value. I doubt it will get  used much if at 
>> all. I don't think `fileprivate` will get used much either
>> but in such cases, I think those seven extra letters are essential and 
>> documenting.
>> 
>> The two remaining public and private access levels are simple and 
>> intuitively obvious.
> 
> I'm going to say that I remain unhappy with these new names. I don't believe 
> that these won't get used, and I don't want them to feel awkward, 
> discouraged, or penalized when they do. The standard library, for example, 
> has in its style guide that all access control should be explicit, which is a 
> reasonable style to enforce. I also have a small concern that they won't be 
> easy to talk about: "this method is private" "wait, file-private or 
> module-private?" "neither, just private-private".

I think this is a very important observation. Being able to talk about these 
levers is very important, especially in the context of teaching new people 
about the various levels of access control.

> I realize these are all vague concerns, and I don't have something more 
> concrete—or a better alternative. "modulescoped" and "filescoped" would be 
> very literally accurate but (a) would force people to learn what "scoped" 
> means unnecessarily, and (b) aren't less awkward.
> 
> I agree with the concerns that just saying "file var foo" makes it sound like 
> there's one copy of the variable shared in the entire file, even when applied 
> to an instance property. I think there's a lot of value is making the access 
> control terms adjectives.
> 
> I honestly still think "public, internal, private, local" is a better 
> taxonomy.. It's true that "internal" and "private" aren't automatically 
> ordered relative to each other (and maybe not even "local"), but they're all 
> adjectives (unlike "module" and "file"), and they're not awkward to read or 
> to use in conversation. But both the core team and the list disagree, mainly 
> because (a) it aligns 'private' more closely with other languages, and (b) if 
> you're not thinking about it, more restrictive is better than less. (Both of 
> which I agree are good ideas.)

I agree 100% with this. 

> 
> Jordan
> ___
> 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] [DRAFT] Introducing a Debug Build Configuration Test

[David Owens II via swift-evolution]

Along the lines of what Jordan is saying, I don't think there even is a such 
thing a unifying definition of "debug build". Even your definition for "my 
people" is a collection of build settings.

The definition of "asserts can fire" is also problematic. Maybe if tied 
specifically to Swift's asserts, but honestly, Swift's asserts, as they are, 
are simply not sufficient for everyone's development model.

Here's an real example:

I have a set of test automation that I want to ensure works. However, running 
this automation with a blocking assert is not what I want. Instead, I've 
created a mechanism for asserts, configurable at runtime, for the way in which 
those asserts are handled. During automation, I want those asserts to simply 
log, but code execution is not halted. During my normal dev cycle though, I 
want those asserts to be raised immediately so the developer sees the error and 
can chose to investigate or ignore the assert.

The proposal seems to be trying to simplify something that is actually much 
more complicated in the wild. 

All that said, there is a feature that I think your proposal is hinting 
towards: the ability to define named configs from set of flags and compiler 
options (essentially, the ability to define your scheme in a Swift-friendly 
way).

This feature would need coordination across the SwiftPM project as well though 
so you could define "MYCONFIG" as setting flags A-E, and likely other 
configuration settings. Then you would have the net of your proposal:

#if config(MYCONFIG)
#endif

-David

-Original Message-
From: swift-evolution-boun...@swift.org 
[mailto:swift-evolution-boun...@swift.org] On Behalf Of Erica Sadun via 
swift-evolution
Sent: Tuesday, March 15, 2016 11:20 AM
To: Jordan Rose ; Dmitri Gribenko ; 
Joe Groff 
Cc: swift-evolution 
Subject: Re: [swift-evolution] [DRAFT] Introducing a Debug Build Configuration 
Test


> On Mar 15, 2016, at 11:28 AM, Jordan Rose  wrote:
> 
> What is a "debug build"? Is it one where testing is enabled? Where the 
> optimization level is -Onone? (We've talked about having an -Odebug and/or 
> -Oplayground at some point. Are those "debug builds"?) Is it one where 
> asserts are not removed? (This can technically be controlled independently of 
> -O, but we don't advertise the fact, and I'm not sure we even want that 
> feature.)
> 
> Also, what is "config"? It doesn't mean anything to me on its own, which 
> means I wouldn't know what else I can put besides "debug".
> 
> Jordan
> 

Figuring out what debug *means* is an important first step. To "my people", 
it's the Xcode Build Configuration > Debug scheme setting. For language 
purposes, the only definition I can come up with at the moment is that debug is 
what happens when asserts can fire and are not disabled by compile-time 
optimizations.

Is there a better definition?

-- E

___
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-0018 Flexible Memberwise Initialization

[David Owens II via swift-evolution]

-1 for me.

> On Jan 6, 2016, at 2:47 PM, Chris Lattner via swift-evolution 
> mailto:swift-evolution@swift.org>> wrote:
> 
> Hello Swift community,
> 
> The review of "Flexible Memberwise Initialization" begins now and runs 
> through January 10th. The proposal is available here:
> 
>   
> https://github.com/apple/swift-evolution/blob/master/proposals/0018-flexible-memberwise-initialization.md
>  
> 
>
> 
>   * What is your evaluation of the proposal?

I’m unconvinced that the value is warranted for the complexity that is being 
brought to the table. Couple this with the fact that it’s very easy to 
accidentally make breaking changes by simply re-ordering your members, adding 
new ones, or even assigning a default value. I just find it far too fragile.

>   * Is the problem being addressed significant enough to warrant a change 
> to Swift?

I don’t think so. 

>   * Does this proposal fit well with the feel and direction of Swift?

I suppose. However, it has a lot of impact on the resiliency of APIs, so I’d 
want to delay this feature until those issues are worked out first. The other 
concern is there is a lot of magic involved, especially when some of the future 
enhancements are looked at.

>   * If you have you used other languages or libraries with a similar 
> feature, how do you feel that this proposal compares to those?

I’ve used tools to do this in past, such as MACROs or snippet-like items. Those 
seemed to be more useful and less constrained. Also, I make use of Swift’s 
implicit initializers for structs for internal code. While that is nice, I’ve 
not been convinced that moving this functionality to public is a good thing.

>   * How much effort did you put into your review? A glance, a quick 
> reading, or an in-depth study?

I’ve been following the iterations and partaking in some of the conversations.

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

Re: [swift-evolution] [swift-build-dev] [Review] SE-0019 Swift Testing (Package Manager)

[David Owens II via swift-evolution]

> On Jan 5, 2016, at 4:06 PM, Max Howell  wrote:
> 
> We won’t be running tests by default, just building them by default. We have 
> to pick a build-configuration as a default.
> 
> I’m sorry I must be missing something, I don’t see how we are only supporting 
> unit tests. At first XCTest is the only framework, but part of the proposal 
> explains how in the future we will support any framework that can conform to 
> a protocol. That protocol is the topic for another proposal.

When there is stuff like this in the proposal:

> "We would prefer to go even further by executing the tests each time a module 
> is built as well, but we understand that this would impede debug cycles.”

That implies that there is a desire to run tests by default. That also suggests 
the design of the proposal is geared for a very specific type of testing 
category, specifically unit tests. Maybe that’s not what is meant, but that is 
how I read it.


>> Then please provide and specify how this can be opt-ed out of clearly. Is it 
>> the --without-tests flag? Can we specific default options in the 
>> Package.swift so that this always occurs?
>> 
>> As a simple query, go around Apple and ask the compiler team if they want 
>> this feature for their code. Ask those developing in the corelibs. Ask any 
>> of the app teams. Please also do performance testing on this for various 
>> sized projects. It will absolutely have an impact, especially with regards 
>> to the current state of Swift compile times.
> 
> The proposal specifies there will be a flag, the flag is TBD. Probably 
> exactly what you specified.

What about the defaults so that whenever “swift build” is run, specific flags 
are used? Is that out of scope - maybe with the build configurations? Or is 
that intended to be done via a layer of “build scripts” so teams can have 
consistent workflows?


> In the future, we may choose to promote the --test option to be a 
> subcommand of the swift command itself:
> 
> $ swift test
> 
> However, any such decision would warrant extensive design consideration, 
> so as to avoid polluting or crowding the command-line interface. Should 
> there be sufficient demand and justification for it, though, it would be 
> straightforward to add this functionality.
 
 
 This doesn’t make sense to me. It’s either straightforward, or it requires 
 extensive design consideration. I personally strongly dislike coupling the 
 notion of building with test execution, so I would much rather see “swift 
 test” used, especially with a look into the future where it’s going to be 
 asked for the ability to run categories of tests and filter to a 
 particular set of tests to be run.
>>> 
>>> I agree, but my issue with `swift test` is that we are beginning to tightly 
>>> couple `swift build` with swift itself. I’m not sure we should run-and-gun 
>>> into this decision. SwiftPM is strictly alpha/beta and any decisions we 
>>> make on these sorts of issues can change.
>> 
>> The alternatives are:
>> 
>> 1. Factor out to a new binary, like spm, or
>> 2. Continue down the path of tightly coupling build code with test execution.
>> 
>> I’d actually like to see the Swift Package Manager factor out to it’s own 
>> entity sooner rather than later and instead shell out and use the swift 
>> compiler.
> 
> This is already how it is.

Huh? Isn’t it tied to the “swift” compiler as a plug-in of sorts? Maybe I don’t 
understand how it works. I’m talking about removing it completely from the 
compiler infrastructure. But we can have this discussion a different time.


>> This would also help with other proposals, such as the “Getting C code 
>> compiling” one. But that’s a different proposal...
>> 
 Another real problem with this type of design, is that is makes more 
 advanced build systems very complicated to make. For example, distributed 
 builds that bring together all of the compiled bits to run tests on get 
 blocked because the build command starts to expect certain intermediate 
 output. This is a real problem my previous team still has to this day with 
 xcodebuild and actively prevents us from doing this exact thing with 
 standard tools from Apple, so we have to basically roll our own. I see 
 this design following in the exact same footsteps.
>>> 
>>> I’m not sure I understand.
>> 
>> Every time you run “swift build” it’s going to trigger a build. This is 
>> should never be required to run tests. Even if you say, “we’ll only re-build 
>> on incremental builds”, you are assuming that you are building and running 
>> tests within the same environment and that the environment is a 
>> build-capable environment. This is not a valid assumption. This is what 
>> xcodebuild test does today, it tries to smartly only trigger builds when 
>> necessary, but since we build on one set of boxes and run tests on other 
>> machines, this simply doesn’t work.
>> 
>> We hav

Re: [swift-evolution] [swift-build-dev] [Review] SE-0019 Swift Testing (Package Manager)

[David Owens II via swift-evolution]

> On Jan 5, 2016, at 2:58 PM, Max Howell  wrote:
> 
>> Overall, I think the feature is important to have, but I don’t understand 
>> some of the aspects of the proposal. I also don’t think there is a real 
>> focus for clarity on the types of testing that are being supported here. The 
>> implication is that unit tests are what this is being targeted, but is this 
>> proposal specifically limiting to those particular types of tests? If so, 
>> why? If not, some of the aspects really don’t make much sense to be 
>> defaulted into.
> 
> The proposal does not advocate any particular testing methodology. Certainly 
> to start with we only support XCTest, but that is just a practical decision. 
> Fundamentally the proposal is only advocating building modules that are *for* 
> testing, and then executing these tests with a runner, which at first will be 
> an XCTest runner.

XCTest is just the runner with an additional style of how to validate the test. 
I’m talking about the distinction between unit, integration, performance, etc. 
All of these types of tests can be written with XCTest, though some harder than 
others. There are choices being made with the implicit assumption that tests in 
your test modules are unit tests. Running tests by default and only running 
tests by default on debug builds are examples of those implicit assumptions 
about the classification of test within your modules.


>>> Additionally we will support directories called FooTests. This layout style 
>>> is prevalent in existing open source projects and supporting it will 
>>> minimize vexation for their authors. However in the interest of consistency 
>>> and the corresponding reduction of cognitive-load when examining new Swift 
>>> packages we will notrecommend this layout. For example:
>>> 
>>> Package
>>> └── Sources
>>> │   └── Foo.swift
>>> └── FooTests
>>> └── Test.swift
>> 
>> Why support something that that is not going to be recommended? Prevalence 
>> of something seems like a poor choice, especially when you are going to 
>> specifically not recommend to use it. Also, the proposal already mentioned 
>> an override mechanism to allow these to be specified. This seems like 
>> something that could easily be cut.
> 
> If we don’t cater to the thousands of projects already out there we 
> potentially will hinder adoption.
> 
> I’d agree with you if supporting this was going to hurt, but it won’t.

It “hurts” by increasing cost, maintenance, and cognitive overload for 
understanding all of the “out-of-the-box” ways that test modules get implicitly 
created. 

> 
>>> Additionally, we propose that building a module also builds that module's 
>>> corresponding tests. Although this would result in slightly increased build 
>>> times, we believe that tests are important enough to justify this (one 
>>> might even consider slow building tests to be a code smell). We would 
>>> prefer to go even further by executing the tests each time a module is 
>>> built as well, but we understand that this would impede debug cycles.
>> 
>> Re-building tests all of the time is a huge time waste. Executing those 
>> tests even more so (also see original question on the types of tests being 
>> supported). Not only that, in production software, it’s very often the case 
>> that there are levels of tests that get run because of the shear amount of 
>> them that exist and the time involved to run them. In addition to levels, 
>> there are classifications of tests (perf, robustness, memory, stress, 
>> fuzzing, etc…).
> 
> I would like to wait and see. If you are right and it is a huge time waste 
> then we can turn this off.

Then please provide and specify how this can be opt-ed out of clearly. Is it 
the --without-tests flag? Can we specific default options in the Package.swift 
so that this always occurs?

As a simple query, go around Apple and ask the compiler team if they want this 
feature for their code. Ask those developing in the corelibs. Ask any of the 
app teams. Please also do performance testing on this for various sized 
projects. It will absolutely have an impact, especially with regards to the 
current state of Swift compile times.

>> This is something that should be an opt-in. The most basic example of this 
>> is refactoring a code base (which is later briefly mentioned at the end o 
>> the proposal). The first step is getting the code compiling for the project. 
>> It’s not true that the very next step you take is fix up the tests, 
>> especially in the cases that the refactoring/changes are exploratory.
> 
> Indeed, I agree. But I’d like to wait and see.

I really would like to understand what your metrics of acceptability are here. 
Is twice the build cost ok? Three times?

>>> In the future, we may choose to promote the --test option to be a 
>>> subcommand of the swift command itself:
>>> 
>>> $ swift test
>>> 
>>> However, any such decision would warrant extensive design consideration, so 
>>>

Re: [swift-evolution] [Review] SE-0019 Swift Testing (Package Manager)

[David Owens II via swift-evolution]

Overall, I think the feature is important to have, but I don’t understand some 
of the aspects of the proposal. I also don’t think there is a real focus for 
clarity on the types of testing that are being supported here. The implication 
is that unit tests are what this is being targeted, but is this proposal 
specifically limiting to those particular types of tests? If so, why? If not, 
some of the aspects really don’t make much sense to be defaulted into.

> Additionally we will support directories called FooTests. This layout style 
> is prevalent in existing open source projects and supporting it will minimize 
> vexation for their authors. However in the interest of consistency and the 
> corresponding reduction of cognitive-load when examining new Swift packages 
> we will not  recommend this layout. For example:
> 
> Package
> └── Sources
> │   └── Foo.swift
> └── FooTests
> └── Test.swift

Why support something that that is not going to be recommended? Prevalence of 
something seems like a poor choice, especially when you are going to 
specifically not recommend to use it. Also, the proposal already mentioned an 
override mechanism to allow these to be specified. This seems like something 
that could easily be cut.

> Additionally, we propose that building a module also builds that module's 
> corresponding tests. Although this would result in slightly increased build 
> times, we believe that tests are important enough to justify this (one might 
> even consider slow building tests to be a code smell). We would prefer to go 
> even further by executing the tests each time a module is built as well, but 
> we understand that this would impede debug cycles.

Re-building tests all of the time is a huge time waste. Executing those tests 
even more so (also see original question on the types of tests being 
supported). Not only that, in production software, it’s very often the case 
that there are levels of tests that get run because of the shear amount of them 
that exist and the time involved to run them. In addition to levels, there are 
classifications of tests (perf, robustness, memory, stress, fuzzing, etc…).

This is something that should be an opt-in. The most basic example of this is 
refactoring a code base (which is later briefly mentioned at the end o the 
proposal). The first step is getting the code compiling for the project. It’s 
not true that the very next step you take is fix up the tests, especially in 
the cases that the refactoring/changes are exploratory.

> In the future, we may choose to promote the --test option to be a subcommand 
> of the swift command itself:
> 
> $ swift test
> 
> However, any such decision would warrant extensive design consideration, so 
> as to avoid polluting or crowding the command-line interface. Should there be 
> sufficient demand and justification for it, though, it would be 
> straightforward to add this functionality.


This doesn’t make sense to me. It’s either straightforward, or it requires 
extensive design consideration. I personally strongly dislike coupling the 
notion of building with test execution, so I would much rather see “swift test” 
used, especially with a look into the future where it’s going to be asked for 
the ability to run categories of tests and filter to a particular set of tests 
to be run.

Another real problem with this type of design, is that is makes more advanced 
build systems very complicated to make. For example, distributed builds that 
bring together all of the compiled bits to run tests on get blocked because the 
build command starts to expect certain intermediate output. This is a real 
problem my previous team still has to this day with xcodebuild and actively 
prevents us from doing this exact thing with standard tools from Apple, so we 
have to basically roll our own. I see this design following in the exact same 
footsteps.

I think a lot of the design would be clarified by changing all of “by 
convention” items into realized default values in the Package.swift file. That 
would clearly demonstrate how the work and how we can change them.

-David


> On Jan 5, 2016, at 11:06 AM, Rick Ballard via swift-evolution 
>  wrote:
> 
> Hello Swift community,
> 
> The review of “Swift Testing” for the Package Manager begins now and runs 
> through Thursday, January 7th. The proposal is available here:
> 
>   
> https://github.com/apple/swift-evolution/blob/master/proposals/0019-package-manager-testing.md
> 
> For this particular review, please note that a significant amount of 
> discussion history is available in the original pull request for the proposal:
> 
>   https://github.com/apple/swift-evolution/pull/51
> 
> Reviews are an important part of the Swift evolution process. All reviews 
> should be sent to the swift-evolution mailing list at
> 
>   https://lists.swift.org/mailman/listinfo/swift-evolution
> 
> or, if you would like to keep your feedback private, directly to th

Re: [swift-evolution] Thoughts on clarity of Double and Float type names?

[David Owens II via swift-evolution]

+1. I think it brings a nice symmetry with the integer types and puts size 
classing in a more consistent place.

And to be frank, I already typedef the intrinsic float/double types in my C 
code to f32/f64 for similar reasons.

-David

> On Jan 4, 2016, at 12:58 PM, Alex Johnson via swift-evolution 
>  wrote:
> 
> Hi all,
> 
> I'm curious how other members of the Swift community feel about the clarity 
> of the "Double" and "Float" type names. It seems incongruous that the default 
> type for integers is "Int", but the default type for floating point numbers 
> is not "Float".
> 
> What if the name "Float" were given to the intrinsic, 64-bit floating point 
> type? (And the existing "Float" and "Double" names were removed in favor of 
> "Float32" and "Float64"?)
> 
> 
> Discussion:
> 
> I understand the origins of these names in single- and double-precision IEEE 
> floats. But this distinction feels like a holdover from C (and a 32-bit 
> world), rather than a natural fit for Swift.
> 
> Here are some reasons to keep Double and Float as they are (numbered for easy 
> reference, but otherwise unordered):
> "Double" and "Float" are more natural for developers who are "familiar with 
> C-like languages."
> A corollary: A 64-bit "Float" type could be confusing to those developers.
> Another corollary: Swift needs to interoperate with Objective C, and its 
> "float" and "double" types.
> Renaming these types would open the door to bike-shedding every type name and 
> keyword in the language.
> Changing the meaning of an existing type ("Float") would be a bit PITA for 
> existing code (although an automated migration from "Float" to "Float32" and 
> "Double" to "Float" should be possible).
> Renaming a fundamental type would take considerable effort.
> Here are some reasons to rename these types:
> The default for a "float literal" in Swift is a 64-bit value. It would feel 
> natural if that that value were of type "Float".
> There are size-specific names for 32-bit ("Float32") and 64-bit ("Float64") 
> floating point types. For cases where a size-specific type is needed, a 
> size-specific name like "Float32" probably makes the intention of the code 
> more clear (compared to just "Float").
> Apple's Objective C APIs generally use aliased types like "CGFloat" rather 
> than raw float or double types.
> There is precedent for "Float" types being 64-bit in other languages like 
> Ruby, Python and Go (as long as the hardware supports it).
> What kind of a name for a type is "Double" anyways, amirite?
> (that last one is a joke, BTW)
> 
> What do you think? Do you agree or disagree with any of my assessments? Are 
> there any pros or cons that I've missed? Is the level of effort so large that 
> it makes this change impractical? Is it a colossal waste of human effort to 
> even consider a change like this?
> 
> Thanks for your time and attention,
> Alex Johnson (@nonsensery)
>  ___
> 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] Swift 2.2: #if swift language version

[David Owens II via swift-evolution]

The @available() and if #available constructs are not sufficient as they fall 
under the same limitations that your proposal addresses: they require that the 
non-valid branch not be parsed. For example, an API that has changes with a new 
language feature, such as variadic generic arguments, would not be able to be 
defined.

If we look at the grammar, I don’t see why the grammar for 
“availability-argument” couldn’t look like this:

availability-argument: (platform-name | language-name | package-name) 
version.
GRAMMAR OF AN AVAILABILITY CONDITION

 <>availability-condition → #available­(­availability-arguments 
<https://developer.apple.com/library/ios/documentation/Swift/Conceptual/Swift_Programming_Language/Statements.html#//apple_ref/swift/grammar/availability-arguments>­)­
 <>availability-arguments → availability-argument 
<https://developer.apple.com/library/ios/documentation/Swift/Conceptual/Swift_Programming_Language/Statements.html#//apple_ref/swift/grammar/availability-argument>­
  availability-argument 
<https://developer.apple.com/library/ios/documentation/Swift/Conceptual/Swift_Programming_Language/Statements.html#//apple_ref/swift/grammar/availability-argument>­,­availability-arguments
 
<https://developer.apple.com/library/ios/documentation/Swift/Conceptual/Swift_Programming_Language/Statements.html#//apple_ref/swift/grammar/availability-arguments>­
 <>availability-argument → platform-name 
<https://developer.apple.com/library/ios/documentation/Swift/Conceptual/Swift_Programming_Language/Statements.html#//apple_ref/swift/grammar/platform-name>­platform-version
 
<https://developer.apple.com/library/ios/documentation/Swift/Conceptual/Swift_Programming_Language/Statements.html#//apple_ref/swift/grammar/platform-version>­
 <>availability-argument → *­
 <>platform-name → iOS­  iOSApplicationExtension­
 <>platform-name → OSX­  OSXApplicationExtension­
 <>platform-name → watchOS­
 <>platform-version → decimal-digits 
<https://developer.apple.com/library/ios/documentation/Swift/Conceptual/Swift_Programming_Language/LexicalStructure.html#//apple_ref/swift/grammar/decimal-digits>­
 <>platform-version → decimal-digits 
<https://developer.apple.com/library/ios/documentation/Swift/Conceptual/Swift_Programming_Language/LexicalStructure.html#//apple_ref/swift/grammar/decimal-digits>­.­decimal-digits
 
<https://developer.apple.com/library/ios/documentation/Swift/Conceptual/Swift_Programming_Language/LexicalStructure.html#//apple_ref/swift/grammar/decimal-digits>­
 <>platform-version → decimal-digits 
<https://developer.apple.com/library/ios/documentation/Swift/Conceptual/Swift_Programming_Language/LexicalStructure.html#//apple_ref/swift/grammar/decimal-digits>­.­decimal-digits
 
<https://developer.apple.com/library/ios/documentation/Swift/Conceptual/Swift_Programming_Language/LexicalStructure.html#//apple_ref/swift/grammar/decimal-digits>­.­decimal-digits
 
<https://developer.apple.com/library/ios/documentation/Swift/Conceptual/Swift_Programming_Language/LexicalStructure.html#//apple_ref/swift/grammar/decimal-digits>­
I’d further argue that the version argument properly adhere to the semver spec: 
http://semver.org.

The above change, in addition to the change for the if #available statement to 
not parse the unavailable path would seem to provide the solution you want to 
have in addition to the solution that many package developers could use as well.

The nice thing is that this could be done in stages:

1. Add support for the language condition and change #available to not parse 
the non-valid paths
2. Add support for package names
3. Add support for proper semver versioning.

The only breaking change is #1. When/if semver was supported, the version could 
still take the decimal digits while adding semver support.

-David

> On Jan 4, 2016, at 4:02 PM, David Farler  wrote:
> 
> We already have @- and #-prefixed availability-like constructs, so I would 
> prefer something more specific to the task – I wouldn't want to dilute the 
> meaning of a package name argument by supplying it with the magic package 
> "swift", for example. Changes to the language can be highly disruptive to all 
> Swift code, so that's why I think it warrants its own build configuration. 
> 
> David
> 
>> On Dec 20, 2015, at 10:45 PM, David Owens II via swift-evolution 
>> mailto:swift-evolution@swift.org>> wrote:
>> 
>> If we are going to support something like this, I’d rather see it be 
>> something everyone could leverage as there are many use cases for this 
>> feature:
>> 
>> #if available("package-name", "1.2.*")
>> #endif
>> 
>> Then at least everyone can opt-in to using it for availability checks. This 
>> should of course tie into the Swift 

Re: [swift-evolution] [Proposal] Swift 2.2: #if swift language version

[David Owens II via swift-evolution]

I could (assuming I’m the David you’re referring to), though it will probably 
be towards the end of the week or early next week before I get a chance to get 
to it.

-David

> On Jan 4, 2016, at 1:03 PM, Drew Crawford  wrote:
> 
> The swift package manager is currently considering its own define 
> ,
>  so it's now the second official project that could benefit from this syntax.
> 
> David, any interest in writing this up?
> 
>> On Jan 3, 2016, at 4:48 AM, Goffredo Marocchi > > wrote:
>> 
>> +1 from me as well, supporting conditional compilation when the two versions 
>> of foundation differ and may differ for the foreseeable future seems a must 
>> on this end.
>> 
>> Sent from my iPhone
>> 
>> On 3 Jan 2016, at 10:12, Drew Crawford via swift-evolution 
>> mailto:swift-evolution@swift.org>> wrote:
>> 
 If we are going to support something like this, I’d rather see it be 
 something everyone could leverage as there are many use cases for this 
 feature:
 
 #if available("package-name", "1.2.*")
 #endif
>>> 
>>> Big +1.
>>> 
>>> I've asked specifically to get some kind of conditional compilation on 
>>> corelibs-foundation 
>>> 
>>>  being used.  corelibs-founcation is currently incompatible with Darwin 
>>> Foundation, and so it is impractical to make a single codebase build for 
>>> both.
>>> 
>>> But building the same application against both Foundations and spotting 
>>> differences is one of the important ways we're going to spot bugs.
>>> 
>>> So I think the code quality of Foundation ultimately hinges on getting some 
>>> feature like this in the language.
>>> 
>>> ___
>>> 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-build-dev] [swiftpm] Add proposal for C language support

[David Owens II via swift-evolution]

Seems like a good start for Swift developers that need to write some C code for 
their project. 

-David

Sent from my iPhone

> On Jan 2, 2016, at 9:00 AM, Daniel Dunbar via swift-build-dev 
>  wrote:
> 
> Happy 2016!
> 
> I am working on an initial proposal for adding support for C language targets 
> to the Swift package manager, and am interested in feedback:
>  
> https://github.com/ddunbar/swift-evolution/blob/master/proposals/-swiftpm-c-language-targets.md
> 
> Some TL;DR:
> - The proposal defines a basic convention for pure C language targets (no 
> Swift/C mix and match, but other Swift targets can use the C targets).
> - This is just intended to be the minimal initial feature, there will be a 
> lot of add on work which I expect should be tackled in follow on 
> PRs/proposals.
> - The proposal doesn't try and outline every single nitty detail (e.g., 
> exactly what C++ standard we will compile with). My intention is to pick a 
> sensible default at implementation time and refine incrementally.
> 
> Unless there are serious objections, I am hoping to hope to land this 
> proposal soon and start work on the feature shortly after.
> 
> Cheers,
> - Daniel
> 
> 
> ___
> swift-build-dev mailing list
> swift-build-...@swift.org
> https://lists.swift.org/mailman/listinfo/swift-build-dev
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Proposal Draft] automatic protocol forwarding

[David Owens II via swift-evolution]

> On Dec 31, 2015, at 9:47 AM, Matthew Johnson via swift-evolution 
>  wrote:
> 
> No.  This is addressed in the proposal and the lazy collections motivating 
> example I replied with last night.  I don’t think it’s a good idea to require 
> this.

Can you put your proposal on GitHub under your swift-evolution fork? It’s 
really hard to follow the current state of the proposal and the changes over 
time.


> The forwardee needs to implement the members of the protocol but does not 
> need to conform.  The forwarder will receive forwarding implementations of 
> the members, but again does not need to declare conformance.  Forwarding is 
> orthogonal to conformance, just as it is today when you manually write 
> forwarding members today.

I cannot think of a time where I wanted this pseudo-conformance. The entire 
purpose of forwarding, that I’ve ever wanted or seen at least, is to act as a 
pass-through from the outer type’s conformance to a protocol to an internal 
specific implementor of that protocol without having to write all of the 
boiler-plate code to make that happen.

So I find it confusing that you say they are orthogonal.

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

Re: [swift-evolution] sortBy, minElementBy and maxElementBy methods

[David Owens II via swift-evolution]

I don’t get the resistance to Dave’s solution? I think it works well and much 
more applicable. Taking Susan’s original example, it’s not uncommon to want to 
sort or filter by multiple mechanisms.


func byComparing(getComparisonKey: (T)->U) -> (T, T) -> Bool {
return { getComparisonKey($0) < getComparisonKey($1) }
}

struct Person {
var name: String
var age: Int
var height: Int
}

let peoples = [
Person(name: "Hawk", age: 24, height: 60),
Person(name: "Andrew", age: 23, height: 66)
]

let youngest = peoples.minElement(byComparing { $0.age })
let tallest = peoples.maxElement(byComparing { $0.height })

print("youngest: \(youngest?.name ?? "")")
print("tallest: \(tallest?.name ?? "")")


-David

> On Dec 31, 2015, at 8:19 AM, Dave Abrahams via swift-evolution 
>  wrote:
> 
> 
>> On Dec 31, 2015, at 4:14 AM, Tino Heth <2...@gmx.de > 
>> wrote:
>> 
>> 
>>> func byComparing(getComparisonKey: (T)->U) -> (T, T) -> 
>>> Bool {
>>>   return { getComparisonKey($0) < getComparisonKey($1) }
>>> }
>> I've written something similar to bring file URLs into the order of their 
>> creation dates.
>> It is a small extension for collection types, and its only downside will 
>> disappear as soon as properties are accessible via method calls (afair there 
>> is a proposal in the making).
>> 
>> It was quite a lot fiddling with generics, and I don't have the tiny piece 
>> of code on my own computer, but it works in a way that you can do
>> let sorted = array.sortUsingAccessor(ElementType.methodThatReturnsComparable)
>> Beside the problems with properties, I really liked that approach.
> 
> This seems to be essentially the same design as Susan’s, and has the same 
> problem: it requires a new overload for every algorithm that takes a 
> comparison predicate.
> 
> -Dave
> 
> 
> ___
> 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] Scoped resources (like C# using statement)

[David Owens II via swift-evolution]

+1 to Joe’s comment.

> On Dec 30, 2015, at 10:31 AM, Joe Groff via swift-evolution 
>  wrote:
> 
> 
>> On Dec 30, 2015, at 10:26 AM, Chris Lattner > > wrote:
>> 
>>> 
>>> On Dec 30, 2015, at 9:53 AM, Joe Groff via swift-evolution 
>>> mailto:swift-evolution@swift.org>> wrote:
>>> 
>>> 
 On Dec 29, 2015, at 8:55 PM, Kevin Ballard via swift-evolution 
 mailto:swift-evolution@swift.org>> wrote:
 
 An alternative solution is to do what Rust and C++ do, which is to use 
 RAII. Which is to say, instead of introducing a new language construct 
 that's explicitly tied to a scope, you just use a struct to represent the 
 resource that you hold (e.g. a File that represents an open file). Of 
 course, this does require some changes to structs, notably the addition of 
 a deinit. And if structs have a deinit, then they also need to have a way 
 to restrict copies. This is precisely what Rust does; any struct in Rust 
 that implements Drop (the equivalent to deinit) loses the ability to be 
 implicitly copied (a second trait called Clone provides a .clone() method 
 that is the normal way to copy such non-implicitly-copyable structs).
>>> 
>>> deinit doesn't make sense for value types. 
>> 
>> It would if we extended the model for value types to be richer, e.g. to 
>> introduce the notion of "move only” structs.
> 
> Perhaps, but I feel like it's a more natural extension of our existing model 
> to support uniquely-owned classes though, which would give you all the same 
> benefits.
> 
> -Joe
> 
> 
> ___
> 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] Pitch: Deinit for structs

[David Owens II via swift-evolution]

This is something I asked for before, then I realized it wouldn’t work.

func helper(rs: ResourceHandle) {}

let resource = ResourceHandle()
helper(resource)

result.doSomething() // error

Another example:

let x = Handle()

do {
  let y = x
} // resources are freed here as deinit is called

// x is not safe to use, and freed again when x goes out of scope

Everytime the struct value goes out of scope, the deinit would be called. The 
other option is to create move and copy semantics, as both would be required.

> Given Swift’s emphasis on value types

I think this is a mischaracterization, and one that I’ve made in the past. 
Swift’s emphasis in on clarity and providing you the mechanism to create things 
that are value-types for APIs that should behave like a value. However, that 
doesn’t mean that everything should a struct first.

-David

> On Dec 23, 2015, at 1:07 PM, Charles Srstka via swift-evolution 
>  wrote:
> 
> Introduction:
> 
> This is a rather simple proposal, requesting that structs allow the ‘deinit’ 
> destructor, as classes currently do.
> 
> Motivation:
> 
> Sometimes it is necessary to create an object that wraps a network connection 
> (that needs to be closed when the object is destroyed), or that writes to a 
> file on the disk (that has to be closed when the object is destroyed). Often 
> these objects will implement a close() method, but in the case that the user 
> forgets to call this before the object is disposed of, it is good to call it 
> in deinit just in case. However, deinit currently is available only to 
> classes and not to structs. This means that value types currently cannot be 
> used for network and file-backed constructs. Given Swift’s emphasis on value 
> types, it seems that it would be good to add this functionality to value 
> types.
> 
> Proposed Solution:
> 
> Allow the deinit destructor in structs.
> 
> Impact on Existing Code:
> 
> Should be no impact on existing code.
> 
> Charles
> 
> ___
> 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] Immutable Structures

[David Owens II via swift-evolution]

I’m confused by your example below. Your move() function is equivalent to this:

func move(position: Position) {
var copy = position
copy.x += 20
}

Did you mean “var” there? (sidenote: var is being removed from the function 
call site)

Structs are immutable. It’s only with a var-declaration and a mutating function 
or it’s exposed properties, or the passing via inout, that structs appear to 
become immutable, but even that is a copy-on-write behavior. Like others have 
mentioned, the optimizer can remove this copy in many places for efficiency 
gains.

For instance, this is how you would change the incoming struct:

func move(inout position: Position) {
position.x += 20
}

var p1 = Position(x: 10, y: 10)
move(&p1)

This will print 30 both with struct or class.

> 1) The choice between classes and structures isn’t clear right now. If 
> structures were immutable it would be natural to use them as value objects.


If you have a value-type type and it supports equality, then a struct is the 
“right” choice. That’s the basic guideline. So anything you wish to treat as a 
value and have value-semantics (which is basically copy-on-write), use a 
struct. That seems like what you are saying, and that’s already the case.

> 2) Refactoring a mutable structure into a class when it’s being passed around 
> multiple threads removes the by-value semantics seamlessly. The resulting 
> mutable class isn’t thread-safe.


Classes, by definition, remove value-semantics. I agree that this type of 
refactoring is inherently fragile, but I don’t see how having “immutable” 
structs changes this. 

-David

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

Re: [swift-evolution] [Proposal Draft] Flexible memberwise initialization

[David Owens II via swift-evolution]

> On Dec 22, 2015, at 10:15 AM, Chris Lattner  wrote:
> 
> We would like to integrate this into the package manager as well, so it helps 
> “enforce” proper semantic versioning.

This would be awesome to have, especially integrated in. The way we handle this 
internally is less than ideal, so have a standard way would be great.

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

Re: [swift-evolution] Proposal: Allow Type Annotations on Throws

[David Owens II via swift-evolution]

> On Dec 22, 2015, at 9:50 AM, Matthew Johnson  wrote:
> 
> Unfortunately, I don’t see a way to make it safe.  You had to use fatalError 
> in a default case to make it work.  An alternative would have been to include 
> an ‘UnknownError’ case in ‘PublishedError’.  Neither is not an acceptable 
> solution IMO.

I need the fatalError() because the sample is a working example in Swift today. 
If we had typed errors, this would simply work:

   static func from(@autoclosure fn: () throws InternalError -> T) throws 
PublishedError -> T {
do {
return try fn()
}
catch InternalError.Internal(let value) {
throw PublishedError.Converted(value: value)
}
}

This states that the only closure accepted is one that throws an InternalError. 

> This top level `from` example also brings up a couple of points that I don’t 
> recall being addressed in your proposal.  Specifically, the interaction of 
> typed errors with generics and type inferrence.

I call out in the proposal that errors work with generics no differently than 
other types.

> I still consider this to be an unresolved concern.  I would like to have a 
> safe way to perform error conversion during propagation without cluttering up 
> my control flow and seriously degrading readability.  This is a problem that 
> can and has been solved in other languages.  IMO it is should be considered 
> an essential element of a proposal introducing typed errors.

When Swift has a macro as powerful as Rust, then this is a solved problem as 
well. However, Swift isn’t there yet. 

-David

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

Re: [swift-evolution] [Proposal Draft] Flexible memberwise initialization

[David Owens II via swift-evolution]

> On Dec 22, 2015, at 9:43 AM, Matthew Johnson  wrote:
> 
> Adding a new member to a struct is itself a breaking change.  I don’t see how 
> memberwise initialization makes this worse.

It may have been a bad example as you handle the case where they wouldn’t be a 
breaking change by promoting the default initialization to the memberwise 
init(). 

> Also, keep in mind that nothing in this proposal is *required*.  You can 
> always decline to use the feature.  

My point is the same with what’s going on in the “final as default” thread. 
Features that create public contracts that are hard to guarantee over the 
lifetime of a project, especially when those contracts weren’t being made 
explicitly, are hard to maintain over the life of the product.

I think it’s important to address what the fragility of the API is for 
versioning and how that’s being addressed, but that’s just my opinion. 

> Do you have any suggestions on how to improve the proposal without giving up 
> on its underlying goal of solving the M x N complexity problem (M members x N 
> initializers)? 

No. In my opinion, this is the fragile part of the solution though. I get the 
desire to reduce that part of the boiler plate, but I don’t know how to solve 
that part of the problem without a bunch of annotations that end up being more 
work than just implementing the init() yourself.

-David

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

Re: [swift-evolution] [Proposal idea] Improved interop for ErrorType->NSError

[David Owens II via swift-evolution]

> On Dec 22, 2015, at 9:30 AM, Paul Cantrell via swift-evolution 
>  wrote:
> 
> Hmm, I wonder if #1 or #4 suggest any language changes to propose for this 
> list.

Tangential to the topic at hand, but default values in tuples is something I’ve 
wanted for a while. Comparing optionals in a case statement would also be nice.

-David

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

Re: [swift-evolution] [Proposal Draft] Flexible memberwise initialization

[David Owens II via swift-evolution]

How are you going to deal with public properties creating a breaking change in 
the memberwise init()?

Example:

v1.0 of the API ships:

struct Person {
let name: String
}

v1.1 of the API ships:

struct Person {
let name: String
let age: Int
}

When you use the implicit memberwise init(), the above change is now a breaking 
change. There are ways around it, but all seem fragile to me - for example, 
requiring a default value for new properties on the declaration site.

Similarly, the order of the members must remain the same now, changing them is 
a breaking change. This is ok for structs today because the generated init() is 
only available within a module so all of the places that use it are limited 
within your own codebase.

This is why I do not like like the implicit behavior and the @nomemberwise 
attribute on the declaration of the property; it tightly couples together 
things that are inherently fragile.

-David

> On Dec 22, 2015, at 8:46 AM, Matthew Johnson via swift-evolution 
>  wrote:
> 
> Hi Chris,
> 
> I have given your feedback a lot of thought and have taken another run at 
> this proposal from a slightly different angle.  I believe it is a significant 
> improvement.  
> 
> I believe the programmer model is now very clear straightforward:
> 
> The set of properties that receive memberwise initialization parameters is 
> determined by considering only the initializer declaration and the 
> declarations for all properties that are at least as visible as the 
> initializer (including any behaviors attached to the properties). The rules 
> are as follows:
> 
>   • Their access level is at least as visible as the memberwise 
> initializer.
>   • They do not have a behavior which prohibits memberwise initialization.
>   • The property is not annotated with the @nomemberwise attribute.
>   • The property is not included in the @nomemberwise attribute list 
> attached of the initializer. If super is included in the @nomemberwise
> 
> The parameters are synthesized in the parameter list in the location of the 
> ... placeholder. They are ordered as follows:
> 
>   • All properties without default values precede properties with default 
> values.
>   • Within each group, superclass properties precede subclass properties.
>   • Finally, follow declaration order
> 
> The new model has also dramatically simplified the implementation details.  
> No more need for the compiler to scan the initializer body!
> 
> There are still some details present that you provided feedback on.  My reply 
> from last night is still valid discussion around those issues.  Please reply 
> inline to that message if possible.  
> 
> I’m sure there are still plenty of details to discuss and work through, but I 
> hope you will agree that these changes are a step in the right direction.
> 
> https://github.com/anandabits/swift-evolution/blob/flexible-memberwise-initialization/proposals/-flexible-memberwise-initialization.md
>  
> 
> 
> Matthew

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

Re: [swift-evolution] [Proposal Draft] Flexible memberwise initialization

[David Owens II via swift-evolution]

> On Dec 21, 2015, at 11:05 PM, Brent Royal-Gordon  
> wrote:
> 
>>> The proposal already states that a memberwise initializer only includes 
>>> parameters for properties that are at least as visible as the initializer 
>>> itself. So if you can see the `s` and `i` parameters, you can also see the 
>>> `s` and `i` properties. It's not going to expose anything that isn't 
>>> already visible.
>> 
>> This isn’t about access modifiers, it’s about the name chosen for internal 
>> variables vs. names chosen for API contracts.
> 
> But if you have a bad name in your memberwise initializer, that bad name is 
> *by definition* already part of your API contract as a property name.
> 
> Stated another way: Either the name is already externally visible as a 
> property, and thus is not by any sensible definition an "internal" name, or 
> the memberwise initializer will not publish it.

Not with the updates I suggested as you can still initialize non-visible 
members. Whether you find that valuable or not is a different question.

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

Re: [swift-evolution] [Proposal Draft] Flexible memberwise initialization

[David Owens II via swift-evolution]

> On Dec 21, 2015, at 10:39 PM, Brent Royal-Gordon  
> wrote:
> 
>> Also, I don’t think it generates good API signatures. Take this example:
>> 
>> struct S {
>>  let s: String
>>  let i: Int
>> 
>>  // user declares:
>>  memberwise init() {}
>>  // compiler synthesizes:
>>  init(s: String, i: Int) {
>>  self.s = s
>>  self.i = i
>>  }
>> }
>> 
>> That is not a very descriptive API.
> 
> Well, yeah. This is a toy example. Do you often write APIs with properties 
> like `s` and `i`? Or, for that matter, structs named `S`?

I often write APIs where the internal member’s name is not what I want to use 
as the label for the public API. 


>> It’s also not necessarily the case that your internal names are what you 
>> want exposed.
> 
> The proposal already states that a memberwise initializer only includes 
> parameters for properties that are at least as visible as the initializer 
> itself. So if you can see the `s` and `i` parameters, you can also see the 
> `s` and `i` properties. It's not going to expose anything that isn't already 
> visible.

This isn’t about access modifiers, it’s about the name chosen for internal 
variables vs. names chosen for API contracts.

-David

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

Re: [swift-evolution] [Proposal Draft] Flexible memberwise initialization

[David Owens II via swift-evolution]

I really like the idea and it’s something that’s extremely annoying to deal 
with today in Swift. My biggest concern is that the proposal, in its entirety, 
seems to really complicate the initialization rules.

Also, I don’t think it generates good API signatures. Take this example:

struct S {
let s: String
let i: Int

// user declares:
memberwise init() {}
// compiler synthesizes:
init(s: String, i: Int) {
self.s = s
self.i = i
}
}

That is not a very descriptive API. It’s also not necessarily the case that 
your internal names are what you want exposed.

I would actually prefer the rule to simply be this: when an init() is modified 
by memberwise, the labelled parameters will be set. This lookup will try both 
the argument name and the parameter name, in that order, for reasons that 
become more clear with convenience inits described later.

So you would have this:

memberwise init(name s: String, value i: Int) {
// autogenerated: self.s = s; self.i = i
}

This provides you all of the freedom that you may need:
Order of the APIs is explicitly controlled
API names of the members are not exposed if not desired, especially helpful for 
non-public members
Default values are handled naturally

Optionally, you could keep the default simply with this:

memberwise init {}

This would use the property names as the argument labels.

Another example:

memberwise init(name s: String, value i: Int = 12) {
// autogenerated: self.s = s; self.i = i
}

And the usage is much nicer:

let s = S(name: "Happy")

Here’s a subclassing example:

class Animal {
let type: String
let numberOfLegs: Int

memberwise init(type: String, numberOfLegs: Int) {
/* generated */ self.type = type
/* generated */ self.numberOfLegs = numberOfLegs
}
}

class Dog: Animal {
let name: String

memberwise private init(type: String = "dog", numberOfLegs: Int = 4, n 
name: String) {
/* generated */ self.name = name
/* generated */ super.init(type: type, numberOfLegs: numberOfLegs);
}

memberwise convenience init(name: String) {
/* generated */ self.init(type: "dog", numberOfLegs: 4, n: name)
}
}

let d = Dog(name: "Fido")

The biggest thing about convenience inits is that the generation of the init 
needs to pull the defaults from the designated init. Also, for super.init(), 
it’s a straight label/name lookup for the designated init() only. Anything more 
fancy must be written by the user.

You also disallow private init, but that doesn’t need to happen with explicit 
members. That’s the beauty of giving the public API a real contract with names.

struct S {
let s: String
private let i: Int

memberwise init(name s: String, value i: Int = 12) {
/* generated */ self.s = s
/* generated */ self.i = i
}
}

Also, partial initialization could be possible, much like you proposed 
originally:

struct S {
let s: String
private let i: Int

memberwise init(name s: String) {
/* generated */ self.s = s
self.i = s.utf8.count
}
}

My concern is that this starts to be more complicated and magical. I’d actually 
cut this from the proposal.

The last change I would make is that if any property has an assignment in the 
declaration, it cannot be memberwise initialized.

struct S {
let s: String
let i: Int = 10

memberwise init(name s: String) {
/* generated */ self.s = s
}
}

In the above, i will always be 10.

-David

> On Dec 21, 2015, at 11:32 AM, Matthew Johnson via swift-evolution 
>  wrote:
> 
> I have completed a draft of the proposal I have been working on for flexible 
> memberwise initialization.  I am really looking forward to your input and 
> will be refining the proposal based on our discussion.
> 
> I am including a current snapshot of the proposal in this message.  I will 
> keep the proposal up to date on Github at this link:
> 
> https://github.com/anandabits/swift-evolution/blob/flexible-memberwise-initialization/proposals/-flexible-memberwise-initialization.md
>  
> 
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Proposal: Support for commit comments

[David Owens II via swift-evolution]

What you are talking about are source control hooks. They don’t belong in a 
language as a language is completely agnostic of a source control system, 
assuming on is even used.

> On Dec 21, 2015, at 3:04 PM, Amir Michail via swift-evolution 
>  wrote:
> 
> 
>> On Dec 21, 2015, at 6:03 PM, Brent Royal-Gordon  
>> wrote:
>> 
>>> If it is part of the language standard and is supported by Xcode, then many 
>>> source control systems/IDEs will support it also as it gives them a 
>>> competitive advantage.
>> 
>> Xcode is not part of the Swift.org project either.
> 
> It doesn’t have to be. But if Xcode supports it, then more people will know 
> about this language feature.
> 
>> 
>> -- 
>> Brent Royal-Gordon
>> Architechies
>> 
> 
> ___
> 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: Allow Type Annotations on Throws

[David Owens II via swift-evolution]

> I understand that Rust is not doing implicit conversions, but the effect for 
> the user is pretty much the same.  The try macro is converting the underlying 
> error to the type that can be propagated.  As I stated, Swift is not Rust and 
> deserves a different solution.  
> 
> Nevertheless, that does not minimize the need to solve the problem.  I 
> maintain that the problem solved by the try macro is a significant one that 
> is not addressed by the current proposal.  I would really like to see it 
> addressed one way or another.
> 
>> 
>> You could make it “nicer” by doing something like this:
>> 
>> try MyError.convertFrom(try 
>> funcThatThrowsAnErrorThatMustBeTranslatedItoMyPublishedError())
> 
> Can you elaborate on how you think this would work?  If 
> funcThatThrowsAnErrorThatMustBeTranslatedItoMyPublishedError actually throws 
> it will be propagated to the next enclosing catch clause.  
> MyError.convertFrom will not have a chance to do anything with it.

Here’s a full playground example (I’ve annotated in comments where the type of 
error could be described):

enum InternalError: ErrorType {
case Internal(value: Int)
}

enum PublishedError: ErrorType {
static func from(@autoclosure fn: () throws -> T) throws -> T {
do {
return try fn()
}
catch InternalError.Internal(let value) {
throw PublishedError.Converted(value: value)
}
catch {
fatalError("unsupported conversion")
}
}

case Converted(value: Int)
}


func example() {

func bad(value: Int) throws /* InternalError */ -> Int {
if value % 2 == 0 { throw InternalError.Internal(value: value) }
return value
}

func verbose(value: Int) throws /* PublishedError */ -> Int {
do {
return try bad(value)
}
catch InternalError.Internal(let value) {
throw PublishedError.Converted(value: value)
}
catch {
fatalError("unsupported conversion")
}
}

func convert(value: Int) throws /* PublishedError */ -> Int {
return try PublishedError.from(try bad(value))
}

do {
let r1 = try verbose(11)
print("verbose: \(r1)")

let r2 = try convert(9)
print("converted: \(r2)")
}
catch {
print("error: \(error)")
}

}

example()


As you can see, the “verbose()” and the “from()” conversion are basically the 
same implementation. What I’m saying is that I believe you can simply do the 
explicit conversion yourself without much fanfare (compare the verbose() and 
convert() implementations).

In the implementation of PublishedError.from() you can use Swift’s pattern 
matching to do all of your conversions in a single place. Note that where the 
implementation of “from” is at doesn’t matter, it could be on another type or a 
free function, whatever.

> Are you willing to explore adding *explicit* syntax to convert thrown errors 
> to your proposal?  That seems like it might be a reasonable compromise 
> between implicit conversions and manual boilerplate.  

The only boiler plate I’m seeing is the explicit conversion call: 
PublishedError.from(try bad(value))

Am I misunderstanding something? 

To me, this would be much more confusing:

func convert(value: Int) throws /* PublishedError */ -> Int {
return try bad(value) /* implicit conversion from InternalError -> 
PublishedError */
}

If there were implicit type conversions, this would have to be something that 
Swift supported all up. I’d be very hesitant to make this work for only errors. 
For example, how does implicit conversion work if we can later extend this to 
async behaviors? Do we have special conversions that can take an async error 
make it a synchronous error? How about vice-versa?

I guess I wouldn’t want to go further than having explicit conversions until we 
better understood all of those answers and how implicit type conversion would 
work in Swift generally. If I recall, Swift had implicit type conversion in the 
early versions, and it has been removed in most places. 

-David

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

Re: [swift-evolution] Proposal: Allow Type Annotations on Throws

[David Owens II via swift-evolution]

I’m just going to interject a few thoughts in here.

> On Dec 21, 2015, at 6:36 AM, Matthew Johnson  wrote:
> 
> Hi David,
> 
> (my paraphrase: pattern matching is great and solves more of my concerns than 
> I originally realized.) 

Awesome!

> I would also like to comment that there are some interesting related ideas 
> for enhancing enums in the "[Pitch] Use enums as enum underlying types” 
> thread.  They don’t directly impact the proposal but could make such use 
> cases even more convenient if they are pursued independently.

I’m not sure I really like any of those proposals, but feedback for those is 
better on that thread, and I’ve only taken a cursory look at them.

> The other concern I have is still valid, but I think a relatively 
> straightforward solution is possible.
> 
> (my paraphrase: Converting from an inner-error to a publicly exposed error is 
> tedious, boilerplate code.)

Maybe. I think that depends on the assumption that you do nothing other than 
convert the inner error to a published error. Also, it assumes that all 
“recoverable” inner errors stay “recoverable” outer errors.

I tend to use a lot of telemetry markers and assertions within my code, so it’s 
not a one-liner conversion.

do {
try some.implementation.detail.throwing.api()
}
catch {
// what happens here?
}

I actually think there are various options of what to do at this place:

Simply propagate the error out (basically untyped errors)
Wrap the error (still exposes the internal implementation details)
Convert the error to a published error type
Promote the error to a non-recoverable error (e.g. fatalError())

All of these can have additional code in place, such as telemetry/logging or 
debug assertions. While it might be the case that people simply want to wrap an 
error, can we say that is the safe way to deal with the errors? I’m not sure 
I’m willing to make that statement.

I, obviously, recommend against doing options #1 and #2 above. I’ll talk about 
conversion below. And I believe promotion would look something like this:

guard ((try? some.implementation.detail.throwing.api()) != nil) else { 
fatalError("bad mojo!") }

Or if I want the error:

do {
try some.implementation.detail.throwing.api()
}
catch {
Telemetry.LogFatalIssue(error)
fatalError("bad mojo!")
}

In an ideal world, I would also like to be able to do something like this:

guard try some.implementation.detail.throwing.api() else {
Telemetry.LogFatalIssue(error)
fatalError("bad mojo!")
}

But that’s a syntax that’s out-of-scope for this proposal as well.

> This is the problem that `From` addresses in Rust.  Swift is not Rust and our 
> solution will look different.  The point is that this is a problem and it can 
> and has been solved.
> 
> My suggestion is that we should allow implicit conversion during error 
> propagation.  If the published error type has one and only one non-failable, 
> non-throwing initializer that takes a single argument of the type that is 
> thrown (including enum case initializers with a single associated value of 
> the thrown type) that initializer is used to implicitly convert to the 
> published error type.  This conversion could be accomplished by synthesizing 
> the necessary boilerplate or by some other means.
> 
> Now we have:
> 
> func functionThatCallsUnderlingyingThrows(_ whichError: Bool) throws 
> MyPublishedError {
> try funcThatThrowsAnErrorThatMustBeTranslatedIntoMyPublishedError()
> }
> 
> This looks as it should.  We don’t pay a price of boilerplate for carefully 
> designing the errors we expose in our API contract.  This also handles 
> automatic wrapping of errors where that is appropriate.

I would argue against implicit conversion. Again, this is about consistency 
with the language. Also, Rust is using it’s macro system to generate the code; 
it’s not actually doing implicit conversions either.

You could make it “nicer” by doing something like this:

try MyError.convertFrom(try 
funcThatThrowsAnErrorThatMustBeTranslatedItoMyPublishedError())

All of the “boiler-plate” code (which you need to write the conversion code 
regardless) can be put where it needs to be and kept out of all of the call 
sites. You could then propose a “conversion” feature to Swift that would allow 
explicit conversions:

try funcThatThrowsAnErrorThatMustBeTranslatedItoMyPublishedError() as MyError

This could call the conversion initializers.

-David

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

Re: [swift-evolution] [Proposal] Swift 2.2: #if swift language version

[David Owens II via swift-evolution]

If we are going to support something like this, I’d rather see it be something 
everyone could leverage as there are many use cases for this feature:

#if available("package-name", "1.2.*")
#endif

Then at least everyone can opt-in to using it for availability checks. This 
should of course tie into the Swift Package Manager and use proper semver 
syntax (might as well use node’s example: https://docs.npmjs.com/misc/semver).

Another solution would be to simply factor out the code into separate files and 
add each to the appropriate build configuration. Then nothing new needs to be 
added.

-David

> On Dec 20, 2015, at 2:01 PM, James Campbell via swift-evolution 
>  wrote:
> 
> Also in future versions features may go away meaning older libraries may 
> assume that greater than swift 2 is all that is needed to imply 
> compatibility. Also libraries may be written against features they may not 
> know which version of swift it will get into. Additionally certain features 
> aren't available across platforms so how do you know what swift 2 means 
> across platforms ? 
> 
> Swift version conditionals are a useful fallback but we should also try and 
> make feature conditionals a first class citizen too. 
> 
> I love the @supports syntax in CSS, if we could do that then that would be 
> awesome :)  it's a great way of handling implementations across platforms 
> 
> Sent from my iPhone
> 
> On 20 Dec 2015, at 21:00, Andrey Tarantsov via swift-evolution 
>  wrote:
> 
>>> I suspect with the race to a stable language, the plan is to design 
>>> features as if the language were to stay solid.
>> 
>> Are you implying that Swift 4 will have zero new features? Nothing that 
>> libraries will want to use conditionally when available?
>> 
>> A.
>> 
>> ___
>> 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] Final by default for classes and methods

[David Owens II via swift-evolution]

These apps you’re referring too would still be possible. Reflection and method 
swizzling is an alternative to subclassing for working around bugs in authors 
frameworks without exposing the ability to subclass by default across all class 
types everywhere. In addition, if there are places where the author is casting 
to the specific type for some reason, the method swizzled approach will still 
work where as subclassing will not.

While Swift doesn’t have a full on reflection system yet, it’s on the roadmap. 
I’d much rather see us getting into safer, and frankly more correct, defaults 
while still providing mechanisms to do, what essentially boil down to hacks, to 
get stuff working.

-David

> On Dec 20, 2015, at 2:53 PM, Charles Srstka via swift-evolution 
>  wrote:
> 
> I agree with this. -1 to the proposal.
> 
> Charles
> 
>> On Dec 17, 2015, at 8:00 PM, Rod Brown via swift-evolution 
>> mailto:swift-evolution@swift.org>> wrote:
>> 
>> To play devils advocate, take for example UINavigationController in UIKit on 
>> iOS.
>> 
>> I’ve seen multiple times in multiple projects legitimate reasons for 
>> subclassing it, despite the fact that UIKit documentation says we “should 
>> not need to subclass it”. So if we relied on Apple to “declare”, they most 
>> probably wouldn’t, and these use cases (and some really impressive apps) 
>> would become impossible.
>> 
>> While I agree with all points made about “If it’s not declared subclassable, 
>> they didn’t design it that way”, I think that ties everyone’s hands too 
>> much. There is a balance between safety and functionality that must be 
>> worked out. I think this errs way too far on the side of safety.
>> 
>> Rod
>> 
>> 
>>> On 18 Dec 2015, at 12:51 PM, Javier Soto >> > wrote:
>>> 
>>> What if one framework provider thinks “you won’t need to subclass this ever”
>>> 
>>> If the framework author didn't design and implement that class with 
>>> subclassing in mind, chances are it's not necessarily safe to do so, or at 
>>> least not without knowledge of the implementation. That's why I think 
>>> deciding that a class can be subclassed is a decision that should be made 
>>> consciously, and not just "I forgot to make it final"
>>> On Thu, Dec 17, 2015 at 5:41 PM Rod Brown >> > wrote:
>>> My opinion is -1 on this proposal. Classes seem by design to intrinsically 
>>> support subclassing.
>>> 
>>> What if one framework provider thinks “you won’t need to subclass this 
>>> ever” but didn’t realise your use case for doing so, and didn’t add the 
>>> keyword? When multiple developers come at things from different angles, the 
>>> invariable situation ends with use cases each didn’t realise. Allowing 
>>> subclassing by default seems to mitigate this risk at least for the most 
>>> part.
>>> 
>>> I think this definitely comes under the banner of “this would be nice” 
>>> without realising the fact you’d be shooting yourself in the foot when 
>>> someone doesn’t add the keyword in other frameworks and you’re annoyed you 
>>> can’t add it.
>>> 
>>> 
>>> 
 On 18 Dec 2015, at 10:46 AM, Javier Soto via swift-evolution 
 mailto:swift-evolution@swift.org>> wrote:
 
>>> 
 Does it seem like there's enough interesest in this proposal? If so, what 
 would be the next steps? Should I go ahead and create a PR on the 
 evolution repo, describing the proposal version that Joe suggested, with 
 classes closed for inheritance by default outside of a module?
 
 Thanks!
 
 On Tue, Dec 8, 2015 at 7:40 AM Matthew Johnson via swift-evolution 
 mailto:swift-evolution@swift.org>> wrote:
 I understand the rationale, I just disagree with it.
 
 IMO adding a keyword to state your intention for inheritance is not a 
 significant obstacle to prototyping and is not artificial bookkeeping.  I 
 really don't understand how this would conflict with "consequence-free" 
 rapid development.  It is a good thing to require people to stop and think 
 before using inheritance.  Often there is a more appropriate alternative.
 
 The assumption that it is straightforward to fix problems within a module 
 if you later decide you made a mistake is true in some respects but not in 
 others.  It is not uncommon for apps to be monolithic rather than being 
 well factored into separate modules, with many developers contributing and 
 the team changing over time.  While this is not ideal it is reality.
 
 When you have the full source it is certainly *possible* to solve any 
 problem but it is often not straightforward at all.  Here is an example of 
 a real-work scenario app developers might walk into:
 
 1) A class is developed without subclassing in mind by one developer.
 2) After the original developer is gone another developer adds some 
 subclasses without stopping to think about whether the original developer 
>

Re: [swift-evolution] Final by default for classes and methods

[David Owens II via swift-evolution]

+1 to everything Jordan said here. 

Sent from my iPhone

> On Dec 19, 2015, at 7:21 PM, Jordan Rose via swift-evolution 
>  wrote:
> 
> 
>>> On Dec 7, 2015, at 20:30 , John McCall via swift-evolution 
>>>  wrote:
>>> 
 On Dec 7, 2015, at 7:18 PM, Matthew Johnson via swift-evolution 
  wrote:
 Defaults of public sealed/final classes and final methods on a class by 
 default are a tougher call. Either way you may have design issues go 
 unnoticed until someone needs to subclass to get the behavior they want. 
 So when you reach that point, should the system error on the side of rigid 
 safety or dangerous flexibility?
>>> 
>>> This is a nice summary of the tradeoff.  I strongly prefer safety myself 
>>> and I believe the preference for safety fits well with the overall 
>>> direction of Swift.  If a library author discovers a design oversight and 
>>> later decides they should have allowed for additional flexibility it is 
>>> straightforward to allow for this without breaking existing client code.  
>>> 
>>> Many of the examples cited in argument against final by default have to do 
>>> with working around library or framework bugs.  I understand the motivation 
>>> to preserve this flexibility bur don't believe bug workarounds are a good 
>>> way to make language design decisions. I also believe use of subclasses and 
>>> overrides in ways the library author may not have intended to is a fragile 
>>> technique that is likely to eventually cause as many problems as it solves. 
>>>  I have been programming a long time and have never run into a case where 
>>> this technique was the only way or even the best way to accomplish the task 
>>> at hand.
>>> 
>>> One additional motivation for making final the default that has not been 
>>> discussed yet is the drive towards making Swift a protocol oriented 
>>> language.  IMO protocols should be the first tool considered when dynamic 
>>> polymorphism is necessary.  Inheritance should be reserved for cases where 
>>> other approaches won't work (and we should seek to reduce the number of 
>>> problems where that is the case).  Making final the default for classes and 
>>> methods would provide a subtle (or maybe not so subtle) hint in this 
>>> direction.
>>> 
>>> I know the Swift team at Apple put a lot of thought into the defaults in 
>>> Swift.  I agree with most of them. Enabling subclassing and overriding by 
>>> default is the one case where I think a significant mistake was made.
>> 
>> Our current intent is that public subclassing and overriding will be locked 
>> down by default, but internal subclassing and overriding will not be.  I 
>> believe that this strikes the right balance, and moreover that it is 
>> consistent with the general language approach to code evolution, which is to 
>> promote “consequence-free” rapid development by:
>> 
>>  (1) avoiding artificial bookkeeping obstacles while you’re hacking up the 
>> initial implementation of a module, but
>> 
>>  (2) not letting that initial implementation make implicit source and binary 
>> compatibility promises to code outside of the module and
>> 
>>  (3) providing good language tools for incrementally building those initial 
>> prototype interfaces into stronger internal abstractions.
>> 
>> All the hard limitations in the defaults are tied to the module boundary 
>> because we assume that it’s straightforward to fix any problems within the 
>> module if/when you decided you made a mistake earlier.
>> 
>> So, okay, a class is subclassable by default, and it wasn’t really designed 
>> for that, and now there are subclasses in the module which are causing 
>> problems.  As long as nobody's changed the default (which they could have 
>> done carelessly in either case, but are much less likely to do if it’s only 
>> necessary to make an external subclass), all of those subclasses will still 
>> be within the module, and you still have free rein to correct that initial 
>> design mistake.
> 
> I think John summarized my position very well, so of course I'm going to come 
> in here and add more stuff. :-)
> 
> In working on the design for library evolution support ("resilience"), we've 
> come across a number of cases of "should a library author be able to change 
> this when they release v2 of their library?" Many times, the answer is it's 
> possible to do something in one direction, but not at all safe to go the 
> other way. For example, you can always add public methods to a class, but you 
> can't remove public methods because you don't know who's calling them. You 
> can mark them deprecated, but that doesn't help with any client apps that 
> have already been compiled and shipped.
> 
> One of the things that came up was "can you add 'final' to a class?" And of 
> course you can't, because you don't know who may have already subclassed it. 
> That's very unfortunate for a library author who simply forgot to add 'final' 
> when they were first writing the class.
> 
>

Re: [swift-evolution] [Proposal] function "return" optional keyword.

[David Owens II via swift-evolution]

-1 for me. Closures gain a special syntax because of their use case, 
specifically inlining locally. Functions don’t get that.

> On Dec 19, 2015, at 4:44 PM, Andrew Bennett via swift-evolution 
>  wrote:
> 
> +1 for consistency with closures
> 
> On Sun, Dec 20, 2015 at 8:15 AM, Stephen Christopher via swift-evolution 
> mailto:swift-evolution@swift.org>> wrote:
> The discussion I was remembering, comment courtesy of Chris: 
> https://devforums.apple.com/message/1014317#1014317 
> 
> 
> (linked from https://devforums.apple.com/thread/255242 
> )
> 
>  
> ___
> 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: Allow Type Annotations on Throws

[David Owens II via swift-evolution]

> On Dec 18, 2015, at 4:38 PM, Ricardo Parada  wrote:
> 
> Hi David
> 
> I started reading your proposal and I have a couple of questions. 
> 
> In the Enum Base ErrorType example you mentioned that it requires a "catch { 
> }" clause.  However the code is already covering the two possible Enum values 
> (OffBy1 and MutatedValue). Why is the "catch { }" required? I typed that code 
> into a playground and I did not get any errors. Are you saying that because 
> the Enum type could add a value in the future?

Playgrounds are basically in an anonymous function that throws, so the problem 
doesn’t show up there at the top level. Copy this into your playground.

enum MyError: ErrorType {
case OnlyOne
}

func thrower() throws { throw MyError.OnlyOne }

func nolies() {
do {
try thrower()
}
catch MyError.OnlyOne { print("handled") }
// catch { print("compiler error until uncommented") }
}

> Also, you proposed the catch clause to use error as the name of the constant 
> holding the error.  Wouldn't it be better to let the programmer decide the 
> name rather than hard coding it to use error? For example:
> 
> catch e where e.value == 0 { print("0") }
> catch e where e.value == 1 { print("1") }
> catch { print("nothing") }

The “error” name is already specified in the Swift rules for what the constant 
is. I don’t see any compelling reason to propose a change to that.

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

Re: [swift-evolution] Proposal - Allow properties in Extensions

[David Owens II via swift-evolution]

> On Dec 18, 2015, at 3:34 PM, Joe Groff via swift-evolution 
>  wrote:
> 
> 
>> On Dec 18, 2015, at 3:24 PM, Kevin Ballard via swift-evolution 
>> mailto:swift-evolution@swift.org>> wrote:
>> 
>> AFAIK there's no precedent today for extensions in the same module being 
>> able to do things that extensions in other modules can't do (beyond 
>> accessing `internal` members of course). I'm not completely opposed to the 
>> idea, but I would want to be very careful and make sure there's an extremely 
>> clear benefit to changing it so extensions in the same module can add extra 
>> storage.
>> 
>> One potentially large downside is you can no longer look at a type 
>> declaration and find out how large it is. For example, I could define
>> 
>> struct Foo {
>>var x: Int
>> }
>> 
>> and it looks like a tiny struct, but I could then add an extension in a 
>> separate file that bloats that out to some ridiculously massive struct, and 
>> that wouldn't be obvious from looking at it.
>> 
>> That said, when looking at a definition imported from another module, you 
>> can't see which properties are computed and which are stored anyway, so it's 
>> maybe not a huge deal (although you can assume any property defined in an 
>> extension is computed). But it is still something to consider.
> 
> True, this is a tradeoff. We've discussed moving in the direction of allowing 
> same-module extensions to do anything that can be done in the original type 
> declaration, to allow freedom of organization without arbitrary rules about 
> what must go in the type, but sizing instances was one of our concerns. (You 
> could always peek at the LLVM IR if you want to know for sure what's getting 
> generated.)


Have you considered using “partial” or “extendable" for these types of 
definitions (similar to C# partials) to reduce this confusion?

extendable struct Foo {
   var x: Int
}

When the keyword is there, all bets are off that the layout of the struct only 
contains a single member. Then extensions, defined within the same module, 
could add to it.

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

Re: [swift-evolution] Proposal: Allow Type Annotations on Throws

[David Owens II via swift-evolution]

> On Dec 18, 2015, at 9:41 AM, Matthew Johnson  wrote:
> 
> I’m not asking for you to speak for them.  But I do think we need to learn 
> from communities that are having success with typed error handling.  Your 
> proposal would be stronger if it went into detail about how it would avoid 
> the problems that have been encountered in other languages.  The experience 
> of Rust could help to make that case as it is concrete and not hypothetical.

Sure, it could. It’s also anecdotal. It’s not necessarily true that something 
that works well in one context works well in another. It’s good to note that 
typed errors are wholly considered bad, but I’m not sure how much further we 
need to go then that. If you have specifics, then I could probably add them as 
an addendum to the proposal.

> My understanding is that Rust uses static multi-dispatch to do this.  I don’t 
> believe it has anything to do with structural sum types.  Rust error handling 
> uses a Result type with a single error case: 
> http://doc.rust-lang.org/book/error-handling.html 
> .

That example takes you through many of the options available. In the end, you 
end up at the sum-type for the error:
fn search>
 (file_path: &Option, city: &str)
 -> Result, CliError> {
...
}
It’s the CliError which is defined as:
enum CliError {
Io(io::Error),
Csv(csv::Error),
NotFound,
}
The From() function essentially allows the try! macro to expand these in a 
nicer way.

So back to the proposal, one of the key things is to promote the `error` 
constant throughout the catch-clauses. This means that we can already leverage 
Swift’s pattern matching to solve this problem:

enum Combined {
case IO(String)
case Number(Int)
}

func simulate(err: Combined) {
switch err {
case let Combined.IO(string) where string == "hi": print("only hi!")
case let Combined.IO(string): print(string)
case let Combined.Number(value): print(value)
}
}

simulate(Combined.IO("hi"))
simulate(Combined.IO("io"))
simulate(Combined.Number(9))

It’s not hard to use Swift’s pattern matching to extract out the inner 
information on an associated value enum and white the case/catch clauses. So 
unless I’m missing something, I think Swift already provides a good mechanism 
to do what you’re asking for, with the caveat that the `error` constant is 
promoted to be usable in the catch-clauses similar to how the switch-statements 
work.

Maybe adding this to the proposal would clarify usage?

> How does this create a fragile API surface area?  Adding a new error type to 
> the signature would be a breaking change to the API contract.  This is really 
> no different than changing the type of error that can be thrown under your 
> proposal.

It’s the same fragility that enums create; this was covered in the criticisms 
section. The likelihood of adding additional error cases is much greater than a 
change that would completely change the type of the error.

> 
>> I see this functionality as a general limitation in the language. For 
>> example, errors are not the only context where you may want to return a type 
>> of A, B, or C. There have been other proposals on how we might do that in 
>> Swift. If and when it was solved in the general case for type parameters, I 
>> can’t foresee a compelling reason why it wouldn’t work in this context as 
>> well.
> 
> That makes sense in some ways, but I don’t think it’s unreasonable to ask for 
> some analysis of whether a better design for typed errors would be possible 
> if we had them.  IMO it’s pretty important to get the design of typed errors 
> right if / when we add them.  If we don’t it will be considered a major 
> mistake and will lead to a lot of less than desirable outcomes down the road.
> 
> I also think typed errors may be one of the more important use cases for 
> structural sum types of some kind.  If we are able to show that design 
> problems that cannot be solved without them can be solved with them that 
> might influence whether they are added or not.  It might also influence when 
> it makes sense to add support for typed errors to the language.

The problem can be solved without implicitly generated sum types though. The 
design of typed errors, as proposed, is to be consistent with the Swift type 
system today. Regardless, I’ve added a response in the “cirticisms” section 
that hopefully addresses this in some manner - basically, yes it would be 
helpful, but out of scope for this proposal.

> That approach would make catch clauses rather clunky by nesting errors inside 
> of associated values.  If you’re advocating for this approach do you have any 
> ideas on how to streamline syntax for catching them?

See above example. Does that address this concern?

-David

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

Re: [swift-evolution] Proposal: Allow Type Annotations on Throws

[David Owens II via swift-evolution]

I’d be ok with having enum/struct only error types, however, I don’t have a 
compelling reason to really limit their usage context. Also, that would 
complicate the bridging with NSError at the moment.

FYI: I’ve added some updates to the criticism section to qualify the Java 
checked-exceptions and the multiple error type annotations.

-David

> On Dec 18, 2015, at 9:21 AM, Félix Cloutier  wrote:
> 
> Oh, I see what you mean. I considered polymorphic types to be class 
> hierarchies, when you're talking about ErrorType polymorphism.
> 
> Yes, I think that the compiler should be aware of what the function can 
> throw, but I would be happier if it stayed a bit inconvenient to use 
> reference types.
> 
>> Le 18 déc. 2015 à 12:17:06, Félix Cloutier via swift-evolution 
>>  a écrit :
>> 
>> I'm not sure I understand your comment either. If I understand correctly, 
>> you say that the problem I describe is applicable only to polymorphic types 
>> (which is true). However, you then say that the only option today is 
>> polymorphic error types. Isn't that an issue? (Also, why is it the only 
>> option today?)
>> 
>>> Le 18 déc. 2015 à 11:58:44, David Owens II  a écrit :
>>> 
>>> 
 On Dec 18, 2015, at 7:03 AM, Félix Cloutier  wrote:
 
 For this reason, I don't like to encourage throwing polymorphic types, and 
 I think that it's a misconception to pretend that having a single type in 
 the throws annotation ensures that the function throws a single type. In 
 my opinion, the fact that it's currently possible but awkward to use 
 polymorphic types as errors is exactly as much support as the feature 
 should receive.
>>> 
>>> I don’t follow this. Declaring a type that is an enum or a struct 
>>> absolutely guarantees that the function only returns a single type. If the 
>>> type is a class-based error, then sure, there’s not guarantee.
>>> 
>>> However, the only option today is polymorphic error types. 
>>> 
>>> -David
>>> 
>> 
>> ___
>> 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: Allow Type Annotations on Throws

[David Owens II via swift-evolution]

> On Dec 18, 2015, at 7:03 AM, Félix Cloutier  wrote:
> 
> For this reason, I don't like to encourage throwing polymorphic types, and I 
> think that it's a misconception to pretend that having a single type in the 
> throws annotation ensures that the function throws a single type. In my 
> opinion, the fact that it's currently possible but awkward to use polymorphic 
> types as errors is exactly as much support as the feature should receive.

I don’t follow this. Declaring a type that is an enum or a struct absolutely 
guarantees that the function only returns a single type. If the type is a 
class-based error, then sure, there’s not guarantee.

However, the only option today is polymorphic error types. 

-David

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

Re: [swift-evolution] Proposal: Allow Type Annotations on Throws

[David Owens II via swift-evolution]

> On Dec 18, 2015, at 5:53 AM, Matthew Johnson  wrote:
> 
> David,
> 
> Thank you for taking the time to continue working on a proposal for typed 
> throws.  I agree that this feature is very desirable and appreciate the work 
> you’re doing to bring forward a proposal.  I think it’s a great start but 
> also has some room for improvement.
> 
> First, I think it could be strengthened by incorporating some learning from 
> Rust.  My impression is that the Rust community is very happy with typed 
> error handling.  Adding some detail about their experience would provide a 
> counter-example to those who are concerned about the experience in Java and 
> C++.

I’m not involved in the Rust community so I wouldn’t feel comfortable making 
claims for them. 

> I agree that error types are an important part of an API contract.  One of 
> the big hurdles to doing this well is the need to catch errors when all that 
> needs to be done is to wrap and rethrow them.  Ideally should not need to do 
> this just to perform a simple type translation to map the underlying error 
> into the type we wish to expose as part of a stable API contract.  You might 
> want to take a look at the From mechanism Rust uses to facilitate this.  IMO 
> a proposal for typed error handling should address this issue in some way 
> (even if the author determines this mechanism is not necessary or a good 
> design cannot be identified).

The From() construct seems like a map(T) -> U problem, but it seems heavily 
tied into the ability to create sum types. Swift doesn’t have this feature, and 
that feature is out-of-scope for this proposal. More on this later.

> I would also like to see much more detail on why you think allowing a 
> function to throw multiple error types is problematic.  My impression is that 
> you have concerns from a usability point of view.  I am on the fence here to 
> some degree, but definitely leaning in the direction that allowing a function 
> to throw multiple error types is better.  

Sure. There’s no functionality today to auto-generate a sum type in Swift 
today, and that is what this request really is. If you want to return multiple 
return types, then you need to do exactly what Rust does and create a sum type 
that composes the various types of errors. This exposes the same potential 
fragile API surface as extending enums do. I did call this part out 
specifically.

I see this functionality as a general limitation in the language. For example, 
errors are not the only context where you may want to return a type of A, B, or 
C. There have been other proposals on how we might do that in Swift. If and 
when it was solved in the general case for type parameters, I can’t foresee a 
compelling reason why it wouldn’t work in this context as well.

> I am willing to be convinced that a single error type is better than multiple 
> error types but the current proposal does not provide a compelling argument 
> in that direction.  It just says “Java checked exceptions”.  I know these 
> have been pretty much universally considered a serious design mistake.  My 
> impression is that there are quite a few reasons for that.  I don’t have any 
> direct experience with Java and am not familiar with the details.  If you 
> could elaborate on specifically why you believe allowing multiple error types 
> was a significant contributor to the problem in a manner that indicates that 
> they will be a problem in any language that includes them I would appreciate 
> that.  Links would be sufficient if they are focused on answering this 
> particular question.  

I guess I should have just specifically called this out in the proposal. It’s 
not because of “Java checked exceptions”, it’s because nowhere else in the 
language are types allowed to be essentially annotated in a sum-like fashion. 
We can’t directly say a function returns an Int or a String. We can’t say a 
parameter can take an Int or a Double. Similarly, I propose we can’t say a 
function can return an error A or B.

Thus, the primary reason is about type-system consistency.

Swift already supports a construct to create sum types: associated enums. What 
it doesn’t allow is the ability to create them in a syntactic shorthand. In 
this way, my error proposal does the same thing as Rust: multiple return types 
need to be combined into a single-type - enum.

On to Félix’s comments now!

-David

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

Re: [swift-evolution] [Review] Require self for accessing instance members

[David Owens II via swift-evolution]

* What is your evaluation of the proposal?

+1.

* Is the problem being addressed significant enough to warrant a change to 
Swift?

Yes. I believe that is much clarity lost. I also really dislike the 
inconsistent requirement of self in multiple contexts. When we talk about 
language rules, I really think it’s a disservice when there needs to be a lot 
of qualifiers. You use “self” in this context, but you don’t have to in this 
one, well, unless you then do that… This kind of explanation, in my opinion, 
signals a design flaw.

I’ve never encountered a bug in a language that requires self to access its 
members with shadowing, but I have had the opposite experience many, many 
times. While this doesn’t fix all shadowing issues, I do think it fixes the 
vast majority of them.

* Does this proposal fit well with the feel and direction of Swift?

Yes.

* If you have you used other languages or libraries with a similar feature, how 
do you feel that this proposal compares to those?

I’ve used languages on both sides. Most recently, I’ve been working with 
TypeScript. I don’t know the language well (at all really), it requires self 
for member access. I have to say, it’s really been a help for understanding 
what is where.

* How much effort did you put into your review? A glance, a quick reading, or 
an in-depth study?

I’ve read through the threads and proposal and experience from languages that 
don’t require this and do.

-David

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

[swift-evolution] Proposal: Allow Type Annotations on Throws

[David Owens II via swift-evolution]

This a significantly updated proposal for typed annotations on the `throws` 
construct. The previous was closed due to not be complete; I believe I’ve 
addressed all of those concerns.

https://github.com/owensd/swift-evolution/blob/master/proposals/allow-type-annotations-on-throw.md

—

Allow Type Annotation on Throws
Proposal: SE- 
Author(s): David Owens II 
Status: Pending Approval for Review
Review manager: TBD
Introduction
The error handling system within Swift today creates an implicitly loose 
contract on the API. While this can be desirable in some cases, it’s certainly 
not desired in all cases. This proposal looks at modifying how the error 
handling mechanism works today by adding the ability to provide a strong API 
contract.

Error Handling State of the Union
This document will use the terminology and the premises defined in the Error 
Handling Rationale 
 
document.

To very briefly summarize, there are four basic classification of errors:

Simple Domain Errors
Recoverable Errors
Universal Errors
Logic Failures
Each of these types of errors are handled differently at the call sites. Today, 
only the first two are directly handled by Swift error handling mechanism. The 
second two are uncatchable in Swift (such as fatalError(), ObjC exceptions, and 
force-unwrapping of null optionals).

Simple Domain Errors

As stated in Error Handling Rationale 
 
document, the “Swift way” to handle such errors is to return an Optional.

func parseInt(value: String) -> Int? {}
The simple fact of the result being Optional.None signifies that the string 
could not be parsed and converted into an Int. No other information is 
necessary or warranted.

Recoverable Errors

In this context, these are errors that need to provide additional information 
to the caller. The caller can then decide a course of action that needs to be 
taken. This could be any number of things, including, but not limited to, 
logging error information, attempting a retry, or potentially invoking a 
different code path. All of these errors implement the ErrorType protocol.

func openFile(filename: String) throws {}
The throws keyword annotates that the function can return additional error 
information. The caller must also explicitly make use of this when invoking the 
function.

do {
  try openFile("path/to/somewhere")
}
catch {}
Errors are able to propagate if called within another context that can throw, 
thus alleviating the annoying “catch and rethrow” behavior:

func parent() throws {
  try openFile("path/to/somwhere")
}
Lastly, functions can be marked to selectively throw errors if they take a 
function parameter that throws with the rethrows keyword. The really 
interesting part is that it’s only necessary to use try when calling the 
function with a throwing closure.

func openFile(filename: String) throws {}
func say(message: String) {}

func sample(fn: (_: String) throws -> ()) rethrows {
try fn("hi")
}

try sample(openFile)
sample(say)
Converting Recoverable Errors to Domain Errors

Swift also has the try? construct. The notable thing about this construct is 
that it allows the caller to turn a “Recoverable Error” into a “Simple Domain 
Error”.

if let result = try? openFile("") {}
ErrorType Implementors

Errors are implemented using the ErrorType protocol. Since it is a protocol, 
new error types can be a class, a struct, or an enum. A type qualified throws 
clause would allow code authors to change the way that the catch-clauses need 
to be structured.

Enum Based ErrorType

When enums are used as the throwing mechanism, a generic catch-clause is still 
required as the compiler doesn’t have enough information. This leads to 
ambiguous code paths.

enum Errors: ErrorType {
case OffBy1
case MutatedValue
}

func f() throws { throw Errors.OffBy1 }

do {
try f()
}
catch Errors.OffBy1 { print("increment by 1") }
catch Errors.MutatedValue { fatalError("data corrupted") }
The above code requires a catch {} clause, but it’s ambiguous what that case 
should do. There is no right way to handle this error. If the error is ignored, 
we’re now in the land of “Logic Errors”; the code path should never be hit. If 
we use a fatalError() construct, then we are now in the land of converting a 
potential compiler error into a “Universal Error”.

Both of these are undesirable.

Struct and Class Based ErrorType

In the current design, errors that are thrown require a catch-all all the time. 
In the proposed design, which will be explained further, a catch-all would not 
be required if there was a case-clause that matched the base type.

class ErrorOne: ErrorType {}
func g() throws { throw ErrorOne() }

do {
try g()
}
catch is ErrorOne { print("ErrorOne") }
The advantage in these cases are different, these cases do not allow pattern 
matching over the error type members (as yo