Re: [swift-evolution] [Pitch] Let's talk about submodules

[Rien via swift-evolution]

Maybe we should try to collect what people want from submodules first.

I wanted modules for organisational purposes, however with the arrival of SPM 
that need has been almost completely removed. At least to the point that I do 
not feel that they are absolutely necessary.

Have the people who want modules tried SPM yet?

PS: be prepared for additional access levels requests when modules are 
available… :-0

Regards,
Rien

Site: http://balancingrock.nl
Blog: http://swiftrien.blogspot.com
Github: http://github.com/Balancingrock
Project: http://swiftfire.nl





> On 21 Feb 2017, at 02:36, Brent Royal-Gordon via swift-evolution 
>  wrote:
> 
> Okay, lots of people want to have some kind of submodule feature, so I'd like 
> to sketch one out so we can hopefully agree on what submodules might look 
> like.
> 
> ***
> 
> Any group of Swift files can be grouped together to form a submodule. 
> Submodules belong within a particular module, and have a dotted name: If 
> `ModKit` is a module, it might have a submodule called `ModKit.Foo`. 
> Submodules can be nested within one another: `ModKit.Foo.Bar` is a submodule 
> of `ModKit.Foo`, which is a submodule of `ModKit`.
> 
> No new access levels are necessary. `internal` APIs are only visible within 
> the submodule they're declared in; a module cannot see its submodules' 
> `internal` APIs, and a submodule cannot see its parent module's `internal` 
> APIs. If a submodule wants to expose some of its APIs to its parent or 
> sibling modules, it must mark them as `public` or `open`. Then they can 
> import the submodule to see its APIs:
> 
>   import ModKit.Foo
> 
> By default, outside modules cannot import a submodule. But an import in the 
> parent module can be decorated by an access control keyword to allow that:
> 
>   /// Any module outside ModKit can import ModKit.Foo and access its 
> `public` and `open` APIs.
>   open import ModKit.Foo
> 
>   /// Any module outside ModKit can import ModKit.Foo and access its 
> `public` and `open` APIs, 
>   /// except `open` APIs are treated as `public`.
>   public import ModKit.Foo
> 
> Imports may also be decorated by the `@exported` attribute, which exposes the 
> submodule's APIs as though they were parent module APIs:
> 
>   @exported open import ModKit.Foo
> 
>   @exported public import ModKit.Foo
> 
> (This is sort of half-implemented already in a buggy `@_exported` attribute.)
> 
> Finally, the standard syntax for importing individual symbols can be used to 
> cherry-pick types to treat differently:
> 
>   // Most ModKit.Foo APIs are not importable...
>   import ModKit.Foo
> 
>   // ...but SomeEnum can be imported as public...
>   public import enum ModKit.Foo.SomeEnum
> 
>   // ...SomeClass can be imported as open...
>   open import class ModKit.Foo.SomeClass
> 
>   // And ImportantStruct will import whenever you import ModKit.
>   @exported public import struct ModKit.Foo.ImportantStruct
> 
> (This syntax should be enhanced to allow cherry-picked importing of global 
> functions, constants, and variables.)
> 
> If there are several different `import`s covering the same submodule or 
> submodule symbol, the most permissive one wins.
> 
> (In large projects, `public`, `open`, and `@exported` imports will most 
> likely all be put in a single Policy.swift file or something, but this is not 
> enforced by the language.)
> 
> A submodule may not import any direct parent module (parent, grandparent, 
> etc.), but may import any other submodule in the same module. This list shows 
> permitted imports for a project with four modules/submodules:
> 
>   ModKit
>   - ModKit.Foo
>   - ModKit.Foo.Bar
>   - ModKit.Quux
>   ModKit.Foo
>   - ModKit.Foo.Bar
>   - ModKit.Quux
>   ModKit.Foo.Bar
>   - ModKit.Quux
>   ModKit.Quux
>   - ModKit.Foo
>   - ModKit.Foo.Bar
> 
> However, submodules may not form circular dependencies through imports—if 
> `ModKit.Quux` imports `ModKit.Foo`, then `ModKit.Foo` cannot import 
> `ModKit.Quux`. The `#if canImport()` feature cannot be used to probe for 
> other submodules within the same top-level module you're in.
> 
> At the compiler driver level, a submodule is specified by giving a 
> `-module-name` parameter with a dot in it. When a file is compiled, only the 
> filenames of the other .swift files in the same module are specified, along 
> with .o files for any submodules; then all the .o files within that submodule 
> are linked into a single .o file for the whole submodule. So files in 
> `ModKit.Foo` would be compiled with only the .swift files in `ModKit.Foo` and 
> the .o file for `ModKit.Foo.Bar`; then all the `ModKit.Foo` .o files would be 
> linked into one .o file for the top-level `ModKit` to use. None of 
> `ModKit.Foo`'s .swift files would be included in the command line when 
> compiling the top-level `Mod

Re: [swift-evolution] [Draft] Fix Private Access Levels

[Rien via swift-evolution]

I don’t know if you want to add this to the ‘criticism’ or not.

1) The information content added by “fileprivate” is questionable because of 
the ‘soft default’:

- People will switch from private to fileprivate without much thought if that 
is desirable or not.
- Other people will default to ‘fileprivate’, necessary or not.


2) Since the difference between ‘fileprivate’ and  ‘private’ only works within 
a file, anybody who is affected by it also has the possibility to change it 
from one to the other. Making the distinction between them rather arbitrary. 
Teams relying on the distinction may find themselves in a place where a 
developer changed private to fileprivate for a quick investigation/solution, 
and forgetting to revert the change before committing his solution. This error 
might remain undiscovered until several revisions later (or never).


3) Mixing scope and file based access levels makes the entire access level 
concept hard to understand.


Regards,
Rien

Site: http://balancingrock.nl
Blog: http://swiftrien.blogspot.com
Github: http://github.com/Balancingrock
Project: http://swiftfire.nl





> On 21 Feb 2017, at 07:58, David Hart via swift-evolution 
>  wrote:
> 
> Hello list,
> 
> Matthew Johnson and I have been putting our proposals together towards a 
> joint “let’s fix private access levels” proposal. As the community seems 
> quite divided on the issue, we offer two solutions in our proposal to let the 
> community debate and to let the core team make the final decision.
> 
> I’d like to concentrate this round of feedback on the quality of the 
> proposal, and not on the merits of Solution 1 or 2. thoughts?
> 
> https://github.com/hartbit/swift-evolution/blob/fix-private-access-levels/proposals/-fix-private-access-levels.md
> 
> David.
> 
> Fix Private Access Levels
> 
>   • Proposal: SE-
>   • Authors: David Hart, Matthew Johnson
>   • Review Manager: TBD
>   • Status: TBD
> Introduction
> 
> This proposal presents the problems the came with the the access level 
> modifications in SE-0025 and presents two community driven solutions to fix 
> them. As a consensus will not easily emerge, this proposal will allow a last 
> round of voting and let the core team decide. Once that is done, this 
> proposal will be ammended to describe the chosen solution.
> 
> Motivation
> 
> Since the release of Swift 3, the access level change of SE-0025 was met with 
> dissatisfaction by a substantial proportion of the general Swift community. 
> Before offering solutions, lets discuss how and why it can be viewed as 
> actiely harmful, the new requirement for syntax/API changes.
> 
> Criticisms of SE-0025
> 
> There are two primary criticism that have been offered.
> 
> The first is that private is a "soft default" access modifier for restricting 
> access within a file. Scoped access is not a good behavior for a "soft 
> default" because it is extremely common to use several extensions within a 
> file. A "soft default" (and therefore private) should work well with this 
> idiom. It is fair to say that changing the behavior of private such that it 
> does not work well with extensions meets the criteria of actively harmful in 
> the sense that it subtly encourages overuse of scoped access control and 
> discourages the more reasonable default by giving it the awkward name 
> fileprivate.
> 
> The second is that Swift's system of access control is too complex. Many 
> people feel like restricting access control to scopes less than a file is of 
> dubious value and therefore wish to simplify Swift's access control story by 
> removing scoped access. However, there are many others who like the ability 
> to have the compiler verify tighter access levels and believe it helps make 
> it easier to reason about code which is protecting invariants.
> 
> Detailed design
> 
> Both authors agree that the private keyword should be reverted back to its 
> Swift 2 file-based meaning, resolving the first criticism. But the authors 
> disagree on what should be done about the scoped access level and the 
> following solutions represent the two main opinions in the community:
> 
> Solution 1: Remove the scoped access level
> 
> Compared to a file-based access level, the scoped-based access level adds 
> meaningful information by hiding implementation details which do not concern 
> other types or extensions in the same file. But is that distinction between 
> private and fileprivate actively used by the larger community of Swift 
> developers? And if it were used pervasively, would it be worth the cognitive 
> load and complexity of keeping two very similar access levels in the 
> language? This solution argues that answer to both questions is no and that 
> the scoped access level should be removed to resolve the complexity criticism.
> 
> This solution has the added advantage of leaving the most design 
> breathing-room for future discussions about access levels in regards to 
> submodules.

Re: [swift-evolution] [Proposal Draft] Remove open Access Modifier

[Rien via swift-evolution]

While I am in favor of this, I do think this should not be a proposal on its 
own, rather it should be folded into a general overhaul of the entire access 
level structure.

Regards,
Rien

Site: http://balancingrock.nl
Blog: http://swiftrien.blogspot.com
Github: http://github.com/Balancingrock
Project: http://swiftfire.nl





> On 21 Feb 2017, at 07:44, Dimitri Racordon via swift-evolution 
>  wrote:
> 
> Hi all,
> 
> Here’s a draft proposal following 
> https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170220/032576.html
> .
> 
> The idea is simplify Swift’s syntax by getting rid of the `open` access 
> modifier.
> 
> A rendered version of the proposal is available here: 
> https://github.com/kyouko-taiga/swift-evolution/blob/master/proposals/-remove-open-access-modifier.md
> The raw version follows:
> 
> # Remove open Access Modifier
> 
> * Proposal: [SE-](-remove-open-access-modifier.md)
> * Author: [Dimitri Racordon](
> https://github.com/kyouko-taiga
> ), Joanna Carter
> * Status: **Awaiting review**
> * Review manager: TBD
> 
> ## Introduction
> 
> Swift allows classes, methods, properties and subscripts to be marked as 
> `final`, hence disallowing their subclassing/overriding inside **and** 
> outside of their defining module.
> 
> It also features two access levels `open`, which allows an entity to be 
> accessed outside its defining module, and `public`, which gives the same 
> access level the former **and** allows the entity to be subclassed/overridden.
> 
> There's a clear overlap between `open` and `public`, as they essentially 
> represent the same access control within the boundaries of a module, and do 
> not add any benefit from outside them, as `final` is sufficient to prohibit 
> subclassing/overriding.
> 
> Swift-evolution thread: ['Public' class visibility specifiers](
> https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170220/032576.html
> )
> 
> 
> ## Motivation
> 
> Swift has currently 5 access levels, in the form of:
> 
> * `private`, restricting the use of an entity to its enclosing declaration;
> * `fileprivate`, restricting the use of an entity to its defining source file:
> * `internal`, restricting the use of an entity to its defining module;
> * `public`, allowing the entity to be accessed anywhere;
> * `open`, allowing the entity to be accessed anywhere **and** allowing the 
> entity to be subclassed/overridden outside of their defining module.
> 
> From inside a module, `open` and `public` represent exactly the same access 
> level (everything is visible **and** can be subclassed/overridden).
> From outside a module, `public` is actually akin to `final`.
> 
> ```swift
> // Module 1
> // 
> 
> open class OpenClass {}
> public class PublicClass {}
> 
> public final class PublicFinalClass {}
> 
> // The first two classes above have the same access level.
> class derivedFromOpen: OpenClass {}
> class derivedFromPublic: PublicClass {}
> 
> // Module 2
> // 
> 
> class derivedFromOpenOutside: OpenClass {}
> 
> class derivedFromPublicOutside: PublicClass {}
> // Error: Cannot inherit from non-open class ...
> 
> class derivedFromPublicFinalOutside: PublicFinalClass {}
> // Error: Inheritance from a final class ...
> ```
> 
> Hence, the sole use-case of using both `public` and `final` is for an entity 
> that *inside* its defining module should not be subclassed/overridden.
> 
> ```swift
> // Module 1
> // 
> 
> class derivedFromPublicFinal : PublicFinalClass {}
> // Error: Inheritance from a final class ...
> ```
> 
> We believe this use case is rare and not worth the additional complexity of 
> having an `open` access level in the language.
> Besides, `open` is only applicable on classes and class members while the 
> others can be used on other entities (protocols, structures, ...).
> This asymmetry adds to the complexity of an `open` access level.
> 
> In order to simplify the syntax of Swift, we propose to **remove the `open` 
> access modifier**.
> 
> ## Proposal
> 
> Remove the `open` access modifier from Swift.
> 
> ## Source compatibility
> 
> This is a breaking change, as the `open` keyword would disappear from the 
> language.
> However, a fixit would be quite easy to put in place, simply replacing `open` 
> with `public`.
> 
> ## Alternative considered
> 
> Not removing the `open` access modifier from the language and keep the status 
> quo.
> 
> 
> ___
> 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] A Comprehensive Rethink of Access Levels in Swift

[Rien via swift-evolution]

Very well written.

Personally I am in favor of very simple systems and to put the responsibility 
for an application by the application developer (not a library developer). 
Though I understand that in some cases (Apple!) the developer is the 
end-customer, and this creates special circumstances warranting concessions on 
the achievable simplicity.

While it is possible to create an even simpler access level system, I think the 
system you proposed is probably the best compromise between “simple enough” and 
“complex enough”, and I could certainly live with it.

The final word (imo) should come after the submodule’s discussion reaches its 
inevitable peak.

Regards,
Rien

Site: http://balancingrock.nl
Blog: http://swiftrien.blogspot.com
Github: http://github.com/Balancingrock
Project: http://swiftfire.nl





> On 23 Feb 2017, at 22:56, Nevin Brackett-Rozinsky via swift-evolution 
>  wrote:
> 
> Introduction
> 
> There has been a deluge of discussion about access levels lately, all 
> attempting to simplify the situation. Shortly after Swift 3 was released, 
> many people realized that the new access modifier story was far more complex 
> than the old one, and expressed the belief that the changes may have been a 
> mistake.
> 
> In the months that followed, more and more people came to share the same 
> view, and stage 2 of Swift 4 has seen a profusion of proposals addressing the 
> issue. These proposals are generally small and focus on changing just one 
> aspect of access control. However, given the situation we are in now, it is 
> important to look at the problem in its entirety and arrive at a cohesive 
> solution.
> 
> Background
> 
> During the Swift 3 timeframe there were lengthy debates about access control. 
> The end results were to adopt SE-0025, which introduced the ‘fileprivate’ 
> keyword and made ‘private’ scope-based, and SE-0117, which made ‘public’ 
> classes closed by default and introduced the ‘open’ keyword. At the time, 
> there was broad agreement (and some dissent) that these were the right 
> changes to make.
> 
> That belief, as well as the numerous arguments which led to it, were 
> well-informed and thoughtfully considered. However, due to the inevitable 
> linear nature of time, they were not based on first-hand experience with the 
> new changes. Upon the release of Swift 3, we all gained that first-hand 
> experience, and it quickly became apparent to many people that the new access 
> control system was needlessly complicated, and not at all the improvement it 
> had been heralded as.
> 
> Rather than make it easy to encapsulate implementation details of related 
> types across multiple files, we had instead doubled down on requiring that 
> many things go in a single file or else reveal their secrets to the entire 
> module. Even worse, the new scope-based ‘private’ discouraged the preferred 
> style of using extensions to build up a type. To cap it off, we went from 
> needing to know two access modifier keywords (‘public’ and ‘private’) to 
> needing to know four of them (‘private’, ‘fileprivate’, ‘public’, and ‘open’) 
> without even providing a way to share details across a small number of 
> related files.
> 
> Motivation – Overview
> 
> Many different ideas for access control have been expressed on the Swift 
> Evolution mailing list. Some people want ‘protected’ or ‘friend’ or 
> ‘extensible’ or various other combinations of type-based visibility. Other 
> people (*cough* Slava) see no need for any levels finer than ‘internal’ at 
> all. The common points of agreement, though, are that ‘fileprivate’ is an 
> awkward spelling, and that the whole system is too complicated.
> 
> It is important that we as the Swift community are able to recognize our 
> mistakes, and even more important that we fix them. We originally thought 
> that the Swift 3 access control changes would be beneficial. However, 
> experience with them in practice has shown that not to be the case. Instead, 
> the language became more complex, and that has real costs. It is time for a 
> simplification.
> 
> The prevailing view from recent discussions is that there should be just one 
> access level more fine-grained than ‘internal’, and it should be spelled 
> ‘private’. Let us leave aside for the moment what its exact meaning should 
> be, and consider the other end of the scale.
> 
> Motivation – Rethinking ‘public’
> 
> Prior to Swift 3 we had just one access level more broad than ‘internal’, and 
> for simplicity of the model it would be desirable to achieve that again. 
> However, SE-0117 raised the point that certain library designs require a 
> class to have subclasses within the defining module, but not outside. In 
> other words, client code should not be able to create subclasses, even though 
> they exist in the library. Let us be clear: this is a niche use-case, but it 
> is important.
> 
> The most common situations are that a class either should not be subclassable 
> at all—in whic

Re: [swift-evolution] A Comprehensive Rethink of Access Levels in Swift

[Rien via swift-evolution]

Just joking of course (???)

Exposure levels: World, Module, File, Type (= [ W | M | F | T ])
Access control: Read, Write, Override, Inheritable (= [ R | W | O | I ])

let api = Access(w, [r, -w, -o, -i]) // Access must always be statically 
resolved
let mod = Access(m, [r, w, -o, i])
let cust = Access(api, mod, (f, [r, -w, o, i]), (t, [r, w, o, i]))

access(cust) var a: Int

Ok, joking besides…

I think the above suggestion is madness. Sure it would work and it is not even 
close to the worst possible solution.

In effect what I see people suggesting is exactly the above, only differently 
phrased:

fileprivate = access((w, [-r, -w, -o, -i]), (m, [-r, -w, -o, -i]), (f, [r, w, 
o, i]), (t, [r, w, o, i]) 
public private(set) = access((w, [r, -w, -o, -i]), (m, [r, -w, -o, -i]), (f, 
[r, -w, -o , i]), (t, [r, w, o, i])
open = …
final = ...

etc, you get the drift
What I am trying to show in this example is the complexity of trying to 
implement the full set of possible controls by introducing keywords (or keyword 
combinations!) for each possible combination.

I like simplicity. The TO suggestion would suit me just fine.

But there is a tip over point: when we get too many keywords then it becomes 
simpler to dump the keyword approach and go for the full Monty.

IMO in Swift 3 we are already dangerously close to the tip-over point.

Regards,
Rien

Site: http://balancingrock.nl
Blog: http://swiftrien.blogspot.com
Github: http://github.com/Balancingrock
Project: http://swiftfire.nl


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

Re: [swift-evolution] A Comprehensive Rethink of Access Levels in Swift

[Rien via swift-evolution]

Ah, the irony…

Having argued against too much complexity, I now encountered an error in my 
software that shows why there might indeed be a need for “open” and “public”.

In an API:

class Foo {
  open func foo(options: Option ...) {
foo(options)
  }
  open func foo(options: [Options]) { … }
}

An API user might do this:

class Bar: Foo {
  override func foo(options: Option ...) {
…
super.foo(options)
  }
}

var b = Bar()
b.foo(options: [Option.thisOne])

This compiles fine, and will even work  up to a point where the additions 
in Bar.foo are essential. Then it fails.
The user should have called:  b.foo(options: Option.thisOne)

This can easily be prevented by making Foo.foo(options: Option) public instead 
of open.
Then the user would not have been able to override the convenience method.
Furthermore: the user would not have experienced any inconvenience either as 
Foo.foo() would still be usable.

The interesting thing is that in this case there is no real argument on the 
side of the API developer to have a need for either open or public. It is 
entirely to the benefit of the API user. To me that makes a case for having 
both open and public. As an API developer I am willing to “go the extra mile” 
to create a good user experience, even if that means using tricks to achieve 
that end. However that would be impossible in this case. This end-user 
convenience is only achievable through open and public.

Regards,
Rien

Site: http://balancingrock.nl
Blog: http://swiftrien.blogspot.com
Github: http://github.com/Balancingrock
Project: http://swiftfire.nl



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

Re: [swift-evolution] [Draft] A Consistent Foundation For Access Control: Scope-Bounded Capabilities

[Rien via swift-evolution]

Just scanned it, but my first impression is: LOVE IT!

IMO this is the way to go.

Though some of the details will no doubt be improved. I will read it in more 
depth coming WE.

Regards,
Rien

Site: http://balancingrock.nl
Blog: http://swiftrien.blogspot.com
Github: http://github.com/Balancingrock
Project: http://swiftfire.nl





> On 02 Mar 2017, at 20:58, Matthew Johnson via swift-evolution 
>  wrote:
> 
> I’ve been continuing to think about how to provide clear and consistent 
> semantics for access control in Swift.  This draft represents what I think is 
> the best way to accomplish that.  It eliminates the current inconsistencies 
> and establishes a principled basis for the features we have today as well as 
> the enhancements we may need in the future.  It does this with minimal 
> breaking changes.
> 
> The draft is included below and can also be found here: 
> https://github.com/anandabits/swift-evolution/blob/scope-bounded-capabilities/proposals/-scope-bounded-capabilities.md.
> 
> I’m looking forward to everyone’s feedback.
> 
> Matthew
> 
> 
> A Consistent Foundation For Access Control: Scope-Bounded Capabilities
> 
>   • Proposal: SE-
>   • Authors: Matthew Johnson
>   • Review Manager: TBD
>   • Status: Awaiting review
> Introduction
> 
> This proposal introduces a consistent foundation for all access control in 
> Swift: scope-bounded capabilities. The existing access control features are 
> generalized with a single mechanism that unifies their semantics. This 
> unified mechanism eliminates the inessential complexity and inconsistency of 
> the current system while expanding its utility. 
> 
> Swift-evolution thread: Discussion thread topic for that proposal
> 
> Motivation
> 
> The new access control features in Swift 3 have proven to be extremely 
> controversial. The most common refrain is that we need a more simple system. 
> In order to accomplish this we need to do more than tweak the system we 
> already have. We need to revisit the foundation of the system itself.
> 
> Simple Made Easy
> 
> Rich Hickey gave a fantastic talk called [Simple Made 
> Easy])(https://www.infoq.com/presentations/Simple-Made-Easy). In this talk 
> Rich explores the etymology and relationship of the words "simple", 
> "complex", and "easy". The meanings he explores are:
> 
>   • Complex: entangled, intertwined, interleaved, braided together
>   • Simple: one strand, single focus, disentangled
>   • Easy: familiar, nearby, readily at hand
> The central point Rich makes in this talk is that when a design entangles two 
> orthogonal concepts complexity is the result. He coins the term "complect" to 
> refer to this kind of inessential complexity. This complexity can be removed 
> by disentangling the concepts. Instead of "complecting" independent concerns 
> we can compose them. 
> 
> The result is a simpler system. It is simpler because independent concepts 
> can be considered and understood independently of each other.
> 
> The composition of independent concerns also results in a more flexible 
> system. When orthogonal concepts are entangled it is more difficult to extend 
> the system to meet future needs. One concept cannot be extended independently 
> of the other. It is not possible to make independent decisions about what 
> should be orthogonal aspects of the design.
> 
> Rich believes that the programming community is often too quick to reach for 
> an immediately "easy" solution. Unfortunately, the "easy" solution often 
> entangles concepts and are therefor actually complex. He suggests that we 
> firstdesign a simple (i.e. disentangled) solution and then layer ease of use 
> and familiarity on top, thus the title "Simple Made Easy".
> 
> Two orthogonal concepts
> 
> The access control system in Swift 3 incorporates two orthogonal concepts: 
> availability and capability. Availability is what immediately comes to mind 
> when one thinks of access control: a symbol is either available or it is not. 
> Capability is more nuanced. It refers to what you can do with that symbol.
> 
> Each declaration supports a basic capability which is always available when 
> the symbol itself is available. Many declarations also offer additional 
> capabiities (such as the ability to inherit, override, set a property, etc). 
> These additional capabilities may be less available than the symbol itself.
> 
> In Swift, availability is always specified in terms of a scope. Swift does 
> not currently have a consistent way to talk about capabilities. Thus far we 
> have introduced new syntax every time we wish to distinguish the availabiltiy 
> of an additionalcapability from that of the symbol itself:
> 
>   • open vs public access modifiers classes and methods
>   • Access modifier parameterization for setter availability: private(set)
>   • The @closed attribute which has been discussed as a way to specify 
> non-resilient enums in Swift 4*
> It is clear that we need

Re: [swift-evolution] Yet Another Take on Swift Sub-modules

[Rien via swift-evolution]

I don’t like the file location based approach taken, see inline.

Rien.

> On 03 Mar 2017, at 16:24, Karim Nassar via swift-evolution 
>  wrote:
> 
> 
> I’ve read through the last couple of Swift (sub)Module proposals put forward, 
> and since my particular use-cases for a sub-module solution seemed to be 
> under-served by them, I’ve decided to write up my thoughts on the matter to 
> prompt discussion. 
> 
> Perhaps my use-cases are outliers, and my approach will be deemed naive by 
> the community… I’m happy to learn better ways of doing things in Swift, and 
> welcome any thoughts, criticism, or illumination related to these ideas.
> 
> I’m including the write-up below, but it’s also available as a gist: 
> https://gist.github.com/anonymous/9806f4274f1e13860670d6e059be5dce
> 
> —
> 
> # Sub-modules
> 
> A sub-module solution in Swift should have the following properties:
> 
> * Extremely light-weight
> * Low API surface area
> * Adopt progressive disclosure
> * Integrate with Access Control features to enable a level of encapsulation & 
> hiding between the Module and File level
> * Be permeable when desired
> 
> ## Discussion
> 
> As we get deeper into building real applications & frameworks with Swift, we 
> begin to realize that having a way to express relationships between types is 
> desireable.  Currently, Swift only allows us to express these relationships 
> at two levels, the Module and the File. 
> 
> The Module boundary is acceptable for small, focused frameworks, while the 
> File boundary is acceptable for small, focused Types, but both levels can be 
> unweildy when dealing with certain cases where a cluster of internally 
> related types needs to know about each other but may only want to publish a 
> narrow set of APIs to the surrounding code, or in large complex applications 
> which are necessarily structured as a single Module. In these cases, we wind 
> up with large monolithic Modules or (even worse) large monolithic Files.
> 
> I have seen this proliferation of Huge Sprawling Files (HSFs) in my own code, 
> and seek a way to combat this rising tide.
> 
> ## Goals 
> 
> It is a goal of this proposal to:
> 
> * Suggest a mechanism for organizing code between the Module and File levels 
> that is as lightweight and low-friction as possible
> * Provide mechanisms for authors to create both "hard" and "soft" API 
> boundaries between the Module and File levels of their code
> 
> ## Anti-Goals
> 
> It is not a goal of this proposal to:
> 
> * Move Swift away from filesystem-based organization
> * Significantly alter the current Access Control philosophy of Swift
> 
> ## Proposal Notes
> 
> Please take the following proposal wholely as a Straw-Man... I would be 
> equally satisfied with any solution which meets the critera described at the 
> top of this document.
> 
> Unless specified otherwise, all spellings proposed below are to be considered 
> straw-men, and merely illustrative of the concepts.
> 
> ## Proposed Solution
> 
> Two things are clear to me after using Swift and following the Swift 
> Evolution list since their respective publications:
> 
> 1. Swift has a preference for file-based organization
> 2. Vocal Swift Users dislike `fileprivate` and want to revert to Swift2-style 
> `private`
> 
> Because of #1, this proposal does not seek to change Swift's inherent 
> file-system organization, and instead will expand on it.
> 
> Since I personally fall into the camp described by #2, and most of the 
> community response to this has been "Lets wait to deal with that until 
> sub-modules", I'm making this proposal assuming that solving that quagmire is 
> in-scope for this propsoal.
> 
> ### Changes to Access Control Modifiers
> 
> As part of this proposal, I suggest the following changes to Swift 3's Access 
> Control modifiers:
> 
> * Revert `private` to Swift 2's meaning: "hidden outside the file"
> * Remove `fileprivate` as redundant
> 
> This is potentially a source-breaking change. However, it is interesting to 
> note that this change is **not** required for the following proposal to 
> function.
> 
> Changes that *are* necessary are:
> 
> * Change the spelling of `internal` to `module` (making `module` the new 
> default)
> * Introduce a new modifier `internal` to mean "Internal to the current 
> sub-module and its child-sub-modules"
> 
> These changes are *not* source-breaking because the new `internal` modifier 
> acts exactly as the old `internal` modifier unless it is used within a 
> sub-module. The specific spelling of this new `internal` modifier is 
> necessary to maintain backwards source compatibility.
> 
> The new `module` modifier allows authors to make APIs permeable between 
> sub-modules while still hidden outside the owning Module if desired.
> 
> All other Access Control modifiers behave the same as they currently do 
> irrespective of sub-module boundaries, so:
> 
> * `public` => Visible outside the Module
> * `open` => Sub-classable outside the Module
> 

Re: [swift-evolution] Yet Another Take on Swift Sub-modules

[Rien via swift-evolution]

> On 03 Mar 2017, at 18:54, Karim Nassar  wrote:
> 
> Thanks for your feedback. 
> 
> These are very fair concerns and point taken. There are other mechanisms we 
> could use to achieve similar ends, I’ll work on some additional ideas.
> 
> How do you view the overall goals/use cases?

I’m rather neutral on the need for modules/submodules. The points you mentioned 
don’t sound bad, but then again they are kind-a subjective.

Regards,
Rien.

> 
> —Karim
> 
>> On Mar 3, 2017, at 10:58 AM, Rien  wrote:
>> 
>> I don’t like the file location based approach taken, see inline.
>> 
>> Rien.
>> 
>>> On 03 Mar 2017, at 16:24, Karim Nassar via swift-evolution 
>>>  wrote:
>>> 
>>> 
>>> I’ve read through the last couple of Swift (sub)Module proposals put 
>>> forward, and since my particular use-cases for a sub-module solution seemed 
>>> to be under-served by them, I’ve decided to write up my thoughts on the 
>>> matter to prompt discussion. 
>>> 
>>> Perhaps my use-cases are outliers, and my approach will be deemed naive by 
>>> the community… I’m happy to learn better ways of doing things in Swift, and 
>>> welcome any thoughts, criticism, or illumination related to these ideas.
>>> 
>>> I’m including the write-up below, but it’s also available as a gist: 
>>> https://gist.github.com/anonymous/9806f4274f1e13860670d6e059be5dce
>>> 
>>> —
>>> 
>>> # Sub-modules
>>> 
>>> A sub-module solution in Swift should have the following properties:
>>> 
>>> * Extremely light-weight
>>> * Low API surface area
>>> * Adopt progressive disclosure
>>> * Integrate with Access Control features to enable a level of encapsulation 
>>> & hiding between the Module and File level
>>> * Be permeable when desired
>>> 
>>> ## Discussion
>>> 
>>> As we get deeper into building real applications & frameworks with Swift, 
>>> we begin to realize that having a way to express relationships between 
>>> types is desireable. Currently, Swift only allows us to express these 
>>> relationships at two levels, the Module and the File. 
>>> 
>>> The Module boundary is acceptable for small, focused frameworks, while the 
>>> File boundary is acceptable for small, focused Types, but both levels can 
>>> be unweildy when dealing with certain cases where a cluster of internally 
>>> related types needs to know about each other but may only want to publish a 
>>> narrow set of APIs to the surrounding code, or in large complex 
>>> applications which are necessarily structured as a single Module. In these 
>>> cases, we wind up with large monolithic Modules or (even worse) large 
>>> monolithic Files.
>>> 
>>> I have seen this proliferation of Huge Sprawling Files (HSFs) in my own 
>>> code, and seek a way to combat this rising tide.
>>> 
>>> ## Goals 
>>> 
>>> It is a goal of this proposal to:
>>> 
>>> * Suggest a mechanism for organizing code between the Module and File 
>>> levels that is as lightweight and low-friction as possible
>>> * Provide mechanisms for authors to create both "hard" and "soft" API 
>>> boundaries between the Module and File levels of their code
>>> 
>>> ## Anti-Goals
>>> 
>>> It is not a goal of this proposal to:
>>> 
>>> * Move Swift away from filesystem-based organization
>>> * Significantly alter the current Access Control philosophy of Swift
>>> 
>>> ## Proposal Notes
>>> 
>>> Please take the following proposal wholely as a Straw-Man... I would be 
>>> equally satisfied with any solution which meets the critera described at 
>>> the top of this document.
>>> 
>>> Unless specified otherwise, all spellings proposed below are to be 
>>> considered straw-men, and merely illustrative of the concepts.
>>> 
>>> ## Proposed Solution
>>> 
>>> Two things are clear to me after using Swift and following the Swift 
>>> Evolution list since their respective publications:
>>> 
>>> 1. Swift has a preference for file-based organization
>>> 2. Vocal Swift Users dislike `fileprivate` and want to revert to 
>>> Swift2-style `private`
>>> 
>>> Because of #1, this proposal does not seek to change Swift's inherent 
>>> file-system organization, and instead will expand on it.
>>> 
>>> Since I personally fall into the camp described by #2, and most of the 
>>> community response to this has been "Lets wait to deal with that until 
>>> sub-modules", I'm making this proposal assuming that solving that quagmire 
>>> is in-scope for this propsoal.
>>> 
>>> ### Changes to Access Control Modifiers
>>> 
>>> As part of this proposal, I suggest the following changes to Swift 3's 
>>> Access Control modifiers:
>>> 
>>> * Revert `private` to Swift 2's meaning: "hidden outside the file"
>>> * Remove `fileprivate` as redundant
>>> 
>>> This is potentially a source-breaking change. However, it is interesting to 
>>> note that this change is **not** required for the following proposal to 
>>> function.
>>> 
>>> Changes that *are* necessary are:
>>> 
>>> * Change the spelling of `internal` to `module` (making `module` the new 
>>> default)
>>> * Introduce a new modifie

Re: [swift-evolution] [Draft] A Consistent Foundation For Access Control: Scope-Bounded Capabilities

[Rien via swift-evolution]

> On 04 Mar 2017, at 16:01, Matthew Johnson via swift-evolution 
>  wrote:
> 
> I have updated this proposal with a few more refinements based on yesterday’s 
> discussion.  You can find the final proposal on Github:
> 
> https://github.com/anandabits/swift-evolution/blob/scope-bounded-capabilities/proposals/-scope-bounded-capabilities.md.
> 
> Matthew
> 
>> On Mar 2, 2017, at 1:58 PM, Matthew Johnson via swift-evolution 
>>  wrote:
>> 
>> ...
>> The rules which make up the essential complexity in Swift's access control 
>> system are:
>> 
>>  • The default scope for all capabilites a declaration offers is 
>> module-wide (or submodule-wide in the future).
>>  • The scope of a capability may be modified by an explicit access 
>> modifier.
>>  • The scope of an additional capability is implicitly bounded by the 
>> scope of the basic capability.
>>  • The scope of an additional capability may not be explicitly specified 
>> as greater than that of the basic capability.
>>  • If no scope is explicitly provided for the basic capability and an 
>> additional capability is specified to be available outside the (sub)module 
>> the basic capability is also given the same availability.
>>  • The scope of a declaration (including all capabilities) may be 
>> bounded by the declaration of ancestor.

Do you mean: IS bounded by?


>>  • The scope of a declaration may not be greater than the scope of the 
>> capabilities necessary to use that declaration: if you can't see a parameter 
>> type you can't call the function.
>> Most of these rules already exist in Swift's access control system. There is 
>> one change and one addition:

Overall I think the draft is pretty solid.
Imo this would give Swift the best available access control system I know of ;-)
Thanks for your work on this!

Regards,
Rien

Site: http://balancingrock.nl
Blog: http://swiftrien.blogspot.com
Github: http://github.com/Balancingrock
Project: http://swiftfire.nl





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

Re: [swift-evolution] Yet Another Take on Swift Sub-modules

[Rien via swift-evolution]

> On 05 Mar 2017, at 15:52, Karim Nassar via swift-evolution 
>  wrote:
> 
> 
>> On Mar 4, 2017, at 2:54 PM, Matthew Johnson  wrote:
>> 
>>> 
>>> On Mar 4, 2017, at 9:56 AM, Karim Nassar  wrote:
>>> 
>>> 
 On Mar 3, 2017, at 5:21 PM, Matthew Johnson  wrote:
 
> 
> On Mar 3, 2017, at 9:24 AM, Karim Nassar via swift-evolution 
>  wrote:
> 
> Changes that *are* necessary are:
> 
> * Change the spelling of `internal` to `module` (making `module` the new 
> default)
> * Introduce a new modifier `internal` to mean "Internal to the current 
> sub-module and its child-sub-modules”
 
 Can you give concrete examples of use cases where a descendent submodule 
 needs access to symbols declared by an ancestor?  I gave some thought to 
 this when drafting my proposal and came to the conclusion that this runs 
 against the grain of layering and is likely to be a bad idea in practice.  
 If there are use cases I didn’t consider I am very interested in learning 
 about them.
>>> 
>>> On further reflection and examination of my notes, I think you’re right, 
>>> and that the `internal` encapsulation should be purely horizontal. Will 
>>> adjust to reflect that.
>>> 
> ### Making a Sub-module
> 
> To create a sub-module within a Module (or sub-module) is simple: The 
> author creates a directory, and places a "sub-module declaration file" 
> within the directory:
> 
> ```
> //  __submodule.swift
 
 Why the double underscore prefix?  To make it sort to the top in a file 
 browser?
 
 Is this file allowed to have any Swift code?  Or is it limited to 
 submodule-related declarations only?  If the latter, why not use an 
 extension such as `.submodule` or `.swiftmodule` to differentiate it from 
 ordinary Swift files and allow the submodule to be named by the name of 
 this file?
>>> 
>>> So, my reasoning was that by requiring a specific standard name for the 
>>> declaration file, we guarantee that any directory can only describe one 
>>> submodule. Prefixing the proposed name with underscores was simply a way of 
>>> preventing naming collision with potential “real code” files (and yes, as a 
>>> side-effect alpha-floating it to the top). Since the `submodule` 
>>> declaration might expand to include statements & configuration about the 
>>> sub-module, I see no reason to prohibit Swift code from existing in that 
>>> sub-module declaration file… Disallowing/controlling that seems to be a 
>>> style/linter concern.
>>> 
>>> However, as I mentioned above, all the specific spellings (except 
>>> `internal`)  for the different concepts in this proposal are straw-men 
>>> awaiting input. I’d say the addition of a new type of file extension raises 
>>> some concerns for me, but there’s already been a lot of push back on the 
>>> general idea of using filesystem structures to organize sub-modules, so the 
>>> whole idea may be moot. 
>> 
>> I’ve actually been starting to come around to the idea of using the file 
>> system.  Not so much because I really like it, but because I have been 
>> considering further some of the drawbacks of other approaches.  
>> 
>> One big reason is that a submodule should form a scope and scopes should 
>> consist of code that is physically adjacent.  In practice this means it 
>> should reside in close proximity in the file system.  Allowing any file in a 
>> project to be a part of any submodule partly defeats the purpose of using 
>> them to structure a project internally.  If we’re going to be organizing the 
>> files in a submodule physically anyway maybe we should just take advantage 
>> of that fact and prevent a stray file in a distant part of the file system 
>> from being part of the submodule.
>> 
>> The second reason is that there is a big problem with placing a simple 
>> `submodule Foo` declaration at the top of each file in a submodule.  We all 
>> make typos from time to time.  This method makes it too easy to accidentally 
>> type `submodule Fooo` and end up in a submodule you didn’t intend.  This 
>> mistake would likely be caught relatively quickly but it seems silly to have 
>> a system subject to this kind of mistake.  This means we would end 
>> arbitrarily placing the declaration in one file and saying `extends 
>> submodule Foo` in the rest of the files.  Your design avoids the need to 
>> arbitrarily choose where to place the declaration and avoids the need for a 
>> declaration in the rest of the files.
> 
> I’m not dead-set on this approach, but as you say, it solves a *lot* of 
> problems that other approaches introduce. I do recognize the reasonableness 
> of the main argument against, that file location shouldn’t have such a 
> dramatic affect on behavior… *but* the fact is (whether by convention or 
> expediency) we already *do* have filesystem location dependencies on our code 
> projects… 
> 
> * One can’t willy-nilly move files 

Re: [swift-evolution] [Draft] Really Simple Submodules

[Rien via swift-evolution]

+1 for the simplicity. I like that.

However I dislike the non-hierachical approach: It should not be possible for 
an ‘outsider’ to declare itself part of a submodule if the original developer 
of that submodule did not want that. I understand that the submodules are not 
exported through the module (though wait for the requests to do so if this were 
ever implemented) but if large teams want to use submodules to structure their 
code base, some level of hierarchy is imo necessary.

Regards,
Rien

Site: http://balancingrock.nl
Blog: http://swiftrien.blogspot.com
Github: http://github.com/Balancingrock
Project: http://swiftfire.nl





> On 05 Mar 2017, at 23:16, Michel Fortin via swift-evolution 
>  wrote:
> 
> Sorry for introducing yet another submodule proposal out of the blue.
> 
> I'm a bit surprised at how far-reaching the various submodule proposals 
> floated on this list have been. Directories, access controls, @exported 
> imports... For comparison's sake here's one that is *really* simple and short 
> I wrote today. Best of all: it requires no new access modifier. 
> 
> I also expect everyone to scream at it because it does not include all the 
> desirable features of a submodule system. At the very least I'll have 
> redefined the meaning of lightweight in that discussion. Good reading.
> 
> Also available here: 
> https://gist.github.com/michelf/779b1bc26a778051b6231b5639665e18
> 
> 
> ## Motivation
> 
> The goal of this proposal is to provide lightweight intra-module boundaries 
> so you can avoid exposing every `internal` declaration within a big module to 
> all other files in the module.
> 
> Not a goal: addressing the file-level access fileprivate/private or 
> scoped/protected debates. This is left to other proposals.
> 
> 
> ## Summary
> 
> This proposal adds the declarations `submodule` and `import submodule`. It 
> also limits the visibility of `internal` to files with a matching `submodule` 
> or `import submodule` declaration.
> 
> Submodules are never exposed outside of the module. They only change the 
> visibility of internal declarations, so there is no point in exposing them 
> publicly.
> 
> Submodules are not bound to directories, nor are they necessarily 
> hierarchical.
> 
> This change is purely additive and introduces no source compatibility issue.
> 
> 
> ## Details
> 
> A `submodule ` declaration at the beginning of a file contains an 
> identifier with the submodule name:
> 
>   submodule Foo
> 
>   internal func foo() {}
>   public func pub() {}
> 
> `internal` declarations within that file are only visible to other files 
> sharing the same submodule name. The submodule only protects `internal` 
> declarations: `public` declarations in the file are visible everywhere (in 
> other submodules and in other modules).
> 
> A file can be part of more than one submodule:
> 
>   submodule Foo
>   submodule Bar
> 
>   internal func achoo() {
>   foo() // available in Foo (from other file)
>   }
> 
> This makes the internal `achoo` function visible within both the `Foo` and 
> `Bar` submodules. Also note that it makes internal members of both submodules 
> `Foo` and `Bar` visible within the file.
> 
> A file can access internal declarations of a submodule without having to 
> expose its own internal functions to the submodule with `import submodule`:
> 
>   submodule Test
>   import submodule Foo
> 
>   internal func test() {
>   foo() // internal, imported from Foo
>   achoo() // internal, imported from Foo
>   pub() // public, so always visible
>   }
> 
> Finally, when a file has no submodule declaration, its internal declarations 
> are visible everywhere in the module and all its submodules:
> 
>   --- Hello.swift ---
>   // no submodule declaration
>   internal func hello() {}
> 
>   --- World.swift ---
>   submodule World
>   internal func test() {
>   hello() // visible!
>   }
> 
> 
> ## Nitpicky Details (Conflicting Declarations)
> 
> Declaring `internal` things that share the same name in two separate 
> submodules is not a conflict:
> 
>   --- Foo1.swift ---
>   submodule Foo1
>   class Foo {} // added to Foo1
> 
>   --- Foo2.swift ---
>   submodule Foo2
>   submodule Foo3
>   class Foo {} // added to Foo2 and Foo3
> 
> (Note: It would be a conflict if one of them was `public`, because `public` 
> declarations are always visible everywhere inside (and outside of) the 
> module.)
> 
> Attempting to use both from another submodule will create ambiguity errors. 
> You can disambiguate using the submodule name as a prefix:
> 
>   --- Main.swift ---
>   import submodule Foo1
>   import submodule Foo2
>   import submodule Foo3
>   let f0 = Foo() // ambiguity error
>   let f1 = Foo1.Foo() // good
>   let f2 = Foo2.Foo() // good
>   let f3 = Foo3.Foo() // good
> 
> Best to avoid this fo

Re: [swift-evolution] Yet Another Take on Swift Sub-modules

[Rien via swift-evolution]

>>> 
>>> I’m not dead-set on this approach, but as you say, it solves a *lot* of 
>>> problems that other approaches introduce. I do recognize the reasonableness 
>>> of the main argument against, that file location shouldn’t have such a 
>>> dramatic affect on behavior… *but* the fact is (whether by convention or 
>>> expediency) we already *do* have filesystem location dependencies on our 
>>> code projects… 
>>> 
>>> * One can’t willy-nilly move files around the disk and expect a project to 
>>> build… if you move it somewhere the compiler doesn’t know to look for it, 
>>> you’re going to break things
>>> * One can’t just move a file out of your SCM repo root, or you’ll “lose” 
>>> the file
>> 
>> True, but if other files do not refer to the lost file, you don’t even know 
>> for which file to look.
>> (imo this is already a weak point in swift, but this approach to submodules 
>> would make it -much?- worse)
>> 
>> If you were to include filenames in the “submodule declaration file” at 
>> least this omission in swift would be partly covered, and you would not need 
>> to move the other files into special places. (You could though)
>> 
> 
> But isn’t this exactly the same case if you’re using Swift without an IDE? 
> It’s true that Xcode keeps track of files in your project, and there’s no 
> reason it couldn’t also keep track of files in a submodule (in fact it would… 
> it just might not know they belong in the sub-module without some work from 
> the Xcode dev team).
> 
> But as a thought-experiment, here’s how I’m thinking of this problem:
> 
> Swift (as a language) has established that a file *is* a unit of code. Not 
> the only one of course, but it is one, as evidenced by access controls 
> (fileprivate, Swift2 private) which bound on the file.

I disagree with this: Swift is just a set of -more or less- arbitrary rules to 
allow the development of applications.
The criteria for those rules are chosen by the core team and will fluctuate 
with time.
As such there is no “Swift way” of doing things. Any such remark is by its 
nature a personal preference. (not that there is anything wrong with that, its 
just not an argument)

(Besides, a computer only knows files, thus of course a file is a unit of code. 
That does not mean we should extend “code” to be something outside the files)

> I (and many others) want to be able to describe another unit of code larger 
> than a file and smaller than a Module to help organize the file-units we have 
> which go together within a Module, but which shouldn’t (for various reasons) 
> describe a complete Module in and of themselves.

Sure, and I have nothing against that. However I an dead set against extending 
the scope of the language itself to the organisation of its files. It is 
traditional to leave the organisation of the files to the configuration of the 
compiler/linker. And I do not see how it would simplify the language itself by 
extending the language to cover file organisation.

I will predict that if this approach is taken you should brace for the storm 
that would want to reverse this feature. It would imo dwarf the private vs 
fileprivate debate.

Besides, why create something new? (Yes there are systems out there that do 
some of this) There are many existing solutions out there that we could adopt 
and stay completely within the bounds of the language, and give the users 
something they are likely already familiar with.

> 
> For the moment—though we actually propose to call this unit a 
> sub-module—we'll call this new unit a Foo. Let's describe properties of a Foo:
> 
> * A Foo should serve to organize one or more File code units by:
>   - ensuring a File (the code-unit) may belong to one and only one Foo
>   - making clear (with or without an IDE) to which Foo a given file might 
> belong
> * A Foo should have a unique name
> * A Foo should be able to nest under another Foo, and the name of that 
> nesting should be clear & unique
> * A Foo should be able to be easily created, split, and merged as the 
> codebase evolves
> * A Foo should be able to be moved, copied, and SCMed as a unit, without 
> reference to anything outside the Foo
> 
> Having now described the critical properties of this new unit called “Foo” 
> have we not also described a filesystem directory?

Many things in life share characteristics. And while we should certainly look 
to them for lessons, we should not conclude that they are the same.

Rien.

> 
> Naturally, we don’t want *all* directories to become Foos (that would be 
> overly restrictive to authors, and backwards-incompatible), so we need a way 
> to distinguish a normal directory from one that is acting as a Foo. I 
> originally proposed a special “sub-module declaration file”, but there may be 
> other ways. For example, we might establish that a directory whose name 
> matches `[SubModuleName].swift-sub-module` becomes a sub-module of designated 
> name, however this can cause problems due to the disjoint se

[swift-evolution] Modules - an extremely simple approach

[Rien via swift-evolution]

I do not believe I have enough language inside to actually propose a solution. 
Still I would like to show what I think is the most simplest and flexible way 
to create modules.

Introduce the ‘module’ keyword to define a module.

module 


To create an empty lexical module named “MyModule”:

module MyModule


To create content for the module define types/functions/variables/protocols etc 
using the module name with a dot notation:

var MyModule.myVar: Int

Defines a variable at the module level that can be referred to by “myVar” 
inside the module, and by “MyModule.myVar” outside the module.
Same for functions, classes, protocols etc.


To create a submodule:

module MyModule.SubModule


To create a sub-sub module:

module SubModule.SubSubModule


If no module definition is present, the default module name is the name of the 
project.

Defining a module with the same name as the project is allowed, but does not 
create a new module, it simply refers to the default module.

Visibility (access) is created by:

import 


Access level (capability) must be defined by other means (preferably the 
mechanism proposed by Matthew)


Regards,
Rien

Site: http://balancingrock.nl
Blog: http://swiftrien.blogspot.com
Github: http://github.com/Balancingrock
Project: http://swiftfire.nl





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

Re: [swift-evolution] Yet Another Take on Swift Sub-modules

[Rien via swift-evolution]

> On 06 Mar 2017, at 15:10, Karim Nassar  wrote:
> 
>> 
>> On Mar 6, 2017, at 3:04 AM, Rien  wrote:
>> 
> 
> I’m not dead-set on this approach, but as you say, it solves a *lot* of 
> problems that other approaches introduce. I do recognize the 
> reasonableness of the main argument against, that file location shouldn’t 
> have such a dramatic affect on behavior… *but* the fact is (whether by 
> convention or expediency) we already *do* have filesystem location 
> dependencies on our code projects… 
> 
> * One can’t willy-nilly move files around the disk and expect a project 
> to build… if you move it somewhere the compiler doesn’t know to look for 
> it, you’re going to break things
> * One can’t just move a file out of your SCM repo root, or you’ll “lose” 
> the file
 
 True, but if other files do not refer to the lost file, you don’t even 
 know for which file to look.
 (imo this is already a weak point in swift, but this approach to 
 submodules would make it -much?- worse)
 
 If you were to include filenames in the “submodule declaration file” at 
 least this omission in swift would be partly covered, and you would not 
 need to move the other files into special places. (You could though)
 
>>> 
>>> But isn’t this exactly the same case if you’re using Swift without an IDE? 
>>> It’s true that Xcode keeps track of files in your project, and there’s no 
>>> reason it couldn’t also keep track of files in a submodule (in fact it 
>>> would… it just might not know they belong in the sub-module without some 
>>> work from the Xcode dev team).
>>> 
>>> But as a thought-experiment, here’s how I’m thinking of this problem:
>>> 
>>> Swift (as a language) has established that a file *is* a unit of code. Not 
>>> the only one of course, but it is one, as evidenced by access controls 
>>> (fileprivate, Swift2 private) which bound on the file.
>> 
>> I disagree with this: Swift is just a set of -more or less- arbitrary rules 
>> to allow the development of applications.
>> The criteria for those rules are chosen by the core team and will fluctuate 
>> with time.
>> As such there is no “Swift way” of doing things. Any such remark is by its 
>> nature a personal preference. (not that there is anything wrong with that, 
>> its just not an argument)
>> 
>> (Besides, a computer only knows files, thus of course a file is a unit of 
>> code. That does not mean we should extend “code” to be something outside the 
>> files)
> 
> First, that’s simply not true. In Swift 1, a file was *not* a logical unit of 
> code because file boundaries were meaningless to the way the code in the 
> project behaved. In Swift 2 we got `private` which made it possible for file 
> boundaries to affect code behavior. Swift 3 changed `private` but introduced 
> `fileprivate` for the same purpose.
> 
> Second, yes, Swift is just a language, but as that language evolves, it is an 
> expression of the values & preferences of its development team and more 
> recently, this community. If the file was not *intended* to be a unit of 
> code, we would not have `fileprivate`.

Take this not too personally, but this is a clear example of “cherrypicking”.

For example: Quite clearly swift currently defines modules as an end product of 
the compile/link process. So if we want multiple modules in a project, we can 
simply do it that way.

Yet you are clearly willing to throw this rule under the bus and replace it 
with something new. But if we should not adhere to the rule set in swift, then 
it is equally not possible to find justification in the current rules.

That is not to say that we should ignore the current rules, because it reduced 
the cognitive load of developers if new rules closely track exiting rules. But 
each change (proposal) should be examined against the current rules, and if it 
does not violate them, or if it does not introduce something that creates 
cognitive dissonance, then the proposal -at least- should not be rejected 
because of that.

I.e. when proposing a change, the current rule set -not directly affected by 
the change- can be used as a reason to reject the proposal, but never to accept 
it.


> 
> 
>>> I (and many others) want to be able to describe another unit of code larger 
>>> than a file and smaller than a Module to help organize the file-units we 
>>> have which go together within a Module, but which shouldn’t (for various 
>>> reasons) describe a complete Module in and of themselves.
>> 
>> Sure, and I have nothing against that. However I an dead set against 
>> extending the scope of the language itself to the organisation of its files. 
>> It is traditional to leave the organisation of the files to the 
>> configuration of the compiler/linker. And I do not see how it would simplify 
>> the language itself by extending the language to cover file organisation.
> 
> Clearly adding any new feature will not simplify the language

Re: [swift-evolution] [Review] SE-0158 Package Manager Manifest API Redesign

[Rien via swift-evolution]

> * What is your evaluation of the proposal?

I like the way this provides more harmonisation with Swift coding style.
Future extensibility seems to be well provided for.


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

If it were the only change, no. But anticipating on expected future 
enhancements, yes.


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

Yes


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

N.A. imo


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


Followed the discussion, quid read of proposal.


Regards,
Rien

Site: http://balancingrock.nl
Blog: http://swiftrien.blogspot.com
Github: http://github.com/Balancingrock
Project: http://swiftfire.nl





> On 07 Mar 2017, at 21:53, Rick Ballard via swift-evolution 
>  wrote:
> 
> Hello Swift community,
> 
> The review of "SE-0158 Package Manager Manifest API Redesign" begins now and 
> runs through March 13, 2017. The proposal is available here:
> 
>   
> https://github.com/apple/swift-evolution/blob/master/proposals/0158-package-manager-manifest-api-redesign.md
> 
> Reviews are an important part of the Swift evolution process. All Swift 
> Package Manager reviews should be sent to the swift-evolution and 
> swift-build-dev mailing lists at
> 
>   https://lists.swift.org/mailman/listinfo/swift-evolution
>   https://lists.swift.org/mailman/listinfo/swift-build-dev
> 
> 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/0158-package-manager-manifest-api-redesign.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 
> the Swift Package Manager?
> * Does this proposal fit well with the feel and direction of Swift?
> * If you have used other languages, libraries, or package managers 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,
> 
> - Rick Ballard
> 
> 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] Infer types of default function parameters

[Rien via swift-evolution]

0

Its not something I would use, but I don’t see why not.

Regards,
Rien

Site: http://balancingrock.nl
Blog: http://swiftrien.blogspot.com
Github: http://github.com/Balancingrock
Project: http://swiftfire.nl





> On 10 Mar 2017, at 22:40, Kilian Koeltzsch via swift-evolution 
>  wrote:
> 
> Hi all,
> 
> I sent the message below to swift-users@ ~a day ago, but this might be a 
> better place to ask and gather some discussion. It is a rather minor 
> suggestion and I'm just looking for some opinions.
> 
> Declaring a function that has default parameters currently looks like this:
> 
> func foo(bar: String = "baz") {
> print(bar)
> }
> 
> Now I'm wondering if there would be any problems if it were possible to omit 
> the type annotation for default params and let Swift's type inference handle 
> that. 
> 
> func foo(bar = "baz") {
> print(bar)
> }
> 
> It feels to be equivalent to omitting type annotations with variable 
> declarations. Obviously more complex types would still require annotations 
> being specified. Off the top of my head I can't think of any negative 
> ramifications this might bring, be it in simple function/method declarations 
> or protocol extensions and elsewhere. 
> Any further input or examples for situations where this might cause issues 
> would be much appreciated :)
> 
> Cheers,
> Kilian
> ___
> 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] SPM - Set 'Defines module' to 'yes' by default

[Rien via swift-evolution]

When generating an xcode project with the SPM, the “Defines module” option is 
not set.

Would it be possible to always set this option to ‘yes’ by default in the next 
release?

This would make it easier to create modulair frameworks for inclusion in 
(other) Xcode projects.

Regards,
Rien

Site: http://balancingrock.nl
Blog: http://swiftrien.blogspot.com
Github: http://github.com/Balancingrock
Project: http://swiftfire.nl





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

[swift-evolution] Code blocks and trailing closures

[Rien via swift-evolution]

What does the following code fragment do?

serverCert.write(to: certificateUrl) { showErrorInKeyWindow(message); return }

The only possible answer is: I don’t know.

The problem is finding out what the “return” statement will do.

Without knowing if the {...} is a code block or a trailing closure it is 
impossible to know what the return statement will do. It will either end the 
closure or it will end the function that contains this code block.

This could be disambiguated by using the same syntax as for lazy variables:

serverCert.write(to: serverCertificateUrl) { showErrorInKeyWindow(message: 
message); return }()

Now it is clear that the return statement will only terminate the (trailing) 
closure.

A question to the educators on the list: Is this a real problem?

Personally, I dislike this situation, but I am also ambivalent towards the 
solution I just described.

Regards,
Rien

Site: http://balancingrock.nl
Blog: http://swiftrien.blogspot.com
Github: http://github.com/Balancingrock
Project: http://swiftfire.nl





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

Re: [swift-evolution] Code blocks and trailing closures

[Rien via swift-evolution]

If I wrote this:

if serverCert.write(to: certificateUrl) { showErrorInKeyWindow(message); return 
}

then the meaning of return would have been different.

Imo it is a problem that two pieces of code impact the understanding of each 
other and that those two pieces of code could potentially be very far apart.

I do agree that the parenthesis are not a perfect solution, it was just the 
first thing that I could think of and that has some level of similarity in 
meaning.

Regards,
Rien

Site: http://balancingrock.nl
Blog: http://swiftrien.blogspot.com
Github: http://github.com/Balancingrock
Project: http://swiftfire.nl





> On 15 Mar 2017, at 12:00, Adrian Zubarev  
> wrote:
> 
> I’m slightly confused by this. How is a trailing closure different from a 
> code block in Swift? It’s basically the same thing with some extra syntax 
> sugar because it happens to be the last parameter of your function.
> 
> You can simply write this if you wanted to:
> 
> myFucntion(someLabel: abc, closureLabel: { …; return })
> 
> Parentheses are indicating that your closure is immediately invoked.
> 
> let someInt = { return 42 }()  
> print(someInt)
> 
> let someClosureWhichReturnsAnInt = { return 42 } // You can reuse the closure
> print(someClosureWhichReturnsAnInt()) // Invocation happens now here
> 
> return is scope based and it’s totally clear (to me) that in your case return 
> will return from your closure with a value of Void.
> 
> 
> 
> 
> -- 
> Adrian Zubarev
> Sent with Airmail
> 
> Am 15. März 2017 um 11:35:39, Rien via swift-evolution 
> (swift-evolution@swift.org) schrieb:
> 
>> What does the following code fragment do?
>> 
>> serverCert.write(to: certificateUrl) { showErrorInKeyWindow(message); return 
>> }
>> 
>> The only possible answer is: I don’t know.
>> 
>> The problem is finding out what the “return” statement will do.
>> 
>> Without knowing if the {...} is a code block or a trailing closure it is 
>> impossible to know what the return statement will do. It will either end the 
>> closure or it will end the function that contains this code block.
>> 
>> This could be disambiguated by using the same syntax as for lazy variables:
>> 
>> serverCert.write(to: serverCertificateUrl) { showErrorInKeyWindow(message: 
>> message); return }()
>> 
>> Now it is clear that the return statement will only terminate the (trailing) 
>> closure.
>> 
>> A question to the educators on the list: Is this a real problem?
>> 
>> Personally, I dislike this situation, but I am also ambivalent towards the 
>> solution I just described.
>> 
>> Regards,
>> Rien
>> 
>> Site: http://balancingrock.nl
>> Blog: http://swiftrien.blogspot.com
>> Github: http://github.com/Balancingrock
>> Project: http://swiftfire.nl
>> 
>> 
>> 
>> 
>> 
>> ___
>> 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] Code blocks and trailing closures

[Rien via swift-evolution]

Sorry, it seems we are talking past each other, let me try again:

I left the “if” out on purpose. To show that even though the snippet was 
“valid” code, it was in fact ambiguous.

With closures (and autoclosures) it becomes possible -to some extent- to 
“enhance” the language.

Consider:

guard let c = somefunc() else { showError(); return }
myguard( let c = somefunc()) { showError(); return }

In this simple example it is clear that the second return behaves quite 
differently from the first.
It gets more difficult if the code in the block cq closure gets very large.
Also, I would expect that beginners would have problems understanding this 
(subtile but important) difference.

Regards,
Rien

Site: http://balancingrock.nl
Blog: http://swiftrien.blogspot.com
Github: http://github.com/Balancingrock
Project: http://swiftfire.nl





> On 15 Mar 2017, at 12:19, Adrian Zubarev  
> wrote:
> 
> There is no if … on my screen nor there is one here 
> https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon–20170313/033888.html.
>  May be a typo?
> 
> In that case it cannot be a trailing closure because trailing closures are 
> banned in such scenarios. 
> https://github.com/apple/swift-evolution/blob/master/proposals/0056-trailing-closures-in-guard.md
> 
> As for the lazy variables you’ve mentioned in the original posts, the closure 
> there is invoked lately but only once and it cannot be reused at all.
> 
> Let me know if I understood your gist now.
> 
> if someFunction { …; return } // someFunction cannot have a trailing closure 
> here!
> 
> 
> 
> 
> -- 
> Adrian Zubarev
> Sent with Airmail
> 
> Am 15. März 2017 um 12:08:19, Rien (r...@balancingrock.nl) schrieb:
> 
>> If I wrote this: 
>> 
>> if serverCert.write(to: certificateUrl) { showErrorInKeyWindow(message); 
>> return } 
>> 
>> then the meaning of return would have been different. 
>> 
>> Imo it is a problem that two pieces of code impact the understanding of each 
>> other and that those two pieces of code could potentially be very far apart. 
>> 
>> I do agree that the parenthesis are not a perfect solution, it was just the 
>> first thing that I could think of and that has some level of similarity in 
>> meaning. 
>> 
>> Regards, 
>> Rien 
>> 
>> Site: http://balancingrock.nl 
>> Blog: http://swiftrien.blogspot.com 
>> Github: http://github.com/Balancingrock 
>> Project: http://swiftfire.nl 
>> 
>> 
>> 
>> 
>> 
>> > On 15 Mar 2017, at 12:00, Adrian Zubarev  
>> > wrote: 
>> >  
>> > I’m slightly confused by this. How is a trailing closure different from a 
>> > code block in Swift? It’s basically the same thing with some extra syntax 
>> > sugar because it happens to be the last parameter of your function. 
>> >  
>> > You can simply write this if you wanted to: 
>> >  
>> > myFucntion(someLabel: abc, closureLabel: { …; return }) 
>> >  
>> > Parentheses are indicating that your closure is immediately invoked. 
>> >  
>> > let someInt = { return 42 }()  
>> > print(someInt) 
>> >  
>> > let someClosureWhichReturnsAnInt = { return 42 } // You can reuse the 
>> > closure 
>> > print(someClosureWhichReturnsAnInt()) // Invocation happens now here 
>> >  
>> > return is scope based and it’s totally clear (to me) that in your case 
>> > return will return from your closure with a value of Void. 
>> >  
>> >  
>> >  
>> >  
>> > --  
>> > Adrian Zubarev 
>> > Sent with Airmail 
>> >  
>> > Am 15. März 2017 um 11:35:39, Rien via swift-evolution 
>> > (swift-evolution@swift.org) schrieb: 
>> >  
>> >> What does the following code fragment do? 
>> >>  
>> >> serverCert.write(to: certificateUrl) { showErrorInKeyWindow(message); 
>> >> return } 
>> >>  
>> >> The only possible answer is: I don’t know. 
>> >>  
>> >> The problem is finding out what the “return” statement will do. 
>> >>  
>> >> Without knowing if the {...} is a code block or a trailing closure it is 
>> >> impossible to know what the return statement will do. It will either end 
>> >> the closure or it will end the function that contains this code block. 
>> >>  
>> >> This could be disambiguated by using the same syntax as for lazy 
>> >> variables: 
>> >>  
>> >> serverCert.write(to: serverCertificateUrl) { 
>> >> showErrorInKeyWindow(message: mess

Re: [swift-evolution] Code blocks and trailing closures

[Rien via swift-evolution]

> On 15 Mar 2017, at 13:04, Jaden Geller  wrote:
> 
> It seems like your complaint is that control-flow statements, specifically 
> `return`, act different inside closures than inside other braced statements.

Yes.
break and continue also come to mind.

For example if you have some nested loops and you see a “break” statement, you 
must inspect the code between the loop start and the “break" to check if the 
break is inside a closure or not.


> I too dislike this inconsistency, but I don’t think that the syntactic change 
> you suggested makes it much more clear.

Agree.

As is probably clear from Adrian’s reaction, I am not sure if this really is a 
problem.
I don’t like it, but the current situation is workable even though it might be 
confusing to newbies.

> I’d rather find a solution that’d allow trailing closure functions (like 
> `forEach`) to support keywords like `return`, though I imagine this would 
> require some sort of macro system.
> 
> Cheers,
> Jaden Geller
> 
>> On Mar 15, 2017, at 4:56 AM, Rien via swift-evolution 
>>  wrote:
>> 
>> Sorry, it seems we are talking past each other, let me try again:
>> 
>> I left the “if” out on purpose. To show that even though the snippet was 
>> “valid” code, it was in fact ambiguous.
>> 
>> With closures (and autoclosures) it becomes possible -to some extent- to 
>> “enhance” the language.
>> 
>> Consider:
>> 
>> guard let c = somefunc() else { showError(); return }
>> myguard( let c = somefunc()) { showError(); return }
>> 
>> In this simple example it is clear that the second return behaves quite 
>> differently from the first.
>> It gets more difficult if the code in the block cq closure gets very large.
>> Also, I would expect that beginners would have problems understanding this 
>> (subtile but important) difference.
>> 
>> Regards,
>> Rien
>> 
>> Site: http://balancingrock.nl
>> Blog: http://swiftrien.blogspot.com
>> Github: http://github.com/Balancingrock
>> Project: http://swiftfire.nl
>> 
>> 
>> 
>> 
>> 
>>> On 15 Mar 2017, at 12:19, Adrian Zubarev  
>>> wrote:
>>> 
>>> There is no if … on my screen nor there is one here 
>>> https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon–20170313/033888.html.
>>>  May be a typo?
>>> 
>>> In that case it cannot be a trailing closure because trailing closures are 
>>> banned in such scenarios. 
>>> https://github.com/apple/swift-evolution/blob/master/proposals/0056-trailing-closures-in-guard.md
>>> 
>>> As for the lazy variables you’ve mentioned in the original posts, the 
>>> closure there is invoked lately but only once and it cannot be reused at 
>>> all.
>>> 
>>> Let me know if I understood your gist now.
>>> 
>>> if someFunction { …; return } // someFunction cannot have a trailing 
>>> closure here!
>>> 
>>> 
>>> 
>>> 
>>> -- 
>>> Adrian Zubarev
>>> Sent with Airmail
>>> 
>>> Am 15. März 2017 um 12:08:19, Rien (r...@balancingrock.nl) schrieb:
>>> 
>>>> If I wrote this: 
>>>> 
>>>> if serverCert.write(to: certificateUrl) { showErrorInKeyWindow(message); 
>>>> return } 
>>>> 
>>>> then the meaning of return would have been different. 
>>>> 
>>>> Imo it is a problem that two pieces of code impact the understanding of 
>>>> each other and that those two pieces of code could potentially be very far 
>>>> apart. 
>>>> 
>>>> I do agree that the parenthesis are not a perfect solution, it was just 
>>>> the first thing that I could think of and that has some level of 
>>>> similarity in meaning. 
>>>> 
>>>> Regards, 
>>>> Rien 
>>>> 
>>>> Site: http://balancingrock.nl 
>>>> Blog: http://swiftrien.blogspot.com 
>>>> Github: http://github.com/Balancingrock 
>>>> Project: http://swiftfire.nl 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>>> On 15 Mar 2017, at 12:00, Adrian Zubarev 
>>>>>  wrote: 
>>>>> 
>>>>> I’m slightly confused by this. How is a trailing closure different from a 
>>>>> code block in Swift? It’s basically the same thing with some extra syntax 
>>>>> sugar because it happens to be the last parameter of your function. 
>>>>> 
>>>>> You can simply write this if 

Re: [swift-evolution] Code blocks and trailing closures

[Rien via swift-evolution]

a trailing closure different from 
>> >> > a code block in Swift? It’s basically the same thing with some extra 
>> >> > syntax sugar because it happens to be the last parameter of your 
>> >> > function.  
>> >> >  
>> >> > You can simply write this if you wanted to:  
>> >> >  
>> >> > myFucntion(someLabel: abc, closureLabel: { …; return })  
>> >> >  
>> >> > Parentheses are indicating that your closure is immediately invoked.  
>> >> >  
>> >> > let someInt = { return 42 }()  
>> >> > print(someInt)  
>> >> >  
>> >> > let someClosureWhichReturnsAnInt = { return 42 } // You can reuse the 
>> >> > closure  
>> >> > print(someClosureWhichReturnsAnInt()) // Invocation happens now here  
>> >> >  
>> >> > return is scope based and it’s totally clear (to me) that in your case 
>> >> > return will return from your closure with a value of Void.  
>> >> >  
>> >> >  
>> >> >  
>> >> >  
>> >> > --  
>> >> > Adrian Zubarev  
>> >> > Sent with Airmail  
>> >> >  
>> >> > Am 15. März 2017 um 11:35:39, Rien via swift-evolution 
>> >> > (swift-evolution@swift.org) schrieb:  
>> >> >  
>> >> >> What does the following code fragment do?  
>> >> >>  
>> >> >> serverCert.write(to: certificateUrl) { showErrorInKeyWindow(message); 
>> >> >> return }  
>> >> >>  
>> >> >> The only possible answer is: I don’t know.  
>> >> >>  
>> >> >> The problem is finding out what the “return” statement will do.  
>> >> >>  
>> >> >> Without knowing if the {...} is a code block or a trailing closure it 
>> >> >> is impossible to know what the return statement will do. It will 
>> >> >> either end the closure or it will end the function that contains this 
>> >> >> code block.  
>> >> >>  
>> >> >> This could be disambiguated by using the same syntax as for lazy 
>> >> >> variables:  
>> >> >>  
>> >> >> serverCert.write(to: serverCertificateUrl) { 
>> >> >> showErrorInKeyWindow(message: message); return }()  
>> >> >>  
>> >> >> Now it is clear that the return statement will only terminate the 
>> >> >> (trailing) closure.  
>> >> >>  
>> >> >> A question to the educators on the list: Is this a real problem?  
>> >> >>  
>> >> >> Personally, I dislike this situation, but I am also ambivalent towards 
>> >> >> the solution I just described.  
>> >> >>  
>> >> >> Regards,  
>> >> >> Rien  
>> >> >>  
>> >> >> Site: http://balancingrock.nl  
>> >> >> Blog: http://swiftrien.blogspot.com  
>> >> >> Github: http://github.com/Balancingrock  
>> >> >> Project: http://swiftfire.nl  
>> >> >>  
>> >> >>  
>> >> >>  
>> >> >>  
>> >> >>  
>> >> >> ___  
>> >> >> 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] Code blocks and trailing closures

[Rien via swift-evolution]

> On 15 Mar 2017, at 13:33, Nick Keets  wrote:
> 
> I think the word you are looking for is “confusing”, not “ambiguous”. Nothing 
> is ambiguous
> about the code you wrote, but you could make an argument that you find it 
> confusing (since this is something subjective).
> 

Agreed.

Rien.

> On Wed, Mar 15, 2017 at 12:35 PM, Rien via swift-evolution 
>  wrote:
> What does the following code fragment do?
> 
> serverCert.write(to: certificateUrl) { showErrorInKeyWindow(message); return }
> 
> The only possible answer is: I don’t know.
> 
> The problem is finding out what the “return” statement will do.
> 
> Without knowing if the {...} is a code block or a trailing closure it is 
> impossible to know what the return statement will do. It will either end the 
> closure or it will end the function that contains this code block.
> 
> This could be disambiguated by using the same syntax as for lazy variables:
> 
> serverCert.write(to: serverCertificateUrl) { showErrorInKeyWindow(message: 
> message); return }()
> 
> Now it is clear that the return statement will only terminate the (trailing) 
> closure.
> 
> A question to the educators on the list: Is this a real problem?
> 
> Personally, I dislike this situation, but I am also ambivalent towards the 
> solution I just described.
> 
> Regards,
> Rien
> 
> Site: http://balancingrock.nl
> Blog: http://swiftrien.blogspot.com
> Github: http://github.com/Balancingrock
> Project: http://swiftfire.nl
> 
> 
> 
> 
> 
> ___
> 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] Smart KeyPaths

[Rien via swift-evolution]

> 
> On 20 Mar 2017, at 12:12, David Hart via swift-evolution 
>  wrote:
> 
> 
> 
>> On 20 Mar 2017, at 10:39, Jonathan Hull via swift-evolution 
>>  wrote:
>> 
>> +1.  This is my favorite solution so far. 
>> 
>> With ‘Person.keypath.name' it is obvious that we are creating a key path.  
>> There is no ambiguity for the reader.  With autocomplete it will be very 
>> little extra typing anyway…
> 
> But that adds a lot of verbosity. They disregarded #keyPath because it was 
> too verbose.
> 

Then let me add a +1 for the verbose solution as well.

Sometimes verbosity is not bad.

Regards,
Rien

Site: http://balancingrock.nl
Blog: http://swiftrien.blogspot.com
Github: http://github.com/Balancingrock
Project: http://swiftfire.nl

>> Thanks,
>> Jon
>> 
>>> On Mar 19, 2017, at 9:20 PM, Dietmar Planitzer via swift-evolution 
>>>  wrote:
>>> 
>>> Key paths of this form:
>>> 
>>> Person.name
>>> 
>>> will always make it harder than necessary to:
>>> 
>>> * search for all places where we are using key paths
>>> 
>>> * do efficient code completion. Eg you’ll get a mix of static properties 
>>> and key paths
>>> 
>>> 
>>> We’ve been using this kind of setup in our projects for some time now:
>>> 
>>> class Person {
>>> 
>>> struct keypath {
>>> 
>>>static let name = #keyPath(Person.name)
>>>…
>>> }
>>> 
>>> …
>>> }
>>> 
>>> where a keypath is then used like this:
>>> 
>>> Person.keypath.name
>>> 
>>> and this has worked very well. It makes it easy to see where we are using a 
>>> keypath rather than accessing some static property, it works very nicely 
>>> with code completion and it makes it very easy to search for all places 
>>> where we are using key paths from the Person type.
>>> 
>>> I would prefer that the proposed keypath model would automatically organize 
>>> key paths like this.
>>> 
>>> 
>>> Regards,
>>> 
>>> Dietmar Planitzer
>>> 
>>> 
 On Mar 19, 2017, at 20:49, Matthew Johnson via swift-evolution 
  wrote:
 
 
 
 Sent from my iPad
 
> On Mar 19, 2017, at 10:31 PM, Jaden Geller via swift-evolution 
>  wrote:
> 
> I think the clarity desired is more similar to that obtained by the `try` 
> keyword. Ya, the compiler knows that this function throws already, but 
> Swift aims for clarity in the source code. Clarity is often achieved by 
> providing potentially redundant information for the programmer.
> 
> As proposed, it is difficult to distinguish a key path from a static 
> variable. Maybe that's not problematic? Well, it's up to the community to 
> decide.
 
 Why don't we just say all instance properties are shadowed by a static 
 constant property of the same name with the appropriate key path type.  
 This makes it not mysterious at all but instead very straightforward.  We 
 could even say that static and class properties are shadowed by a key path 
 property on the meta type.
 
 
> I do think it is a bit worrisome that static variable access might cause 
> side effects (or at least, might take a while to compute) but creating 
> key paths should not, but that's a fringe case probably.
> 
> On Mar 19, 2017, at 6:32 PM, Brent Royal-Gordon via swift-evolution 
>  wrote:
> 
>>> On Mar 19, 2017, at 4:47 PM, Charles Srstka  
>>> wrote:
>>> 
 This is true of many things.  It is why IDEs make type information 
 readily available.
>>> 
>>> Is clarity not a thing to be desired?
>> 
>> Clarity is in the eye of the beholder. Here's one notion of clarity:
>> 
>>   sum :: (Num a, Foldable t) => t a -> a
>>   sum = foldl (+) 0
>> 
>> Here's another:
>> 
>>   int sum(int array[], size_t len) {
>>   int total = 0;
>>   for(size_t i = 0; i < len; i++) {
>>   total += array[i];
>>   }
>>   return total;
>>   }
>> 
>> And another:
>> 
>>   SUM PROC
>>; this procedure will calculate the sum of an array
>>; input : SI=offset address of the array
>>;   : BX=size of the array
>>; output : AX=sum of the array
>> 
>>PUSH CX; push CX onto the STACK
>>PUSH DX; push DX onto the STACK
>> 
>>XOR AX, AX ; clear AX
>>XOR DX, DX ; clear DX
>>MOV CX, BX ; set CX=BX
>> 
>>@SUM:  ; loop label
>>  MOV DL, [SI] ; set DL=[SI]
>>  ADD AX, DX   ; set AX=AX+DX
>>  INC SI   ; set SI=SI+1
>>LOOP @SUM  ; jump to label @SUM while CX!=0
>> 
>>POP DX ; pop a value from STACK into DX
>>POP CX ; pop a value from STACK into CX
>> 
>>RET; return c

Re: [swift-evolution] Code blocks and trailing closures

[Rien via swift-evolution]

Another solution to the original problem would be to allow the parameter name 
of the closure outside the functions parenthesis:

func test(a: Int, onError: ()->Void) {…}

could be called like this:

test(5) onError: { myErrorHandler() }

Myself, I would like this. It makes clear what the closure is used for, and it 
potentially opens up the possibility to use multiple “parameter named closures” 
after the function call.

It also makes it clear that this is a closure and not a code block belonging to 
a statement.

I guess this must have been debated already… if so, why was it rejected?

Regards,
Rien

Site: http://balancingrock.nl
Blog: http://swiftrien.blogspot.com
Github: http://github.com/Balancingrock
Project: http://swiftfire.nl





> On 20 Mar 2017, at 13:13, David Rönnqvist via swift-evolution 
>  wrote:
> 
> Xcode can already draw boxes for nesting scopes, but it’s disabled by 
> default. You’ll find it under: Editor > Code Folding > Focus Follows 
> Selection.
> 
> That said, IIRC it’s been mentioned on this list that (I’m paraphrasing) we 
> should try and avoid designs that rely on editor functionality, and also that 
> a Xcode is independent from the mailing list.
> 
> 
>> On 20 Mar 2017, at 07:22, Rick Mann via swift-evolution 
>>  wrote:
>> 
>> I actually don't like this situation, either. I find it gets a bit confusing 
>> to know what's a block and what's just nested scope. I, too, have had an 
>> impulse to have a different keyword for returning from a block, but what I 
>> really want is for the entire scope of the block to be called out 
>> differently.
>> 
>> This is true regardless of whether or not it's a trailing closure.
>> 
>> I wonder if the source editor (e.g. Xcode) could draw three sides of a box 
>> with arrows:
>> 
>>   { <+
>>   some code  |
>>   more code  |
>>   } <+
>> 
>> I don't know if this would quickly get messy and distracting. It would be 
>> challenging to find exactly the right way to draw it that pleases everyone 
>> (it should, obviously, be hyper-customizable, but Apple hates settings), and 
>> to draw it to make it easy to see what it's pointing to without trampling 
>> over end-of-line comments.
>> 
>> Maybe subtle highlighting of the background (all the way across the window) 
>> to show block, but that makes it harder to show nested blocks.
>> 
>> 
>>> On Mar 19, 2017, at 20:33 , Kenny Leung via swift-evolution 
>>>  wrote:
>>> 
>>> I have proposed that a different keyword be used to return out of blocks. 
>>> In Objective-C, I have a #define that aliases “blockreturn” and I use that 
>>> exclusively in breaking out of blocks.
>>> 
>>> -Kenny
>>> 
>>> 
>>>> On Mar 15, 2017, at 3:35 AM, Rien via swift-evolution 
>>>>  wrote:
>>>> 
>>>> What does the following code fragment do?
>>>> 
>>>> serverCert.write(to: certificateUrl) { showErrorInKeyWindow(message); 
>>>> return }
>>>> 
>>>> The only possible answer is: I don’t know.
>>>> 
>>>> The problem is finding out what the “return” statement will do.
>>>> 
>>>> Without knowing if the {...} is a code block or a trailing closure it is 
>>>> impossible to know what the return statement will do. It will either end 
>>>> the closure or it will end the function that contains this code block.
>>>> 
>>>> This could be disambiguated by using the same syntax as for lazy variables:
>>>> 
>>>> serverCert.write(to: serverCertificateUrl) { showErrorInKeyWindow(message: 
>>>> message); return }()
>>>> 
>>>> Now it is clear that the return statement will only terminate the 
>>>> (trailing) closure.
>>>> 
>>>> A question to the educators on the list: Is this a real problem?
>>>> 
>>>> Personally, I dislike this situation, but I am also ambivalent towards the 
>>>> solution I just described.
>>>> 
>>>> Regards,
>>>> Rien
>>>> 
>>>> Site: http://balancingrock.nl
>>>> Blog: http://swiftrien.blogspot.com
>>>> Github: http://github.com/Balancingrock
>>>> Project: http://swiftfire.nl
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 

Re: [swift-evolution] Code blocks and trailing closures

[Rien via swift-evolution]

> On 20 Mar 2017, at 15:42, Haravikk  wrote:
> 
> 
>> On 20 Mar 2017, at 14:24, Rien via swift-evolution 
>>  wrote:
>> 
>> Another solution to the original problem would be to allow the parameter 
>> name of the closure outside the functions parenthesis:
>> 
>> func test(a: Int, onError: ()->Void) {…}
>> 
>> could be called like this:
>> 
>> test(5) onError: { myErrorHandler() }
> 
> When you get onto that kind of syntax the obvious question is, what's wrong 
> with:
> 
>   test(5, onError: { myErrorHandler() })
> 
> To me there's no real difference, in fact all that's changed now is that a 
> round bracket is at the end; while being within the parenthesis is a little 
> noisier, it's also clearer what's going on. Consider, if the body of the 
> closure were very long:
> 
>   test(5, onError: {
>   // Lots
>   // and
>   // lots
>   // of
>   // code
>   })
> 
> Here the closing round bracket reminds me that this is the end of a closure 
> being passed to a function, rather than some other code block and, if 
> properly indented, it should be easy to jump to whatever that function is.
> 
> It could just be my personal preference; I'm generally uncomfortable with the 
> use of trailing closures except for language-like constructs such as 
> .forEach, and I've never had any problem using closures within the function's 
> parenthesis, but it just seems like there's a point at which we're bolting so 
> much onto trailing closures, that you really do have to ask what's so wrong 
> with just passing the closure normally?

The only (slight) advantage is that using trailing closures you can be sure 
that you have seen all parameters that are necessary inside the function.

Compare:

test(5, onError: {
   // Lots
   // and
   // lots
   // of
   // code
}, 1)

test(5, 1) onError: {
   // Lots
   // and
   // lots
   // of
   // code
}

But I agree, the difference is probably not worth it.

I will start using the inline notation, and see how that works out.

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

Re: [swift-evolution] [Proposal] Factory Initializers

[Rien via swift-evolution]

I just have to ask: why should a factory method be part of the language?

I have nothing against it, I am just wondering if I am missing something.
The way I see it everyone can add a factory initializer if he/she needs it. Why 
make it part of the language?

Regards,
Rien

Site: http://balancingrock.nl
Blog: http://swiftrien.blogspot.com
Github: http://github.com/Balancingrock
Project: http://swiftfire.nl





> On 20 Mar 2017, at 21:40, Jonathan Hull via swift-evolution 
>  wrote:
> 
> Huge +1
> 
> 
>> On Mar 17, 2017, at 9:26 AM, Riley Testut via swift-evolution 
>>  wrote:
>> 
>> Hi again everyone!
>> 
>> Now that Swift 4 Stage 2 proposals are being considered, I thought it might 
>> be time to revisit this proposal and see if it might align with the goals 
>> set forth for Swift 4.
>> 
>> As a quick tl;dr, this proposal describes a new "factory initializer" that 
>> would allow you to return a value from an initializer. This would have 
>> several benefits, as mentioned in the proposal itself as well as throughout 
>> this mailing list. For convenience, here's a link to the proposal on GitHub: 
>> https://github.com/rileytestut/swift-evolution/blob/master/proposals/-factory-initializers.md
>> 
>> Would love to hear any more comments on this proposal, and if we feel this 
>> is appropriate for considering for Swift 4 I'll happily re-open the pull 
>> request!
>> 
>> Riley Testut
>> 
>> On Nov 19, 2016, at 7:45 AM, arkadi daniyelian  wrote:
>> 
>>> i would appreciate this feature.
>>> 
>>> For unexperienced developers, its often hard to recognize *when* factory is 
>>> a good fit to do the job, and how exactly approach the implementation. I 
>>> imagine having this feature built into the language may help to choose and 
>>> implement factory when its the right thing to do.
>>> 
 On Nov 18, 2016, at 12:23 AM, Charles Srstka via swift-evolution 
  wrote:
 
 Is there any chance of reviving this? It seems to me that since this would 
 require Swift initializers to be implemented internally in such a way that 
 they can return a value (as Objective-C init methods do), it may affect 
 ABI stability and thus may be germane to the current stage of Swift 4 
 development.
 
 Charles
 
> On Dec 17, 2015, at 3:41 PM, Riley Testut via swift-evolution 
>  wrote:
> 
> Recently, I proposed the idea of adding the ability to implement the 
> "class cluster" pattern from Cocoa (Touch) in Swift. However, as we 
> discussed it and came up with different approaches, it evolved into a 
> functionality that I believe is far more beneficial to Swift, and 
> subsequently should be the focus of its own proposal. So here is the 
> improved (pre-)proposal:
> 
> # Factory Initializers
> 
> The "factory" pattern is common in many languages, including Objective-C. 
> Essentially, instead of initializing a type directly, a method is called 
> that returns an instance of the appropriate type determined by the input 
> parameters. Functionally this works well, but ultimately it forces the 
> client of the API to remember to call the factory method instead, rather 
> than the type's initializer. This might seem like a minor gripe, but 
> given that we want Swift to be as approachable as possible to new 
> developers, I think we can do better in this regard.
> 
> Rather than have a separate factory method, I propose we build the 
> factory pattern right into Swift, by way of specialized “factory 
> initializers”. The exact syntax was proposed by Philippe Hausler from the 
> previous thread, and I think it is an excellent solution:
> 
> class AbstractBase {
>  public factory init(type: InformationToSwitchOn) {
>  return ConcreteImplementation(type)
>  }
> }
> 
> class ConcreteImplementation : AbstractBase {
> 
> }
> 
> Why exactly would this be useful in practice? In my own development, I’ve 
> come across a few places where this would especially be relevant:
> 
> ## Class Cluster/Abstract Classes
> This was the reasoning behind the original proposal, and I still think it 
> would be a very valid use case. The public superclass would declare all 
> the public methods, and could delegate off the specific implementations 
> to the private subclasses. Alternatively, this method could be used as an 
> easy way to handle backwards-compatibility: rather than litter the code 
> with branches depending on the OS version, simply return the 
> OS-appropriate subclass from the factory initializer. Very useful.
> 
> ## Protocol Initializers
> Proposed by Brent Royal-Gordon, we could use factory initializers with 
> protocol extensions to return the appropriate instance conforming to a 
> protocol for the given needs. Similar to the class cluster/abstract class 
> method, but can work with stru

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

[Rien via swift-evolution]

+1

>   • What is your evaluation of the proposal?

Makes the language easier to understand, lowers cognitive load during coding.
I also hope this will pave the way for a overhaul of the access level system 
including modularization.

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

private vs fileprivate seems swift-only, as such I have no comparison.

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

Followed and participated in the discussions.


Regards,
Rien

Site: http://balancingrock.nl
Blog: http://swiftrien.blogspot.com
Github: http://github.com/Balancingrock
Project: http://swiftfire.nl





> On 21 Mar 2017, at 00:54, Douglas Gregor via swift-evolution 
>  wrote:
> 
> Hello Swift community,
> 
> The review of SE-0159 "Fix Private Access Levels" begins now and runs through 
> March 27, 2017. The proposal is available here:
> 
> https://github.com/apple/swift-evolution/blob/master/proposals/0159-fix-private-access-levels.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/0159-fix-private-access-levels.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
> 
> 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] [Review] SE-0159: Fix Private Access Levels

[Rien via swift-evolution]

> On 21 Mar 2017, at 08:55, Goffredo Marocchi  wrote:
> 
> 
> Sent from my iPhone
> 
>> On 21 Mar 2017, at 07:05, Rien via swift-evolution 
>>  wrote:
>> 
>> +1
>> 
>>>   • What is your evaluation of the proposal?
>> 
>> Makes the language easier to understand, lowers cognitive load during coding.
> 
> Is it really a problem for cognitive load during coding? In a world where 
> protocol extensions defined default methods introducing back the nice and 
> easy to understand concept of polymorphism by reference type where casting an 
> instances class that overrides the method declared in the protocol extensions 
> decides which  method is actually executed... well, having to juggle file and 
> scope based access levels breaks the camel's back?

It does not break the camel’s back, but it does lower the load.
I fully well realize that this issue is not a big one and highly personal, and 
if “fileprivate” remains in use, well, I won’t give up on Swift ;-)

> 
> I remain unconvinced of this, no offense meant Rien.

None taken

Regards,
Rien.

> 
>> I also hope this will pave the way for a overhaul of the access level system 
>> including modularization.
>> 
>>>   • 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?
>> 
>> private vs fileprivate seems swift-only, as such I have no comparison.
>> 
>>>   • How much effort did you put into your review? A glance, a quick 
>>> reading, or an in-depth study?
>> 
>> Followed and participated in the discussions.
>> 
>> 
>> Regards,
>> Rien
>> 
>> Site: http://balancingrock.nl
>> Blog: http://swiftrien.blogspot.com
>> Github: http://github.com/Balancingrock
>> Project: http://swiftfire.nl
>> 
>> 
>> 
>> 
>> 
>>> On 21 Mar 2017, at 00:54, Douglas Gregor via swift-evolution 
>>>  wrote:
>>> 
>>> Hello Swift community,
>>> 
>>> The review of SE-0159 "Fix Private Access Levels" begins now and runs 
>>> through March 27, 2017. The proposal is available here:
>>> 
>>> https://github.com/apple/swift-evolution/blob/master/proposals/0159-fix-private-access-levels.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/0159-fix-private-access-levels.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
>>> 
>>> 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

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

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

[Rien via swift-evolution]

> On 21 Mar 2017, at 10:15, Jonathan Hull via swift-evolution 
>  wrote:

+1

Big Yes, collect the other stuff on access levels and modules too before 
implementing anything.

> 
> I wonder if there is a way to basically accept that this is what we want to 
> do, but delay implementing it until we have other changes to make to the 
> access system (e.g. submodules) at the same time?
> 
> If things like that are scoped for Swift 5, then I would say delay 
> implementing this until then.  If it will be longer than that, we may as well 
> fix it now.
> 
> 
>> On Mar 21, 2017, at 2:07 AM, Brent Royal-Gordon via swift-evolution 
>>  wrote:
>> 
>>> On Mar 20, 2017, at 4:54 PM, Douglas Gregor via swift-evolution 
>>>  wrote:
>>> 
>>> Proposal link:
>>> 
 https://github.com/apple/swift-evolution/blob/master/proposals/0159-fix-private-access-levels.md
>>> 
>>> • What is your evaluation of the proposal?
>> 
>> I'm torn. During the SE-0025 review, I argued against scoped private. I 
>> still think it was a mistake to add it. But we did, it's out there, and I 
>> don't want to introduce churn unnecessarily.
>> 
>> Long ago, judges realized the problems caused by re-litigating old disputes 
>> and created a doctrine called "stare decisis": standing by things decided. 
>> That doesn't mean they won't correct obvious mistakes, but it does mean that 
>> they default to upholding the precedent they've already set. I think that 
>> would be a wise course here.
>> 
>> I personally would prefer to have Swift behave as SE-0159 proposes. But if 
>> the core team thinks this is going to come out 50/50—that is, this change 
>> will help about as many people as it hurts—I think they should reject this 
>> proposal and keep the status quo. I really don't want to write another 
>> review next year for SE-0289 "Reintroduce Scoped Private".
>> 
>> -- 
>> 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

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

Re: [swift-evolution] [Review] SE-0160: Limiting @objc inference

[Rien via swift-evolution]

+1

> * What is your evaluation of the proposal?

Seems to remove magic, which is something I can support, even if it means 
refactoring existing code.

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

Neutral

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

Neutral

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

None

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


Glance


Regards,
Rien

Site: http://balancingrock.nl
Blog: http://swiftrien.blogspot.com
Github: http://github.com/Balancingrock
Project: http://swiftfire.nl





> On 22 Mar 2017, at 07:03, Chris Lattner via swift-evolution 
>  wrote:
> 
> Hello Swift community, 
> 
> The review of "SE-0160: Limiting @objc inference" begins now and runs through 
> March 28. The proposal is available here:
> 
>   
> https://github.com/apple/swift-evolution/blob/master/proposals/0160-objc-inference.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, 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 you 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 
> 
> Thanks!
> 
> -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] [Review] SE-0159: Fix Private Access Levels

[Rien via swift-evolution]

> On 22 Mar 2017, at 10:53, Goffredo Marocchi via swift-evolution 
>  wrote:
> 
> 
> Sent from my iPhone
> 
> On 22 Mar 2017, at 09:43, Brent Royal-Gordon via swift-evolution 
>  wrote:
> 
>>> On Mar 21, 2017, at 11:29 PM, Matt Whiteside via swift-evolution 
>>>  wrote:
>>> 
>>> One point which was raised by a couple of different people on this thread 
>>> (Brent Royal-Gordon, Jonathan Hull), which gave me some hesitation in 
>>> voting in favor of this proposal, is that it might make more sense to leave 
>>> things alone for the time being, with the understanding that scoped access 
>>> will be solved in some more general way via submodules in the future.
>> 
>> For what it's worth, I don't really agree with Jonathan Hull on this. If 
>> we're going to remove the band-aid, we might as well rip it off now; there's 
>> no reason to wait for people to write more code for us to break.
> 
> Fair point, but I honestly do not see how the stated very strong burden of 
> proof to revert previous proposals has been met. The new proposal does seem 
> to do anything really to address the needs of those that have a legitimate 
> use for scoped access and the current state of things does not make life 
> impossible for people who want to use file based visibility only or mostly. I 
> really want to avoid having another proposal like the one that removed 
> argument labels from blocks (burying them from the type param) that is 
> incomplete and supposed to get addressed, but still has not been almost a 
> year later.
> 
> This proposal as it is does not feel complete and I do not think this helps 
> it satisfy the burden of proof needed for this release.

Agreed with the general idea of incompleteness.

I am less sanguine about the burden of proof.

Imo there is no absolute and irrevocable proof needed to accept or reject a 
change proposal.

I was under the impression that Swift should be treated as a living and 
evolving language, fitting and moulding itself to the need, desires and wishes 
of its users.

Rejecting only on the basis of need would be too limiting imo.

And that can be a problem in cases like these: an unliked feature that some 
people feel a need for.

Rien.

> 
>> 
>> My point was simply that the burden of proof is now on those proposing to 
>> revert SE-0025, and the core team shouldn't accept this proposal unless they 
>> are satisfied that the burden has clearly been met.
>> 
>> -- 
>> 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

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

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

[Rien via swift-evolution]

> On 21 Mar 2017, at 08:05, Rien  wrote:
> 
> +1

-1: I have revised my opinion.


> 
>>  • What is your evaluation of the proposal?
> 
> Makes the language easier to understand, lowers cognitive load during coding.
> I also hope this will pave the way for a overhaul of the access level system 
> including modularization.

I still hope that fileprivate will be dumped one day. Presumably when a better 
proposal is on the table.
However it is clear that for some people the disadvantage of dropping it now is 
bigger than the advantage to the proponents together.
Regardless of wether the need is only perceived or not.

> 
>>  • Is the problem being addressed significant enough to warrant a change 
>> to Swift?
> 
> yes.

yes, but not without an alternative solution in place at the time fileprivate 
is dropped.


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

Yes

> 
>>  • If you have used other languages or libraries with a similar feature, 
>> how do you feel that this proposal compares to those?
> 
> private vs fileprivate seems swift-only, as such I have no comparison.

Same

> 
>>  • How much effort did you put into your review? A glance, a quick 
>> reading, or an in-depth study?
> 
> Followed and participated in the discussions.


Same.

> 
> 
> Regards,
> Rien
> 
> Site: http://balancingrock.nl
> Blog: http://swiftrien.blogspot.com
> Github: http://github.com/Balancingrock
> Project: http://swiftfire.nl
> 
> 
> 
> 
> 
>> On 21 Mar 2017, at 00:54, Douglas Gregor via swift-evolution 
>>  wrote:
>> 
>> Hello Swift community,
>> 
>> The review of SE-0159 "Fix Private Access Levels" begins now and runs 
>> through March 27, 2017. The proposal is available here:
>> 
>> https://github.com/apple/swift-evolution/blob/master/proposals/0159-fix-private-access-levels.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/0159-fix-private-access-levels.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
>> 
>> 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: Partial Implementations

[Rien via swift-evolution]

I think the access levels should be revised, no need to introduce a new concept.

Regards,
Rien

Site: http://balancingrock.nl
Blog: http://swiftrien.blogspot.com
Github: http://github.com/Balancingrock
Project: http://swiftfire.nl





> On 23 Mar 2017, at 19:12, Charles Srstka via swift-evolution 
>  wrote:
> 
> MOTIVATION:
> 
> In current Swift, a pattern has emerged among some developers, in order to 
> logically group parts of a class or struct’s declaration, particularly around 
> protocols:
> 
> class Foo {
>   …
> }
> 
> extension Foo: SomeProtocol {
>   ...
> }
> 
> extension Foo: SomeOtherProtocol {
>   ...
> }
> 
> This has certain appealing characteristics; in addition to the obvious 
> organizational property, this pattern also keeps protocol implementations 
> close to the declaration of conformance to the protocol. Unfortunately, there 
> are a couple of problems:
> 
> 1. Extensions cannot contain stored properties. This means that if a protocol 
> requires a property, and it makes sense for that property to be stored, its 
> conformance cannot be completely contained within the extension, but rather 
> some of it must be in the main declaration.
> 
> 2. It’s not uncommon for these protocol conformances to need access to the 
> type’s private internal state, but extensions do not have access to private 
> members within the state. This necessitates declaring the needed state as 
> fileprivate rather than private, a fact has been a primary rallying point in 
> the battle that’s currently raging on this mailing list over whether we 
> should keep the ‘private’ access modifier, and which I would surmise is 
> probably the major remaining use of ‘fileprivate’ in modern Swift code.
> 
> 3. Since members that are declared ‘fileprivate’ cannot be accessed outside 
> the file, these protocol conformance extensions must belong to the same file 
> as the original declaration, which can lead to very long file sizes when the 
> code to implement a protocol is very long, or when a type supports a large 
> number of protocols.
> 
> PROPOSED SOLUTION:
> 
> Add a keyword to declare only part of a type’s implementation. I am 
> suggesting ‘partial’ as the keyword, but this can be changed for a better 
> name if needed. Partial conformances would be declared like this:
> 
> class Foo {
>   private func somePrivateMethod() { … }
> }
> 
> partial Foo: SomeProtocol {
>   var someRequiredProperty: Int = 5
> 
>   func someRequiredMethod() {
>   self.somePrivateMethod()
>   }
> }
> 
> partial Foo: SomeOtherProtocol {
>   func someOtherRequiredMethod() {
>   self.somePrivateMethod()
>   }
> }
> 
> When compiling this, the compiler would simply treat all the contents of 
> partial declarations as if they were located within the original declaration, 
> making the above equivalent to this:
> 
> class Foo: SomeProtocol, SomeOtherProtocol {
>   private func somePrivateMethod() { … }
> 
>   var someRequiredProperty: Int = 5
> 
>   func someRequiredMethod() {
>   self.somePrivateMethod()
>   }
> 
>   func someOtherRequiredMethod() {
>   self.somePrivateMethod()
>   }
> }
> 
> Obviously, partial declarations would only be allowed within the same module 
> (or submodule, once we get them) as the original declaration.
> 
> The advantages to this approach are:
> 
> 1. Given a pattern that many developers are adopting, this proposal would 
> provide a mechanism to follow that pattern properly instead of repurposing a 
> mechanism—extensions—which was intended for something else. The Swift manual 
> claims that extensions are meant to add things “to a type that is declared 
> elsewhere, or even to a type that you imported from a library or a 
> framework,” not for separating your own code into parts.
> 
> 2. Partial implementations can now implement the entirety of a protocol, 
> including stored properties if the protocol necessitates them.
> 
> 3. Since the contents of all partial implementations are considered to be 
> part of the same declaration, the contents of partial implementations can 
> access private members, which should allow the almost complete elimination of 
> ‘fileprivate’ from developers’ codebases, simplifying the access control 
> model.
> 
> 4. Since partial implementations are not dependent on file-based 
> organization, they can be stored in separate files, as long as those files 
> are compiled into the same module, thus allowing for smaller, leaner, source 
> files that are easier to read and understand.
> 
> What do you think?
> 
> 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] [Review] SE-0159: Fix Private Access Levels

[Rien via swift-evolution]

> On 23 Mar 2017, at 21:26, Jose Cheyo Jimenez  wrote:
> 
>> 
>> On Mar 23, 2017, at 11:35 AM, Rien via swift-evolution 
>>  wrote:
>> 
>> 
>>> On 21 Mar 2017, at 08:05, Rien  wrote:
>>> 
>>> +1
>> 
>> -1: I have revised my opinion.
>> 
>> 
>>> 
>>>>• What is your evaluation of the proposal?
>>> 
>>> Makes the language easier to understand, lowers cognitive load during 
>>> coding.
>>> I also hope this will pave the way for a overhaul of the access level 
>>> system including modularization.
>> 
>> I still hope that fileprivate will be dumped one day. Presumably when a 
>> better proposal is on the table.
>> However it is clear that for some people the disadvantage of dropping it now 
>> is bigger than the advantage to the proponents together.
>> Regardless of wether the need is only perceived or not.
>> 
>>> 
>>>>• Is the problem being addressed significant enough to warrant a change 
>>>> to Swift?
>>> 
>>> yes.
>> 
>> yes, but not without an alternative solution in place at the time 
>> fileprivate is dropped.
> 
> Can you clarify what you mean here? 

Quite obviously the functionality of the current private feature is part of the 
workflow of a considerable number of people.
It does not really matter if this feature is necessary or not, they have it 
integrated in their thinking and workflow.
(Note: we don’t need "for element in collection" either, plain "1..N" for loops 
would suffice)
To me, that is enough reason to postpone this proposal until this functionality 
can be retained while at the same time reverting private back to its original 
meaning.

Rien.

> 
>> 
>> 
>>> 
>>>>• Does this proposal fit well with the feel and direction of Swift?
>>> 
>>> Yes
>> 
>> Yes
>> 
>>> 
>>>>• If you have used other languages or libraries with a similar feature, 
>>>> how do you feel that this proposal compares to those?
>>> 
>>> private vs fileprivate seems swift-only, as such I have no comparison.
>> 
>> Same
>> 
>>> 
>>>>• How much effort did you put into your review? A glance, a quick 
>>>> reading, or an in-depth study?
>>> 
>>> Followed and participated in the discussions.
>> 
>> 
>> Same.
>> 
>>> 
>>> 
>>> Regards,
>>> Rien
>>> 
>>> Site: http://balancingrock.nl
>>> Blog: http://swiftrien.blogspot.com
>>> Github: http://github.com/Balancingrock
>>> Project: http://swiftfire.nl
>>> 
>>> 
>>> 
>>> 
>>> 
>>>> On 21 Mar 2017, at 00:54, Douglas Gregor via swift-evolution 
>>>>  wrote:
>>>> 
>>>> Hello Swift community,
>>>> 
>>>> The review of SE-0159 "Fix Private Access Levels" begins now and runs 
>>>> through March 27, 2017. The proposal is available here:
>>>> 
>>>> https://github.com/apple/swift-evolution/blob/master/proposals/0159-fix-private-access-levels.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/0159-fix-private-access-levels.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
>>>> 
>>>> 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

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

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

[Rien via swift-evolution]

Sounds good on a first read through.

Regards,
Rien

Site: http://balancingrock.nl
Blog: http://swiftrien.blogspot.com
Github: http://github.com/Balancingrock
Project: http://swiftfire.nl





> On 24 Mar 2017, at 21:26, Ankit Aggarwal via swift-evolution 
>  wrote:
> 
> Hi,
> 
> We would love to get some feedback on a draft proposal for defining custom 
> target layouts in the Package Manager. This proposal allows overriding the 
> target layout rules set by the Package Manager and simplifies some complex 
> "magic" behaviours. 
> 
> You can find the proposal at the link below. The text is also included in the 
> email.
> 
> https://github.com/aciidb0mb3r/swift-evolution/blob/custom-targets-layout/proposals/-package-manager-custom-targets-layout.md
> 
> Thanks,
> Ankit
> 
> --
> 
> Package Manager Custom Targets Layout
>   • Proposal: SE-
>   • Author: Ankit Aggarwal
>   • Review Manager: TBD
>   • Status: Discussion
>   • Bug: SR-29
> Introduction
> This proposal enhances the Package.swift manifest APIs to support custom 
> target layouts, and removes a convention which allowed omission of targets 
> from the manifest.
> 
> Motivation
> The Package Manager uses a convention system to infer targets structure from 
> disk layout. This works well for most packages, which can easily adopt the 
> conventions, and frees users from needing to update their Package.swift file 
> every time they add or remove sources. Adopting the conventions is more 
> difficult for some packages, however – especially existing C libraries or 
> large projects, which would be difficult to reorganize. We intend to give 
> users a way to make such projects into packages without needing to conform to 
> our conventions.
> 
> The current convention rules make it very convenient to add new targets and 
> source files by inferring them automatically from disk, but they also can be 
> confusing, overly-implicit, and difficult to debug; for example, if the user 
> does not follow the conventions correctly which determine their targets, they 
> may wind up with targets they don't expect, or not having targets they did 
> expect, and either way their clients can't easily see which targets are 
> available by looking at the Package.swift manifest. We want to retain 
> convenience where it really matters, such as easy addition of new source 
> files, but require explicit declarations where being explicit adds 
> significant value. We also want to make sure that the implicit conventions we 
> keep are straightforward and easy to remember.
> 
> Proposed solution
>   • We propose to stop inferring targets from disk. They must be 
> explicitly declared in the manifest file. The inference was not very useful, 
> as targets eventually need to be declared in order to use common features 
> such as product and target dependencies, or build settings (which are planned 
> for Swift 4). Explicit target declarations make a package easier to 
> understand by clients, and allow us to provide good diagnostics when the 
> layout on disk does not match the declarations.
> 
>   • We propose to remove the requirement that name of a test target must 
> have suffix "Tests". Instead, test targets will be explicitly declared as 
> such in the manifest file.
> 
>   • We propose a list of pre-defined search paths for declared targets.
> 
> When a target does not declare an explicit path, these directories will be 
> used to search for the target. The name of the directory must match the name 
> of the target. The search will be done in order and will be case-sensitive.
> 
> Regular targets: package root, Sources, Source, src, srcs. Test targets: 
> Tests, package root, Sources, Source, src, srcs.
> 
> It is an error if a target is found in more than one of these paths. In such 
> cases, the path should be explicitly declared using the path property 
> proposed below.
> 
>   • We propose to add a factory method testTarget to the Target class, to 
> define test targets.
> 
> .testTarget(name: "FooTests", dependencies: ["Foo"])
>   • We propose to add three properties to the Target class: path, sources 
> andexclude.
> 
>   • path: This property defines the path to the top-level 
> directory containing the target's sources, relative to the package root. It 
> is not legal for this path to escape the package root, i.e., values like 
> "../Foo", "/Foo" are invalid. The default value of this property will be nil, 
> which means the target will be searched for in the pre-defined paths. The 
> empty string ("") or dot (".") implies that the target's sources are directly 
> inside the package root.
> 
>   • sources: This property defines the source files to be 
> included in the target, relative to the target path. The default value of 
> this property will be an empty array, which means all valid source files 
> found in the target's path will be included. This can contain directories and 
> individual s

Re: [swift-evolution] [Pitch] Localized Swift Frameworks

[Rien via swift-evolution]

> On 24 Mar 2017, at 21:40, Jean-Daniel via swift-evolution 
>  wrote:
> 
> 
>> Le 24 mars 2017 à 18:28, Jeff Kelley via swift-evolution 
>>  a écrit :
>> 
>> One of the things that struck me from today’s Apple press release about 
>> Swift Playgrounds being localized in more languages is this screenshot:
>> 
>> 
>> 
>> All of the UI is fully localized for Chinese, except the actual code. As far 
>> as I know, almost every major programming language and major platform 
>> framework is primarily English; it’s become the de facto language for 
>> developers. But does that have to be the case?
>> 
>> Imagine a world where alongside our Swift frameworks, we ship .strings files 
>> that contain translations of our APIs to other languages. From some other 
>> screenshots we see that Swift Playgrounds is providing translations of 
>> method names to explain them, here providing “avanzar” for “moveForward()”.
>> 
>> 
>> 
>> A scenario where Swift supported localized frameworks might see a .strings 
>> file with a format like this:
>> 
>> "moveForward()": "avanzar()"
>> 
>> Then, in Swift code, whether through an IDE, some metadata in a comment in 
>> the Swift file, or file extension (think “Foo.es.swift”), a developer who 
>> selects Spanish could simply write avanzar() and understand it in her native 
>> language. In fact, if the IDE is the layer that handles language selection, 
>> two developers who don’t even speak the same language could collaborate on 
>> code, and names from the framework would appear to each in their native 
>> language!
>> 
>> Comments and locally-defined names are of course still a barrier, but this 
>> isn’t new. I know that “mazu” means “first” in Japanese thanks to some code 
>> I worked on with an old coworker.
>> 
>> This is obviously out of scope for Swift 4, and would require significant 
>> effort to support, both technically in Swift itself and for those shipping 
>> Swift frameworks, both inside and outside of Apple, to provided localized 
>> names, so I wanted to throw this out to see if the community is even 
>> interested.
>> 
>> There’s just something about the idea of kids all over the world using Swift 
>> Playgrounds completely in their own language that makes me think this could 
>> help Swift achieve its stated goal of world dominance.
> 
> This has already been done for a couple of languages and it always result in 
> the same very nasty effect: It fragment the community. Trying to search for a 
> method name or a compiler error message in google will returns only the 
> results in your language. 
> 
> This is incredibly frustrating, especially when your language is not English. 
> I hate having to work with localized IDE and toolchain for that reason. 
> Extending the localization to the language itself will just make the problem 
> worse.

Amen to that!
Back in the days (pre inet) where localization for Mac’s was almost unavoidable 
I took the extra effort to order my computers in the US, specifically to avoid 
having to use localized machines.
While localized machines are necessary for some end-users, for me its a 
nightmare.

Rien.

OT: I have had this discussion more than once:

Me: Why is this mac more than twice the price in the US?
Seller: Because it is localized.
Me: But I don’t want a localized machine.
Seller: Uh, ok. I think I can do that… let me see… yes, it will take some time, 
but I can get you one…
Me: And will it then be cheaper?
Seller: No.

> 
> 
> ___
> 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-0159: Fix Private Access Levels

[Rien via swift-evolution]

> On 26 Mar 2017, at 13:23, Andrey Tarantsov via swift-evolution 
>  wrote:
> 
> > What is your evaluation of the proposal?
> 
> Very strong -1. Drew has said it all.
> 
> A few extra points:
> 
> * If you split a class into a bunch of extensions, chances are it's a large 
> class, and fileprivate keyword provides crucial documentation on which 
> methods and fields are accessed from outside the scope. Even if someone 
> blindly uses private until compiler complains, then switches to fileprivate 
> without thinking, there's still value when reading the code. (This has been 
> mentioned as one of the points against scoped private.)

it should, but fileprivate only means that something can be done, not that 
something is done.
And unfortunately or not, people will use this keyword in the wrong way, forget 
to update access levels after changes etc.
So while this should be true in theory, in praxis it is almost never the case.

Rien.

> 
> * Encapsulation is in the spirit of Swift's safety goals, we want to 
> encourage it.
> 
> * // MARK is perfectly fine for tightly-coupled class bodies, so if you find 
> yourself using tons of fileprivate, consider switching to a single body with 
> marks
> 
> * I really like the point that we should uphold the original decision unless 
> we find new compelling arguments that were not considered initially.
> 
> 
> > Is the problem being addressed significant enough to warrant a change to 
> > Swift?
> 
> No. I haven't personally seen any complains about this feature in my circles; 
> everyone is happy about tighter access controls.
> 
> 
> > Does this proposal fit well with the feel and direction of Swift?
> 
> It feels actively against the safety and readability goals of Swift.
> 
> 
> > If you have used other languages or libraries with a similar feature, how 
> > do you feel that this proposal compares to those?
> 
> This has been beaten to death in the original proposal.
> 
> 
> > How much effort did you put into your review? A glance, a quick reading, or 
> > an in-depth study?
> 
> Thorough reading of the first half of this discussion, and active 
> participation in the original discussion (as well as writing and shipping 
> lots of Swift code since Swift 0.x).
> 
> 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

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

[Rien via swift-evolution]

> On 27 Mar 2017, at 16:46, Steven Knodl via swift-evolution 
>  wrote:
> 
> Late to the party here 
>  
> * What is your evaluation of the proposal?
> I’m -1 on this.  The proposal is not a difficult read, but may have been 
> simply more simply named “Remove Scoped Access Level/Revert SE-0025” as that 
> is what is being proposed. “Fix” seems to me to be a unfortunately worded 
> judgmental proposal title.
>  
> * Is the problem being addressed significant enough to warrant a change?
> No.  I consider myself to be a fairly “new/n00b” Obj-C/Swift developer. 
> Although SE-0025 was a change that required source changes when implemented, 
> the reasoning was not difficult to understand and changes were simple to make 
> once identified.   Here they are from SE-0025
>  
>   • public: symbol visible outside the current module
>   • internal: symbol visible within the current module
>   • fileprivate: symbol visible within the current file
>   • private: symbol visible within the current declaration
>  
> Moving forward these changes are not difficult to comprehend.  I tend to make 
> _everything_ “private” up front so I don’t have any API leakage.  Then dial 
> back to “fileprivate” as needed.  It’s not difficult for me I guess.

Right. I do that myself more than I would like to admit.
But when we only loosen up/tighten down during coding then access levels are 
almost useless.
The point of access level control is in the design, not in the coding.
If we made a design (including access levels) and then have to dial back, that 
should be a warning that something is wrong.
To me, this is an argument in favour of the proposal.

Rien.



>   As such, I don’t believe that this change was “Actively Harmful”,  
> especially for new developers who have a clean slate or simply are leaving 
> everything unmarked (internal) anyhow until they move up to more advanced 
> topics.  Unraveling a generic or functional code someone else wrote uses way 
> more cognitive power. 
>  
> I’d like to address the suggestion that the migration for SE-0159 could 
> “simply” be a search and replace without loss of functionality.  This doesn’t 
> make sense if you consider the entire code lifecycle.  Sure the code gets 
> migrated and compiles.  This is fine if they code _never_ has to be read 
> again.  But as we know, code is written once and _read many times_ as it will 
> need to be maintained.  The distinction between private and fileprivate 
> contains information, and although it may work correctly now, some 
> information meant to help maintain that code has been lost if these keywords 
> are merged and the functionality of scoped access is removed.  So yes if you 
> don’t maintain the code where this migration takes place, this would be ok. 
> But Swift strives for readability.  Moving classes to separate files to 
> address these issues, creates a multitude of Bunny classes where again for 
> readability some classes belong together in the same file for ease of 
> comprehension (again, code is written once , read many times)
>  
> * Does this proposal fit well with the feel and direction of Swift?
> The spirit of the proposal to simplify access levels is well taken.  This 
> proposal however simplifies at the expense of lost functionality (Scoped 
> Access levels) with no replacement.  The threads talk a about submodules and 
> other solutions that could fill this gap that are not on the roadmap, planned 
> or possible which makes them  non-admissible in considering this proposal.
>  
> * If you have used other languages, libraries, or package managers with a 
> similar feature, how do you feel that this proposal compares to those?
> I am more familiar with scoped access so perhaps that feels more natural to 
> me.  But with the current implementation Swift users can choose whether they 
> use File Based or Scope Based tools, so although not ideal to either side, 
> acceptable until a suitable replacement could be forged.
>  
> * How much effort did you put into your review? A glance, a quick reading, or 
> an in-depth study?
> Re-read SE-0025/proposal/most of this very long thread
>  
>  
>  
>  
> From:  on behalf of Tino Heth via 
> swift-evolution 
> Reply-To: Tino Heth <2...@gmx.de>
> Date: Monday, March 27, 2017 at 6:48 AM
> To: Zach Waldowski 
> Cc: 
> Subject: Re: [swift-evolution] [Review] SE-0159: Fix Private Access Levels
>  
> 
> 
>> I am now absolutely thrilled to create a filter to Mark As Read anything 
>> else arising from this thread. Good luck.
>  
> That might be a good idea — after more than 200 messages, and a quite 
> circular discussion with an unhealthy amount of ignorance for the opposing 
> side ;-).
>  
> To fight the latter, I just tried to take the position that "new private" is 
> really important, and this imho leads to interesting consequences...
> This access modifier really doesn't solve a problem, like "let" does (unless 
> the problem you want to solve is having a language wit

Re: [swift-evolution] Remove prefixes from all Apple frameworks

[Rien via swift-evolution]

The problem with unprefixed names is name clashes with my own code.
Not often, but often enough. Then you have to invent your owm prefixes.
Besides, NS… and UI… make it much, MUCH more convenient to google…

Regards,
Rien

Site: http://balancingrock.nl
Blog: http://swiftrien.blogspot.com
Github: http://github.com/Balancingrock
Project: http://swiftfire.nl





> On 30 Mar 2017, at 23:42, Louis D'hauwe via swift-evolution 
>  wrote:
> 
> Loud and clear! :-)
> I am, however, very interested in the thoughts of the Swift evolution 
> community for this idea.
> 
> – Louis D'hauwe
> 
>> On 30 Mar 2017, at 23:28, Joe Groff  wrote:
>> 
>>> 
>>> On Mar 30, 2017, at 2:03 PM, Louis D'hauwe via swift-evolution 
>>>  wrote:
>>> 
>>> Apple frameworks contain prefixes, carried over from Objective-C.
>>> These exist to prevent class and method name collisions.
>>> 
>>> Mattt Thompson has a great article about this, containing the following 
>>> brilliant excerpt:
>>> "Namespacing is the preeminent bugbear of Objective-C. A cosmetic quirk 
>>> with global implications, the language’s lack of identifier containers 
>>> remains a source of prodigious quantities of caremad for armchair language 
>>> critics." (http://nshipster.com/namespacing/)
>>> 
>>> Since Swift can handle with these naming conflicts, wouldn't it make sense 
>>> to drop all framework prefixes in a Swift environment?
>>> 
>>> A classic example is UIKit, where all classes are prefixed with "UI". 
>>> Code example:
>>> 
>>>import UIKit
>>> 
>>>class FooViewController: UIViewController {
>>> 
>>>}
>>> 
>>> Dropping the prefix would simply lead to the following:
>>> 
>>>import UIKit
>>> 
>>>class FooViewController: ViewController {
>>> 
>>>}
>>> 
>>> Since conflicts need to be handled by specifying the module name, the 
>>> following could be used if "ViewController" was also used by either some, 
>>> other than UIKit, imported framework or by a user defined class:
>>> 
>>>import UIKit
>>> 
>>>class FooViewController: UIKit.ViewController {
>>> 
>>>}
>>> 
>>> "UIKit.ViewController" is of course quite longer than the current 
>>> "UIViewController".
>>> An improvement could be to allow frameworks to specify an abbreviated form.
>>> UIKit could define "UI" as its abbreviation, making the following code 
>>> valid:
>>> 
>>>import UI
>>> 
>>>class FooViewController: UI.ViewController {
>>> 
>>>}
>>> 
>>> This all seems to me like a natural continuation of SE-0086.
>>> I do realise this would be a major change, breaking pretty much every Swift 
>>> iOS, macOS, tvOS and watchOS project.
>>> But in the long term, I think it's worth it.
>> 
>> The teams at Apple own how their APIs get reflected in Swift. This is 
>> outside the scope of swift-evolution.
>> 
>> -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] [Review] SE-0161: Smart KeyPaths: Better Key-Value Coding for Swift

[Rien via swift-evolution]

>   • What is your evaluation of the proposal?

+1


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

I do not see this as a problem, but as added functionality that would be 
beneficial


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

100%


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

Yes, but this is actually better due to type safety


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

Quick reading.


One observation though: I feel that “PartialKeyPath” does not add information, 
“partial” leaves one swimming: "what exactly is partial?”.
“RootKeyPath” would be more expressive imo. If RootKeyPath would be 
unacceptable, I would still prefer “RelativeKeyPath” over “PartialKeyPath”. 

Regards,
Rien

Site: http://balancingrock.nl
Blog: http://swiftrien.blogspot.com
Github: http://github.com/Balancingrock
Project: http://swiftfire.nl





> On 30 Mar 2017, at 18:25, Douglas Gregor via swift-evolution 
>  wrote:
> 
> Hello Swift community,
> 
> The review of SE-0161 "Smart KeyPaths: Better Key-Value Coding for Swift" 
> begins now and runs through April 5, 2017. The proposal is available here:
> 
> https://github.com/apple/swift-evolution/blob/master/proposals/0161-key-paths.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/0161-key-paths.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
> 
> 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] [Proposal] Factory Initializers

[Rien via swift-evolution]

> On 01 Apr 2017, at 01:35, Riley Testut via swift-evolution 
>  wrote:
> 
> 
>> On Mar 20, 2017, at 8:07 PM, Greg Parker  wrote:
>> 
>> This needs more explanation. It is allowed for a subclass to implement a 
>> convenience initializer that has the same signature as a superclass 
>> convenience initializer or a superclass designated initializer. The 
>> convenience-over-convenience case is not technically overriding, but it is 
>> misleading to say only that a convenience initializer cannot be overridden. 
>> Do factory initializers follow exactly the same rules here as convenience 
>> initializers?
> 
> Yes, that is what I meant. For simplicity, I think the factory initializer 
> inheritance rules should match exactly that of convenience initializers.
> 
>> In addition: designated initializers and convenience initializers have rules 
>> about which other initializers can be called from an implementation. These 
>> rules are intended to guarantee that the chain of designated initializers is 
>> called correctly. What are the precise rules for factory initializers 
>> calling other initializers? What are the precise rules for non-factory 
>> initializers calling factory initializers?
> 
> Factory initializers can call any other initializers. Since calling 
> convenience initializers would still call required initializers, the chain 
> would be correct (unless I’m missing something). As for other initializers 
> calling factory initializers, my gut says this should not be allowed. Factory 
> initializers are supposed to initialize and return a value, whereas other 
> initializers implicitly assign to self. Therefore calling a factory 
> initializer from a self-assigning initializer wouldn’t do much, and I don’t 
> see any benefit to allowing this.
> 
> 
>> On Mar 21, 2017, at 8:49 AM, David Rönnqvist  
>> wrote:
>> 
>> Forgive me if that has already been discussed in the email threads prior to 
>> the proposal, but what I’m missing from this proposal is a discussion of the 
>> problems factory initializers solve (other than the examples at the end) and 
>> an explanation of why factory initializers are the right solution to 
>> that/those problems in Swift.
> 
> I can answer this anecdotally; when learning iOS development and Objective-C, 
> it was (in my opinion) hard to know whether an Objective-C class was meant to 
> be initialized via [[Class alloc] initWithParameters:] or [Class 
> classWithParameters:]. Pre-ARC this did actually have meaning, but post 
> ARC/iOS 5 it just seemed to be whatever the framework developer preferred 
> (not to mention that [Class new] was also another option…).
> 
> When Swift combined all these forms into one common Class(parameters:) 
> format, this greatly reduced this cognitive load. However, as outlined in the 
> proposal, this meant that the factory pattern had to be moved out of the 
> initializers and back into class methods. Because of this, now if you want to 
> implement the factory pattern, you’re bringing back this same confusion from 
> Objective-C; the client has to remember whether your class is initialized via 
> standard Class(parameters:) syntax, or by calling a class method 
> Class.classWithParameters(). Ultimately, I don’t believe there should be a 
> difference between the two for the average programmer. You want an instance 
> of the class, so you should retrieve one by calling an initializer. They 
> don’t need to know or care whether the initializer is directly assigning to 
> self or returning a value, as long as they get the value they need.

If we want to hide the fact that a factory method is a factory method, then we 
need the “assign to self’ in the initializer. Introducing a ‘factory’ keyword 
for that purpose seem counter productive to me.

Rien.

> 
> Beyond this, however, I think the factory initializers on protocols is one of 
> this proposal’s biggest wins. For protocol oriented programming, it’s nice to 
> be apply to supply a default implementation so client’s don’t need to declare 
> their own type. However, if you come across a new codebase/framework, you 
> might not know the difference between the specific type you’re using and the 
> protocol itself (or even which one is which). I’ve personally encountered 
> this many times with Apple’s frameworks, such as UIActivityItemProvider and 
> UIActivityItemSource (which one is the protocol and which one is the type? 
> Hard to know and remember when first using them). With factory initializers 
> on protocol extensions, the initializer can return a private type conforming 
> to the protocol, so again there’s no need to worry about what is the concrete 
> type and what is the protocol.
> 
> P.S. Phase 2 End Question
> 
> I didn’t realize until today that apparently Swift 4 Phase 2 ends tomorrow. 
> Is this true, and does that mean this is now too late to make it into Swift 4?
> ___
> swift-evolution mailing list
> swift-evolution@swift.org

Re: [swift-evolution] [Pitch] Add an all algorithm to Sequence

[Rien via swift-evolution]

> On 01 Apr 2017, at 10:47, Xiaodi Wu via swift-evolution 
>  wrote:
> 
> On Sat, Apr 1, 2017 at 3:40 AM, David Hart via swift-evolution 
>  wrote:
> 
> On 1 Apr 2017, at 09:50, Brandon Trussell  wrote:
> 
>> I agree that based on the method name, I thought a collection would be 
>> returned.  
> 
> Now that I think more about it, I think you're right. It is confusing. 
> Perhaps:
> 
> allAre(equalTo: )
> allAre(matching: )
> 
> Well, if we're going to go full stdlib naming guidelines, shouldn't they be--
> 
> ```
> areAll(equalTo:)
> areAll(matching:)
> ```


thatAre(equalTo: )
thatAre(matching: )

Regards,
Rien

Site: http://balancingrock.nl
Blog: http://swiftrien.blogspot.com
Github: http://github.com/Balancingrock
Project: http://swiftfire.nl


> 
>> On Sat, Apr 1, 2017 at 12:36 AM, David Hart via swift-evolution 
>>  wrote:
>> 
>> 
>> > On 1 Apr 2017, at 06:02, Will Stanton via swift-evolution 
>> >  wrote:
>> >
>> > +1 to adding, but the name `all` suggests (to me) the return of another 
>> > sequence, not a Bool.
>> 
>> I'm not too concerned because the mandatory labels makes it clear.
>> 
>> > Perhaps the function name should be question-like?
>> >
>> > Suggesting: `membersSatisfy(condition:)` or `allSatisfy(condition:)` or 
>> > maybe even just `satisfies(condition:)`
>> > The question-like modifier/verb is necessary to suggest a Bool and IMO not 
>> > a needless word.
>> >
>> > Regards,
>> > Will Stanton
>> >
>> >> On Mar 31, 2017, at 11:28, Ben Cohen via swift-evolution 
>> >>  wrote:
>> >>
>> >> Hopefully non-controversial, aside from the naming of the method and 
>> >> arguments, about which controversy abounds
>> >
>> > ___
>> > 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
>> 
>> 
>> 
>> -- 
>> Brandon
> 
> ___
> 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] [Pitch] Add an all algorithm to Sequence

[Rien via swift-evolution]

> On 01 Apr 2017, at 16:10, David Hart  wrote:
> 
>> 
>> On 1 Apr 2017, at 11:32, Rien  wrote:
>> 
>> 
>>> On 01 Apr 2017, at 10:47, Xiaodi Wu via swift-evolution 
>>>  wrote:
>>> 
>>> On Sat, Apr 1, 2017 at 3:40 AM, David Hart via swift-evolution 
>>>  wrote:
>>> 
 On 1 Apr 2017, at 09:50, Brandon Trussell  wrote:
 
 I agree that based on the method name, I thought a collection would be 
 returned.  
>>> 
>>> Now that I think more about it, I think you're right. It is confusing. 
>>> Perhaps:
>>> 
>>> allAre(equalTo: )
>>> allAre(matching: )
>>> 
>>> Well, if we're going to go full stdlib naming guidelines, shouldn't they 
>>> be--
>>> 
>>> ```
>>> areAll(equalTo:)
>>> areAll(matching:)
>>> ```
>> 
>> 
>> thatAre(equalTo: )
>> thatAre(matching: )
> 
> That would be confusing again. You'd get the impression that the functions 
> are returning elements of the Sequence, not a Bool.

Yup. my bad.

Rien.


> 
>> Regards,
>> Rien
>> 
>> Site: http://balancingrock.nl
>> Blog: http://swiftrien.blogspot.com
>> Github: http://github.com/Balancingrock
>> Project: http://swiftfire.nl
>> 
>> 
>>> 
 On Sat, Apr 1, 2017 at 12:36 AM, David Hart via swift-evolution 
  wrote:
 
 
> On 1 Apr 2017, at 06:02, Will Stanton via swift-evolution 
>  wrote:
> 
> +1 to adding, but the name `all` suggests (to me) the return of another 
> sequence, not a Bool.
 
 I'm not too concerned because the mandatory labels makes it clear.
 
> Perhaps the function name should be question-like?
> 
> Suggesting: `membersSatisfy(condition:)` or `allSatisfy(condition:)` or 
> maybe even just `satisfies(condition:)`
> The question-like modifier/verb is necessary to suggest a Bool and IMO 
> not a needless word.
> 
> Regards,
> Will Stanton
> 
>> On Mar 31, 2017, at 11:28, Ben Cohen via swift-evolution 
>>  wrote:
>> 
>> Hopefully non-controversial, aside from the naming of the method and 
>> arguments, about which controversy abounds
> 
> ___
> 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
 
 
 
 -- 
 Brandon
>>> 
>>> ___
>>> 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] [Pitch] Add an all algorithm to Sequence

[Rien via swift-evolution]

> On 01 Apr 2017, at 18:09, Muse M  wrote:
> 
> At this stage, it's rather confuse to me, if return boolean, probably sizeOf 
> and boolOf is easier for me.
> 
> boolOf(equalTo:)
> boolOf(matching:)
> 

Or:

allEqual(to: )
allMatch(_:)

or

allItemsEqual(to: )
allItemsMatch(_:)

Rien.

> On Sat, Apr 1, 2017 at 10:54 PM, Rien via swift-evolution 
>  wrote:
> 
> > On 01 Apr 2017, at 16:10, David Hart  wrote:
> >
> >>
> >> On 1 Apr 2017, at 11:32, Rien  wrote:
> >>
> >>
> >>> On 01 Apr 2017, at 10:47, Xiaodi Wu via swift-evolution 
> >>>  wrote:
> >>>
> >>> On Sat, Apr 1, 2017 at 3:40 AM, David Hart via swift-evolution 
> >>>  wrote:
> >>>
> >>>> On 1 Apr 2017, at 09:50, Brandon Trussell  wrote:
> >>>>
> >>>> I agree that based on the method name, I thought a collection would be 
> >>>> returned.
> >>>
> >>> Now that I think more about it, I think you're right. It is confusing. 
> >>> Perhaps:
> >>>
> >>> allAre(equalTo: )
> >>> allAre(matching: )
> >>>
> >>> Well, if we're going to go full stdlib naming guidelines, shouldn't they 
> >>> be--
> >>>
> >>> ```
> >>> areAll(equalTo:)
> >>> areAll(matching:)
> >>> ```
> >>
> >>
> >> thatAre(equalTo: )
> >> thatAre(matching: )
> >
> > That would be confusing again. You'd get the impression that the functions 
> > are returning elements of the Sequence, not a Bool.
> 
> Yup. my bad.
> 
> Rien.
> 
> 
> >
> >> Regards,
> >> Rien
> >>
> >> Site: http://balancingrock.nl
> >> Blog: http://swiftrien.blogspot.com
> >> Github: http://github.com/Balancingrock
> >> Project: http://swiftfire.nl
> >>
> >>
> >>>
> >>>> On Sat, Apr 1, 2017 at 12:36 AM, David Hart via swift-evolution 
> >>>>  wrote:
> >>>>
> >>>>
> >>>>> On 1 Apr 2017, at 06:02, Will Stanton via swift-evolution 
> >>>>>  wrote:
> >>>>>
> >>>>> +1 to adding, but the name `all` suggests (to me) the return of another 
> >>>>> sequence, not a Bool.
> >>>>
> >>>> I'm not too concerned because the mandatory labels makes it clear.
> >>>>
> >>>>> Perhaps the function name should be question-like?
> >>>>>
> >>>>> Suggesting: `membersSatisfy(condition:)` or `allSatisfy(condition:)` or 
> >>>>> maybe even just `satisfies(condition:)`
> >>>>> The question-like modifier/verb is necessary to suggest a Bool and IMO 
> >>>>> not a needless word.
> >>>>>
> >>>>> Regards,
> >>>>> Will Stanton
> >>>>>
> >>>>>> On Mar 31, 2017, at 11:28, Ben Cohen via swift-evolution 
> >>>>>>  wrote:
> >>>>>>
> >>>>>> Hopefully non-controversial, aside from the naming of the method and 
> >>>>>> arguments, about which controversy abounds
> >>>>>
> >>>>> ___
> >>>>> 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
> >>>>
> >>>>
> >>>>
> >>>> --
> >>>> Brandon
> >>>
> >>> ___
> >>> 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] [Pitch] Add an all algorithm to Sequence

[Rien via swift-evolution]

> On 02 Apr 2017, at 07:51, Karl Wagner via swift-evolution 
>  wrote:
> 
> Given the relationship to contains, why not keep it simple and go with:
> 
> onlyContains(_ element:)
> onlyContains(_ matching:)
> 
> [9, 9, 9, 9, 9].onlyContains(9) // true
> [1, 2, 3, 2, 3].onlyContains { $0 < 3 } // false
> 
> - Karl

IMO, we have a winner!

Rien.

> 
>> On 1 Apr 2017, at 10:47, Xiaodi Wu via swift-evolution 
>>  wrote:
>> 
>> On Sat, Apr 1, 2017 at 3:40 AM, David Hart via swift-evolution 
>>  wrote:
>> 
>> On 1 Apr 2017, at 09:50, Brandon Trussell  wrote:
>> 
>>> I agree that based on the method name, I thought a collection would be 
>>> returned.  
>> 
>> Now that I think more about it, I think you're right. It is confusing. 
>> Perhaps:
>> 
>> allAre(equalTo: )
>> allAre(matching: )
>> 
>> Well, if we're going to go full stdlib naming guidelines, shouldn't they be--
>> 
>> ```
>> areAll(equalTo:)
>> areAll(matching:)
>> ```
>> 
>>> On Sat, Apr 1, 2017 at 12:36 AM, David Hart via swift-evolution 
>>>  wrote:
>>> 
>>> 
>>> > On 1 Apr 2017, at 06:02, Will Stanton via swift-evolution 
>>> >  wrote:
>>> >
>>> > +1 to adding, but the name `all` suggests (to me) the return of another 
>>> > sequence, not a Bool.
>>> 
>>> I'm not too concerned because the mandatory labels makes it clear.
>>> 
>>> > Perhaps the function name should be question-like?
>>> >
>>> > Suggesting: `membersSatisfy(condition:)` or `allSatisfy(condition:)` or 
>>> > maybe even just `satisfies(condition:)`
>>> > The question-like modifier/verb is necessary to suggest a Bool and IMO 
>>> > not a needless word.
>>> >
>>> > Regards,
>>> > Will Stanton
>>> >
>>> >> On Mar 31, 2017, at 11:28, Ben Cohen via swift-evolution 
>>> >>  wrote:
>>> >>
>>> >> Hopefully non-controversial, aside from the naming of the method and 
>>> >> arguments, about which controversy abounds
>>> >
>>> > ___
>>> > 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
>>> 
>>> 
>>> 
>>> -- 
>>> Brandon
>> 
>> ___
>> 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] [Pitch] Cross-platform Swift TLS library

[Rien via swift-evolution]

Having just finished a client/server framework that builds on openSSL I 
sympathise with this proposal.

However, I wrote a few blogposts about my experiences with openSSL. And those 
leads me to believe that there is not much interest in secure networking. The 
number of hits on those posts are quite low (anaemic even) when compared to 
-for example- posts on socket programming.

While the sketch you made below does not sound too bad, I am afraid that the 
API will become complex so fast, that it will not be much easier to use than 
openSSL/LibreSSL etc. But don’t let that stop you ;-)

Regards,
Rien

PS: https://github.com/Balancingrock/SecureSockets


Site: http://balancingrock.nl
Blog: http://swiftrien.blogspot.com
Github: http://github.com/Balancingrock
Project: http://swiftfire.nl - A server for websites build in Swift






> On 06 Apr 2017, at 18:16, Gelareh Taban via swift-evolution 
>  wrote:
> 
> Hi all,
> 
> I’d like to pitch some of the ideas that have been discussed in the server 
> working group around security. 
> 
> To get more information on the server API group and its goals, see 
> https://swift.org/server-apis/. (TL;DR version is to come up with a set of 
> foundational APIs that work cross-platform, on all platforms supported by 
> Swift, including Linux.) 
> 
> For security, we have divided the scope into SSL/TLS support and crypto 
> support. Our first goal and the subject of this pitch is TLS. This current 
> pitch is the result of various discussions that have taken place over the 
> past several months over the server working group mailing list and several 
> projects by groups such as Vapor, IBM, Zewo, etc. 
> 
> Our plan is to start with the main ideas presented here and work on a Swift 
> library that we prototype and iterate on before finalizing on a specific 
> interface. Hopefully the ideas in this pitch are non-controversial, aside 
> from the naming of the method and protocols (which is widely accepted as a 
> `hard` problem).
> 
> # Problem
> 
> Since there is currently no standard Swift SSL/TLS library that is compatible 
> on both Apple and Linux, Swift projects use their TLS library of choice (such 
> as OpenSSL, LibreSSL, Security framework, etc). This results in:
> - fragmentation of the space as well as incompatibility of project 
> dependencies if more than one security package is needed by different modules 
> (a project cannot have both OpenSSL and LibreSSL in its dependency graph)
> - insecurity (using an unpatched or deprecated library such as OpenSSL on 
> macOS)
> - unmaintainablity (using non-standard or non-native libraries)
> - more complex code (using different APIs or code paths for each platform).
> 
> So we want to propose a standard set of protocols that define the behavior of 
> the TLS service and how the application and the server and networking layers 
> beneath it interact with the TLS service. What complicates this pitch is that 
> the Swift in server space is new and none of the interfaces have yet been 
> defined, so this is really a work in iteration.
> 
> # Design goals
> 
> We came up with the following design goals for a solution:
> 
> - Provide a consistent and unified Swift interface so that the developer can 
> write simple, cross-platform applications;
> - Don't implement new crypto functionality and instead use existing functions 
> in underlying libraries;
> - Plug-n-play architecture which allows the developer to decide on underlying 
> security library of choice, e.g., OpenSSL vs LibreSSL;
> - Library should be agnostic of the transport mechanism (e.g., socket, etc), 
> whilst allowing for both blocking and non-blocking connections;
> - Developers should be able to use the same TLS library for both client and 
> server applications.
> 
> 
> # Proposal
> 
> The proposed solution basically defines a number of protocols for each 
> interface:
> - Transport management
> - TLS management
> 
> A basic diagram that shows the relationship between the proposed protocols is 
> shown below:
> 
> (See attached file: TLSServiceArchitecture.png)
> 
> ![alt 
> text](https://raw.githubusercontent.com/gtaban/blogs/master/TLSServiceArchitecture.png
>  "Architecture of TLSService modules")
> 
> 
> The transport management protocol essentially would be a combination of a 
> connection object (e.g., a socket pointer, a file descriptor, etc) and a 
> connection type.
> 
> This is the connection object that gets passed to the implementation of the 
> TLS service protocol, which also handles the read and write callbacks to the 
> connection object.
> 
> The TLS service protocol would define a sets of methods that deal with TLS 
> setup (certificates, server/client, etc), and TLS events (such as receiving 
> data, encrypting and writing to connection object or reading from a 
> connection object, decrypting and returning the data).
> These methods are implemented by the TLS service which in turn uses its 
> choice of underlying security library. As an exa

Re: [swift-evolution] [Pitch] Cross-platform Swift TLS library

[Rien via swift-evolution]

I subscribed to the list, thanks.

I guess security is something people “want to look into later”… and then 
somehow never get to it.

Regards,
Rien

Site: http://balancingrock.nl
Blog: http://swiftrien.blogspot.com
Github: http://github.com/Balancingrock
Project: http://swiftfire.nl - A server for websites build in Swift






> On 06 Apr 2017, at 23:04, Gelareh Taban  wrote:
> 
> Hi Rien,
> 
> This is great, thanks for referencing your blogs/repo. I'll go through them.
> (An unfortunate issue I have found with security is that, we need it, we 
> expect it, but we don't want to worry about it :-)
> 
> The basic structure of what we are considering right now would to a large 
> extent follow that of 
> https://github.com/IBM-Swift/BlueSSLService/
> which invokes SecureTransport on Apple and OpenSSL on Linux. 
> 
> For more details of some of the discussions, just follow this thread.
> https://lists.swift.org/pipermail/swift-server-dev/Week-of-Mon-20170320/000298.html
> 
> Would love to have your contributions here! :-D
> 
> gelareh
> 
> 
> 
> 
> Rien ---04/06/2017 11:54:57 AM---Having just finished a 
> client/server framework that builds on openSSL I sympathise with this proposa
> 
> From: Rien 
> To: Gelareh Taban/Austin/IBM@IBMUS
> Cc: swift-evolution@swift.org
> Date: 04/06/2017 11:54 AM
> Subject: Re: [swift-evolution] [Pitch] Cross-platform Swift TLS library
> 
> 
> 
> 
> Having just finished a client/server framework that builds on openSSL I 
> sympathise with this proposal.
> 
> However, I wrote a few blogposts about my experiences with openSSL. And those 
> leads me to believe that there is not much interest in secure networking. The 
> number of hits on those posts are quite low (anaemic even) when compared to 
> -for example- posts on socket programming.
> 
> While the sketch you made below does not sound too bad, I am afraid that the 
> API will become complex so fast, that it will not be much easier to use than 
> openSSL/LibreSSL etc. But don’t let that stop you ;-)
> 
> Regards,
> Rien
> 
> PS: https://github.com/Balancingrock/SecureSockets
> 
> 
> Site: http://balancingrock.nl
> Blog: http://swiftrien.blogspot.com
> Github: http://github.com/Balancingrock
> Project: http://swiftfire.nl - A server for websites build in Swift
> 
> 
> 
> 
> 
> 
> > On 06 Apr 2017, at 18:16, Gelareh Taban via swift-evolution 
> >  wrote:
> > 
> > Hi all,
> > 
> > I’d like to pitch some of the ideas that have been discussed in the server 
> > working group around security. 
> > 
> > To get more information on the server API group and its goals, see 
> > https://swift.org/server-apis/. (TL;DR version is to come up with a set of 
> > foundational APIs that work cross-platform, on all platforms supported by 
> > Swift, including Linux.) 
> > 
> > For security, we have divided the scope into SSL/TLS support and crypto 
> > support. Our first goal and the subject of this pitch is TLS. This current 
> > pitch is the result of various discussions that have taken place over the 
> > past several months over the server working group mailing list and several 
> > projects by groups such as Vapor, IBM, Zewo, etc. 
> > 
> > Our plan is to start with the main ideas presented here and work on a Swift 
> > library that we prototype and iterate on before finalizing on a specific 
> > interface. Hopefully the ideas in this pitch are non-controversial, aside 
> > from the naming of the method and protocols (which is widely accepted as a 
> > `hard` problem).
> > 
> > # Problem
> > 
> > Since there is currently no standard Swift SSL/TLS library that is 
> > compatible on both Apple and Linux, Swift projects use their TLS library of 
> > choice (such as OpenSSL, LibreSSL, Security framework, etc). This results 
> > in:
> > - fragmentation of the space as well as incompatibility of project 
> > dependencies if more than one security package is needed by different 
> > modules (a project cannot have both OpenSSL and LibreSSL in its dependency 
> > graph)
> > - insecurity (using an unpatched or deprecated library such as OpenSSL on 
> > macOS)
> > - unmaintainablity (using non-standard or non-native libraries)
> > - more complex code (using different APIs or code paths for each platform).
> > 
> > So we want to propose a standard set of protocols that define the behavior 
> > of the TLS service and how the application and the server and networking 
> > layers beneath it interact with the TLS service. What complicates this 
> > pitch is that the Swift in server space is new and none of the interfaces 
> > have yet been defined, so this is really a work in iteration.
> > 
> > # Design goals
> > 
> > We came up with the following design goals for a solution:
> > 
> > - Provide a consistent and unified Swift interface so that the developer 
> > can write simple, cross-platform applications;
> > - Don't implement new crypto functionality and instead use existing 
> > functions in underlying libraries;
> > - Plug-n-play architecture which a

Re: [swift-evolution] [Draft] Package Manager Revised Dependency Resolution

[Rien via swift-evolution]

+ 1

> On 02 May 2017, at 00:00, Martin Waitz via swift-evolution 
>  wrote:
> 
> Hello,
> 
> Many of the listed package managers are for interpreted languages.
> So after fetching all dependencies, your package is completely usable. It is 
> „installed locally“.
> But Swift packages have to be compiled. You have to build them to be able to 
> use them.
> For me, ‚install' comes after compilation, not before.
> 
> Using ‚resolve‘ is thus a much better name for the proposed command.
> The verb ‚install‘ should only be used when it really installs the package in 
> some way.
> 

Absolutely. I struggle to see any value in “install” at all. “Resolve” feels 
much more natural.

Regards,
Rien

Site: http://balancingrock.nl
Blog: http://swiftrien.blogspot.com
Github: http://github.com/Balancingrock
Project: http://swiftfire.nl - A server for websites build in Swift

> — 
> Martin
>  
>> Am 01.05.2017 um 00:46 schrieb Jon Shier via swift-evolution 
>> :
>> 
>>  `install` only sounds like it should install things in the system if 
>> that’s the only type of manager you’ve ever used. If I’ve only ever used 
>> brew, of course I’ll assume that every other thing that calls itself a 
>> package manager will operate similarly. Thankfully, people learn quickly and 
>> it’s pretty easy to tell the difference between project package managers and 
>> system package mangers. Pretty much anyone developing on Apple platforms 
>> will be familiar with brew and CocoaPods  / bundler, all of which use the 
>> `install` verb, so following those would be an easy way to gain immediate 
>> familiarity. SPM really shouldn't be too different given that it will have 
>> to interoperate on systems with these tools, so choosing your own verbs 
>> would be far more confusing than using `install`. Carthage’s use of 
>> `bootstrap` is weird outlier that is always confusing to me. Plus, using 
>> `install`, allows you to use `.installed` for the file, which I think makes 
>> more sense than `.lock` or `.resolved`.
>>  A second issue is that `resolve` doesn’t sound like it installs 
>> anything at all. It sounds like a command that would just print the resolved 
>> versions of all my dependencies but do nothing else. 
>> 
>> 
>> 
>> Jon
>> 
>> 
>>> On Apr 30, 2017, at 12:06 AM, Rick Ballard via swift-evolution 
>>>  wrote:
>>> 
>>> Thanks for the feedback, David, and apologies for the slow reply. My 
>>> biggest reservation with the word "install" is that it really sounds like 
>>> it should install things into the system, or another shareable location, 
>>> instead of fetching dependencies into the dependency location for a single 
>>> top-level package. We might actually want to add a real "install" command 
>>> that does some type of installation some day in the future, though we might 
>>> also choose to forever leave that sort of thing to your system package 
>>> manager. And while there is some precedence for other package managers 
>>> using "install" to fetch dependencies, I think there's broader precedence 
>>> for it meaning to either install things into the system, or at least create 
>>> an installable "build root", with e.g. `make install`, `xcodebuild 
>>> install`, `brew install`, etc.
>>> 
>>> I just did a quick survey of the same package managers I surveyed 
>>> previously to see if they all used this term, and here's what I found:
>>> 
>>> yarn: `install`
>>> composer: `install`
>>> cargo: No true equivalent, just supprts `update` or `build`. Also, uses 
>>> `install` to mean something different – `cargo install` installs binary 
>>> packages only, to a installation root.
>>> bundler: `install`
>>> cocoapods: `install`
>>> glide: `install`
>>> pub: `get`
>>> mix: `deps.get`
>>> rebar3: `get-deps`
>>> carton: `install`
>>> carthage: `bootstrap`
>>> pip: Uses `install`, but since pip doesn't enforce the top-level-package 
>>> seperation of SwiftPM, Pip's use of `install` is actually more accurate.
>>> npm: `install`
>>> meteor: no true equivalent, just supports `update` or `build`
>>> 
>>> Given that this isn't a universal term, I think I'm comfortable going 
>>> against the flow a little bit if it means that we get to have clear and 
>>> accurate command-line verbs. But I think this is worth adding to the 
>>> "Alternatives Considered" section before we put this up for review!
>>> 
>>> - Rick
> 
> ___
> 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][Discussion] Deprecate Tuple Shuffles

[Rien via swift-evolution]

I think your misunderstanding helped a lot of people understand what is at 
issue here :-)

It did for me!

+1


Regards,
Rien

Site: http://balancingrock.nl
Blog: http://swiftrien.blogspot.com
Github: http://github.com/Balancingrock
Project: http://swiftfire.nl - A server for websites build in Swift






> On 05 May 2017, at 08:33, Adrian Zubarev via swift-evolution 
>  wrote:
> 
> I’m aware what a label is, I just had a small misunderstanding about nested 
> destructuring. ;-)
> 
> Issue solved for me.
> 
> let (a, b /* inner tuple */) = tuple
> 
> let (_, (x, y)) = tuple
> 
> +1 I don’t mind this change at all.
> 
> 
> 
> 
> -- 
> Adrian Zubarev
> Sent with Airmail
> 
> Am 5. Mai 2017 um 08:14:10, Xiaodi Wu (xiaodi...@gmail.com) schrieb:
> 
>> On Fri, May 5, 2017 at 1:12 AM, Adrian Zubarev 
>>  wrote:
>> Oh pardon, on the first glance I didn’t realized the issue with that example.
>> 
>> Here is an updated example that would work:
>> 
>> let (first, second: (x, y)): (first: Int, second: (x: Int, y: Int)) = tuple
>> 
>> This should work right?
>> 
>> No, again, this would be banned. You are using a label (a thing that ends in 
>> a colon) inside a tuple pattern (a thing between parenthesis that comes 
>> after "let").
>>  
>> It’s assigning the inner tuple to second while also creating two additional 
>> constants from the inner tuple. I know this is redundant and can be used as 
>> second.x, but this should work like right, because it’s nested tuple 
>> destructuring? If we’d use var instead of let then x would contain the value 
>> assigned from the inner tuple, but it would be completely independent from 
>> the new second tuple variable.
>> 
>> 
>> 
>> -- 
>> Adrian Zubarev
>> Sent with Airmail
>> 
>> Am 5. Mai 2017 um 08:04:07, Xiaodi Wu (xiaodi...@gmail.com) schrieb:
>> 
>>> let (first: a, second: (x: b, y: c)): (first: Int, second: (x: Int, y: 
>>> Int)) = tuple // fine, unaffected
>>> This would be banned. You are using labels (things ending with a colon) in 
>>> a pattern (the stuff that comes after the word "let").
>> 
> 
> ___
> 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][Discussion] Deprecate Tuple Shuffles

[Rien via swift-evolution]

> On 05 May 2017, at 09:31, Xiaodi Wu via swift-evolution 
>  wrote:
> 
> On Fri, May 5, 2017 at 2:28 AM, Adrian Zubarev 
>  wrote:
> I’m not arguing to remove all labels in Swift. Labels are great, this is a 
> fact for sure. The point I was trying to make is that labels in tuples how 
> either a meaning or not at all.
> 
> // This is a shortcut for the tuple type `(x: Int, y: Int)`
> let foo = (x: 0, y: 0)  
> 
> // In this case the labels are only used for description,  
> // they do not server any benefit here are most likely redundant
> let (x: x, y: y) = foo  
> 
> Labels elsewhere are a different story and I do support the cosmetic addition 
> Chris Lattner sketched out here: 
> https://lists.swift.org/pipermail/swift-evolution-announce/2016-July/000233.html
> 
> However this is about closures and not tuples, I don’t think this would 
> anyhow affect the removal of labels in tuple destructuring.
> 
> Plus I don’t see this to create an inconsistent in Swift, because as I 
> already said, labels in tuple destructuring are useless.
> 
> How come? I just illustrated their use. They help humans write correct code 
> by allowing the compiler to check an assertion that the human knows which 
> labels go with which positions in the tuple.

True, but the ability to define your own labels (instead of the API developer 
defining them for you) can make your code more readable. and hence maintainable.

Rien.

> ___
> 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][Discussion] Deprecate Tuple Shuffles

[Rien via swift-evolution]

> On 05 May 2017, at 09:59, Xiaodi Wu  wrote:
> 
> On Fri, May 5, 2017 at 2:56 AM, Rien  wrote:
> 
> > On 05 May 2017, at 09:31, Xiaodi Wu via swift-evolution 
> >  wrote:
> >
> > On Fri, May 5, 2017 at 2:28 AM, Adrian Zubarev 
> >  wrote:
> > I’m not arguing to remove all labels in Swift. Labels are great, this is a 
> > fact for sure. The point I was trying to make is that labels in tuples how 
> > either a meaning or not at all.
> >
> > // This is a shortcut for the tuple type `(x: Int, y: Int)`
> > let foo = (x: 0, y: 0)
> >
> > // In this case the labels are only used for description,
> > // they do not server any benefit here are most likely redundant
> > let (x: x, y: y) = foo
> >
> > Labels elsewhere are a different story and I do support the cosmetic 
> > addition Chris Lattner sketched out here: 
> > https://lists.swift.org/pipermail/swift-evolution-announce/2016-July/000233.html
> >
> > However this is about closures and not tuples, I don’t think this would 
> > anyhow affect the removal of labels in tuple destructuring.
> >
> > Plus I don’t see this to create an inconsistent in Swift, because as I 
> > already said, labels in tuple destructuring are useless.
> >
> > How come? I just illustrated their use. They help humans write correct code 
> > by allowing the compiler to check an assertion that the human knows which 
> > labels go with which positions in the tuple.
> 
> True, but the ability to define your own labels (instead of the API developer 
> defining them for you) can make your code more readable. and hence 
> maintainable.
> 
> I'm not sure I understand what you're suggesting here. Can you clarify?

In trying to explain, I discovered an error in my thinking… so please disregard.

Rien.

(Btw: Thanks for asking!)
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Proposal: Allow #if to guard switch case clauses

[Rien via swift-evolution]

I hope this makes it through without generating a lot of extra discussion. I 
would love to have this in Swift 4, or the next regular update of xcode.

Regards,
Rien

Site: http://balancingrock.nl
Blog: http://swiftrien.blogspot.com
Github: http://github.com/Balancingrock
Project: http://swiftfire.nl - A server for websites build in Swift






> On 10 May 2017, at 10:32, rintaro ishizaki via swift-evolution 
>  wrote:
> 
> Hi evolution community,
> 
> This proposal allows you to enclose switch cases with #if directive.
> Implementation: https://github.com/apple/swift/pull/9457
> This is one of the oldest SR issue:
> https://bugs.swift.org/browse/SR-2
> https://bugs.swift.org/browse/SR-4196
> 
> Thanks!
> Rintaro
> 
> 
> Allow #if to guard switch case clauses
> 
>   • Proposal: SE-
>   • Authors: Rintaro Ishziaki
>   • Review Manager: TBD
>   • Status: Awaiting review
> Introduction
> 
> This proposal adds ability to guard switch case clauses with #if directives.
> 
> Swift-evolution thread: Not yet
> 
> Motivation
> 
> When you want to switch cases only for certain compilation condition, say 
> switching #if os(Linux) guarded enum cases, right now you have to write 
> switch twice:
> 
> enum Operation
>  {
>   
> case output(String
> )
> #
> if os(Linux
> )
>   
> case syscall
> (Syscall)
> #
> endif
> 
> }
> 
> 
> func execute(operation
> : Operation) {
> #
> if !os(Linux
> )
>
> switch
>  operation {
>
> case .output(let str):
> 
>
> print
> (str)
>}
> #
> else
> 
>
> switch
>  operation {
>
> case .output(let str):
> 
>
> print
> (str)
>
> case .syscall(let call):
> 
>call.
> execute
> ()
>}
> #
> endif
> 
> }
> 
> This is annoying and error prone.
> 
> Proposed solution
> 
> This proposal allows #if to guard switch case clauses.
> 
> func execute(operation
> : Operation) {
> 
> switch
>  operation {
> 
> case .output(let str):
> 
> 
> print
> (str)
> #
> if os(Linux
> )
> 
> case .syscall(let call):
> 
> call.
> execute
> ()
> #
> endif
> 
> }
> }
> 
> Detailed design
> 
> This change shouldn't affect existing #if directives within case clauses. 
> This code should works as expected:
> 
> func foo(x
> : MyEnum) {
> 
> switch
>  x {
> 
> case .some(let str):
> 
> 
> doSomething
> (str)
> #
> if
>  PRINT_SOME
> 
> print
> (str)
> #
> endif
> 
> 
> case .other:
> 
> 
> doOther
> ()
> }
> }
> 
> Only if the next token after #if is case or default, the Parser treat it as 
> guarding case clauses.
> 
> func foo(x
> : MyEnum) {
> 
> switch
>  x {
> 
> case .some(let str):
> 
> 
> doSomething
> (str)
> #
> if
>  HAS_OTHER
> 
> case .other:
> 
> 
> doOther
> ()
> }
> #
> endif
> 
> }
> 
> func foo(x
> : MyEnum) {
> 
> switch
>  x {
> 
> case .some(let str):
> 
> 
> doSomething
> (str)
> #
> if
>  HAS_OTHER
> 
> default:
> 
> 
> break
> 
> #
> endif
> 
> }
> 
> Error cases:
> 
> switch
>  x {
> 
> case .some(let str):
> 
> 
> doSomething
> (str)
> #
> if
>  HAS_OTHER
> 
> case .other:
> 
> 
> doOther
> ()
> #
> else
> 
> 
> doMore() // error: all statements inside a switch must be covered by a 'case' 
> or 'default'
> #endif
> 
> }
> 
> switch
>  x {
> 
> case .some(let str):
> 
> 
> doSomething
> (str)
> #
> if
>  HAS_OTHER
> 
> doMore
> ()
> 
> case .other:
> 
> 
> doOther() // error: 'case' label can only appear inside a 'switch' statement
> #else
> 
> }
> 
> You can guard multiple cases as long as it is guarding whole clauses:
> 
> switch
>  x {
> 
> case .some(let str):
> 
> 
> doSomething
> (str)
> #
> if
>  HAS_OTHERS
> 
> case .other:
> 
> 
> doOther
> ()
> 
> case .more:
> 
> 
> doMore
> ()
> #
> else
> 
> }
> 
> 
> 
> ___
> 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-0178: Add unicodeScalars property to Character

[Rien via swift-evolution]

• What is your evaluation of the proposal?

+1


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

Its not a change but an extension to the language that feels entirely natural.


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

Yes, see above,

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


Not really, as the String type in swift is fairly complex. However I have done 
a fair bit of string parsing, and this change will make string parsing easier 
and more like ascii-string parsing.


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

Quick reading. It does not seem very complicated.

Regards,
Rien

Site: http://balancingrock.nl
Blog: http://swiftrien.blogspot.com
Github: http://github.com/Balancingrock
Project: http://swiftfire.nl - A server for websites build in Swift






> On 12 May 2017, at 22:41, Ted Kremenek via swift-evolution 
>  wrote:
> 
> Hello Swift community,
> 
> The review of SE-0178: Add unicodeScalars property to Character begins now 
> and runs through May 17, 2017.
> 
> The proposal is available here:
> 
> 
> https://github.com/apple/swift-evolution/blob/master/proposals/0178-character-unicode-view.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/0178-character-unicode-view.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:
> 
> More information about the Swift evolution process is available at:
> 
> https://github.com/apple/swift-evolution/blob/master/process.md
> 
> Thank you,
> Ted (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] Swift run Command

[Rien via swift-evolution]

I always wondered why it did not exist already ;-)

However, I am not sure if I like the “auto build” aspect. For example I may 
have started working on a change, but quickly want to verify the exact old 
behaviour. Then I want to run the old build again. While this proposal does not 
make this impossible, it makes it more cumbersome as I now need to remember 
when to use the old method and the new run command.

Having a build option would make more sense imo, i.e:
$ swift run 
Always runs the present build
$ swift run -b
Builds first, then runs the new build.


Regards,
Rien

Site: http://balancingrock.nl
Blog: http://swiftrien.blogspot.com
Github: http://github.com/Balancingrock
Project: http://swiftfire.nl - A server for websites build in Swift






> On 15 May 2017, at 09:47, David Hart via swift-evolution 
>  wrote:
> 
> Hello evolution (and build-dev),
> 
> I’d like to pitch a QOL proposal to improve the development of command-line 
> Swift Packages by introducing a `swift run` command. I’d value any feedback 
> before moving forward.
> 
> https://github.com/hartbit/swift-evolution/blob/swift-run-command/proposals/-swift-run-command.md
> 
> Regards,
> David.
> 
> Swift run Command
> 
>   • Proposal: SE-
>   • Authors: David Hart
>   • Review Manager: TBD
>   • Status: TBD
> Introduction
> 
> The proposal introduces a new swift run command to build and run an 
> executable defined in the current package.
> 
> Motivation
> 
> It is common to want to build and run an executable during development. For 
> now, one must first build it and then execute it from the build folder:
> 
> $ swift build
> $ .build/debug/myexecutable
> 
> In Swift 4, the Swift Package Manager will build to a different path, 
> containing a platform sub-folder (.build/macosx-x86_64/debug for mac and 
> .build/linux-x86_64/debug for linux), making it more cumbersome to run the 
> executable from the command line.
> 
> To improve the development workflow, the proposal suggest introducing a new 
> first-level swift run command that will build if necessary and then run an 
> executable defined in the Package.swift manifest, replacing the above steps 
> into just one.
> 
> Proposed solution
> 
> The swift run command would be defined as:
> 
> $ swift run --help
> OVERVIEW: Build and run executable
> 
> USAGE: swift run [options] [executable] [-- arguments]
> 
> OPTIONS:
>   --build-pathSpecify build/cache directory [default: ./.build]
>   --chdir, -C Change working directory before any other operation
>   --in-dir, -IChange working directory before running the 
> executable
>   --color Specify color mode (auto
> |always|
> never) [default: auto]
>   --configuration, -c Build with configuration (debug
> |
> release) [default: debug]
>   --enable-prefetchingEnable prefetching 
> in
>  resolver
>   --skip-buildSkip building the executable product
>   --verbose, -v   Increase verbosity of informational output
>   -XccPass flag through to all C compiler invocations
>   -XlinkerPass flag through to all linker invocations
>   -XswiftcPass flag through to all Swift compiler invocations
>   --help  Display available options
> 
> If needed, the command will build the product before running it. As a result, 
> it can be passed any options swift buildaccepts. As for swift test, it also 
> accepts an extra --skip-build option to skip the build phase. A new 
> --in-diroption is also introduced to run the executable from another 
> directory.
> 
> After the options, the command optionally takes the name of an executable 
> product defined in the Package.swiftmanifest and introduced in SE-0146. If 
> called without an executable and the manifest defines one and only one 
> executable product, it will default to running that one. In any other case, 
> the command fails.
> 
> The executable can be called with arguments by prefixing them with a -- to 
> separate them from the executable name.
> 
> Alternatives considered
> 
> One alternative to the Swift 4 change of build folder would be for the Swift 
> Package Manager to create and update a symlink at .build/debug and 
> .build/release that point to the latest build folder for that configuration. 
> Although that should probably be done to retain backward-compatibility with 
> tools that depended on the build location, it does not completely invalid the 
> usefulness of the run command.
> ___
> 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] Swift run Command

[Rien via swift-evolution]

> On 15 May 2017, at 10:12, David Hart  wrote:
> 
> 
>> On 15 May 2017, at 10:03, Rien  wrote:
>> 
>> I always wondered why it did not exist already ;-)
>> 
>> However, I am not sure if I like the “auto build” aspect. For example I may 
>> have started working on a change, but quickly want to verify the exact old 
>> behaviour. Then I want to run the old build again. While this proposal does 
>> not make this impossible, it makes it more cumbersome as I now need to 
>> remember when to use the old method and the new run command.
> 
> There is a —skip-build option to run without building. I think it’s better 
> this way before (1) building before running seems like the most common 
> scenario and (2) it mirrors how it works with swift test. Having it work the 
> other way round for run would be very confusing IMHO.

To me this violates the “least surprising use” rule. (Same for ‘test’, even 
though it sets a precedence)
Command line execution should either do as it says, or give an error message. 
This is quite different from a GUI behaviour: a GUI ‘run’ command should build 
if necessary - and indeed Xcode does just that) 
I think it’s a mistake to try to mimic GUI behaviour in a command line 
environment.

Regards,
Rien.

> 
>> Having a build option would make more sense imo, i.e:
>> $ swift run 
>> Always runs the present build
>> $ swift run -b
>> Builds first, then runs the new build.
>> 
>> 
>> Regards,
>> Rien
>> 
>> Site: http://balancingrock.nl
>> Blog: http://swiftrien.blogspot.com
>> Github: http://github.com/Balancingrock
>> Project: http://swiftfire.nl - A server for websites build in Swift
>> 
>> 
>> 
>> 
>> 
>> 
>>> On 15 May 2017, at 09:47, David Hart via swift-evolution 
>>>  wrote:
>>> 
>>> Hello evolution (and build-dev),
>>> 
>>> I’d like to pitch a QOL proposal to improve the development of command-line 
>>> Swift Packages by introducing a `swift run` command. I’d value any feedback 
>>> before moving forward.
>>> 
>>> https://github.com/hartbit/swift-evolution/blob/swift-run-command/proposals/-swift-run-command.md
>>> 
>>> Regards,
>>> David.
>>> 
>>> Swift run Command
>>> 
>>> • Proposal: SE-
>>> • Authors: David Hart
>>> • Review Manager: TBD
>>> • Status: TBD
>>> Introduction
>>> 
>>> The proposal introduces a new swift run command to build and run an 
>>> executable defined in the current package.
>>> 
>>> Motivation
>>> 
>>> It is common to want to build and run an executable during development. For 
>>> now, one must first build it and then execute it from the build folder:
>>> 
>>> $ swift build
>>> $ .build/debug/myexecutable
>>> 
>>> In Swift 4, the Swift Package Manager will build to a different path, 
>>> containing a platform sub-folder (.build/macosx-x86_64/debug for mac and 
>>> .build/linux-x86_64/debug for linux), making it more cumbersome to run the 
>>> executable from the command line.
>>> 
>>> To improve the development workflow, the proposal suggest introducing a new 
>>> first-level swift run command that will build if necessary and then run an 
>>> executable defined in the Package.swift manifest, replacing the above steps 
>>> into just one.
>>> 
>>> Proposed solution
>>> 
>>> The swift run command would be defined as:
>>> 
>>> $ swift run --help
>>> OVERVIEW: Build and run executable
>>> 
>>> USAGE: swift run [options] [executable] [-- arguments]
>>> 
>>> OPTIONS:
>>>  --build-pathSpecify build/cache directory [default: ./.build]
>>>  --chdir, -C Change working directory before any other operation
>>>  --in-dir, -IChange working directory before running the 
>>> executable
>>>  --color Specify color mode (auto
>>> |always|
>>> never) [default: auto]
>>>  --configuration, -c Build with configuration (debug
>>> |
>>> release) [default: debug]
>>>  --enable-prefetchingEnable prefetching 
>>> in
>>> resolver
>>>  --skip-buildSkip building the executable product
>>>  --verbose, -v   Increase verbosity of informational output
>>>  -XccPass flag through to all C compiler invocations
>>>  -XlinkerPass flag through to all linker invocations
>>>  -XswiftcPass flag through to all Swift compiler invocations
>>>  --help  Display available options
>>> 
>>> If needed, the command will build the product before running it. As a 
>>> result, it can be passed any options swift buildaccepts. As for swift test, 
>>> it also accepts an extra --skip-build option to skip the build phase. A new 
>>> --in-diroption is also introduced to run the executable from another 
>>> directory.
>>> 
>>> After the options, the command optionally takes the name of an executable 
>>> product defined in the Package.swiftmanifest and introduced in SE-0146. If 
>>> called without an executable and the manifest defines one and only one 
>>> executable product, it will default to running that one. In any other case, 
>>> the command fa

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

[Rien via swift-evolution]

> On 15 May 2017, at 11:58, David Hart  wrote:
> 
>> 
>> On 15 May 2017, at 10:40, Rien  wrote:
>> 
>> 
>>> On 15 May 2017, at 10:12, David Hart  wrote:
>>> 
>>> 
 On 15 May 2017, at 10:03, Rien  wrote:
 
 I always wondered why it did not exist already ;-)
 
 However, I am not sure if I like the “auto build” aspect. For example I 
 may have started working on a change, but quickly want to verify the exact 
 old behaviour. Then I want to run the old build again. While this proposal 
 does not make this impossible, it makes it more cumbersome as I now need 
 to remember when to use the old method and the new run command.
>>> 
>>> There is a —skip-build option to run without building. I think it’s better 
>>> this way before (1) building before running seems like the most common 
>>> scenario and (2) it mirrors how it works with swift test. Having it work 
>>> the other way round for run would be very confusing IMHO.
>> 
>> To me this violates the “least surprising use” rule. (Same for ‘test’, even 
>> though it sets a precedence)
>> Command line execution should either do as it says, or give an error 
>> message. This is quite different from a GUI behaviour: a GUI ‘run’ command 
>> should build if necessary - and indeed Xcode does just that) 
>> I think it’s a mistake to try to mimic GUI behaviour in a command line 
>> environment.
> 
> Firstly, there are other precedents. swift build itself will get dependencies 
> if needed. In cargo, the closest equivalent to SwiftPM (i.e., a package 
> manager/build tool for a language that needs a compilation stage) cargo run 
> builds beforehand.
> 
> Secondly, if we agree that building before running is the most common 
> scenario, why not make it the default?
> 

I am not familiar with Cargo.
But pretty much any example you can site is something I dislike ;-)
On the command line I like single-purpose commands since that makes creating 
and understanding scripts easier.
Maybe that is just me…

Rien.

> David.
> 
>> Regards,
>> Rien.
>> 
>>> 
 Having a build option would make more sense imo, i.e:
 $ swift run 
 Always runs the present build
 $ swift run -b
 Builds first, then runs the new build.
 
 
 Regards,
 Rien
 
 Site: http://balancingrock.nl
 Blog: http://swiftrien.blogspot.com
 Github: http://github.com/Balancingrock
 Project: http://swiftfire.nl - A server for websites build in Swift
 
 
 
 
 
 
> On 15 May 2017, at 09:47, David Hart via swift-evolution 
>  wrote:
> 
> Hello evolution (and build-dev),
> 
> I’d like to pitch a QOL proposal to improve the development of 
> command-line Swift Packages by introducing a `swift run` command. I’d 
> value any feedback before moving forward.
> 
> https://github.com/hartbit/swift-evolution/blob/swift-run-command/proposals/-swift-run-command.md
> 
> Regards,
> David.
> 
> Swift run Command
> 
>   • Proposal: SE-
>   • Authors: David Hart
>   • Review Manager: TBD
>   • Status: TBD
> Introduction
> 
> The proposal introduces a new swift run command to build and run an 
> executable defined in the current package.
> 
> Motivation
> 
> It is common to want to build and run an executable during development. 
> For now, one must first build it and then execute it from the build 
> folder:
> 
> $ swift build
> $ .build/debug/myexecutable
> 
> In Swift 4, the Swift Package Manager will build to a different path, 
> containing a platform sub-folder (.build/macosx-x86_64/debug for mac and 
> .build/linux-x86_64/debug for linux), making it more cumbersome to run 
> the executable from the command line.
> 
> To improve the development workflow, the proposal suggest introducing a 
> new first-level swift run command that will build if necessary and then 
> run an executable defined in the Package.swift manifest, replacing the 
> above steps into just one.
> 
> Proposed solution
> 
> The swift run command would be defined as:
> 
> $ swift run --help
> OVERVIEW: Build and run executable
> 
> USAGE: swift run [options] [executable] [-- arguments]
> 
> OPTIONS:
> --build-pathSpecify build/cache directory [default: ./.build]
> --chdir, -C Change working directory before any other 
> operation
> --in-dir, -IChange working directory before running the 
> executable
> --color Specify color mode (auto
> |always|
> never) [default: auto]
> --configuration, -c Build with configuration (debug
> |
> release) [default: debug]
> --enable-prefetchingEnable prefetching 
> in
> resolver
> --skip-buildSkip building the executable product
> --verbose, -v   Increase verbosity o

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

[Rien via swift-evolution]

While I’d like a fixed size array, I’d agree with Rod that this looks odd.

Myself I use the name ‘array’ a lot in places where I get/need a temporary 
array that lives for a few lines only. So I am against using the keyword 
‘array’.

A name like SizedArray would seem more in-line with other Swift types.

Also, there is a standard way of looking up indicies, and it uses the ‘[]’ 
signs. Why did you drop that?
I would expect confusion when looking up a variable index like: let c = 
x.myIndex
let c = x[myIndex] looks decidedly more clear to me.

Btw, what to think of:

var z: array 2 of Array

(that looks pretty horrible to me)

Regards,
Rien

Site: http://balancingrock.nl
Blog: http://swiftrien.blogspot.com
Github: http://github.com/Balancingrock
Project: http://swiftfire.nl - A server for websites build in Swift






> On 29 May 2017, at 08:37, Daryle Walker via swift-evolution 
>  wrote:
> 
> Static-Sized Arrays
> This is a new proposed syntax for handling array types whose size is fixed at 
> compile time. This is a classic kind of type that's still missing in Swift.
> 
> Like the built-in processor numeric types are mapped to special struct types, 
> any built-in vector types should be mapped to special array types. There 
> should be some sort of construct to allow parallel visitation of elements.
> 
> For a given array type A with an element type B, we have strideof(A) == COUNT 
> * strideof(B), where COUNT is the number of elements in the array, which is 
> the product of the lengths along each dimension. (A zero-dimension array has 
> an element count of one.)
> 
> New Keywords
>   • array
>   • of
> These keywords should be conditional if possible. The of shouldn't appear 
> without following an array, so of should be easy to make conditional.
> 
> Immediate Arrays
> Immediate arrays are a new kind of compound type. They have value semantics.
> 
> let x: array 3 of Int = [1, 2, 3]
> var y: array 2 of array 5 of Double
> 
> Hopefully, this is simpler than my last proposal. I'm thinking that "array" 
> is like a verb here.
> 
> The element type is at the end, so no parentheses (or similar) are needed. 
> The syntax is easy to expand for nested array types. Here, the extents go 
> from the widest span to the narrowest, like nested arrays in C. The inner 
> element type is at the end instead of the start.
> 
> assert(x.0 == 1)
> x.3 = 3  // ERROR!
> y.1.3 = 3
> y.0 = [-3, -2, -1, 0, +1]
> 
> Elements are addressed just like in tuples.
> 
> Nominal Arrays
> Nominal arrays are a new kind of named type. They have value semantics.
> 
> array MyArray: (0..<6) of Int {
> /* ... */
> }
> 
> I'm thinking "array" is like an adjective (or noun) here. The 
> base-and-protocol list must have a shape specifier as its first item.
> 
> shape-specifier → ( extents-list_opt ) of type
> 
> extents-list → extent
> 
> extents-list → extent , extents-list
> 
> extent → type storage-rank_opt
> 
> extent → expression ..< expression storage-rank_opt
> 
> extent → expression ... expression storage-rank_opt
> 
> storage-rank → : expression
> A type used for an extent:
> 
>   • Must be a raw-value enumeration type.
>   • The raw-value type must be one of the default integer types.
>   • There must be at least one case, and all the cases must form a 
> contiguous range of values.
> A range used for an extent:
> 
>   • Must use for its boundary type either:
>   • a default integer type, or
>   • an enumeration type that could qualify as an extent type.
>   • Must be a valid range with at least one element.
> The expression for a storage rank must evaluate to a compile-time integer 
> value that is at least zero and less than the number of extents. An extent 
> without an explicit storage rank gets one equal to the smallest valid value 
> yet unused. (Multiple extents without explicit ranks are finalized in lexical 
> order.)
> 
> The extent with the largest storage rank has elements with adjacent indexes 
> (assuming all other extents use fixed indexes) placed adjacent in memory. The 
> extent with storage rank 0 have elements with adjacent indexes (assuming all 
> other extents use fixed indexes) the furthest span apart in memory.
> 
> The total number of elements for the array is the product of the lengths of 
> the extents. A zero-dimension array has a singular element.
> 
> A nominal array type can have type-level members and computed instance-level 
> properties, just like the other named types. The initial set of members, if 
> not overridden, are:
> 
>   • A type-alias Element that refers to the element type.
>   • A type-alias Index that refers to a tuple composed of the extent 
> types. For a range-based extent, the corresponding type is its boundary type.
>   • If the element type is default-initializable, a default initializer.
>   • An initializer that takes as its only parameter an Element, which is 
> copied to each element.
>   • An initia

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

[Rien via swift-evolution]

I don’t like this, it violates the locality principle. I.e. that all 
information that is needed to understand something is close by.

But since it is not something that everybody has to use… I don’t object to it 
either.

Regards,
Rien

Site: http://balancingrock.nl
Blog: http://swiftrien.blogspot.com
Github: http://github.com/Balancingrock
Project: http://swiftfire.nl - An HTTP(S) web server framework in Swift







> On 17 Jun 2017, at 23:48, Ted F.A. van Gaalen via swift-evolution 
>  wrote:
> 
> (I am not sure if I should tag this subject with [pitch]? ) 
> 
> Please don’t worry , I am not attempting to start a new
> and infinite thread about whether or not the way scope
> is handled in Swift is imho correct or not.
> Errhm well, apart from that “protected” is missing,
> but please let us not start again.. :o) 
> 
> No, it is more or less a convenience solution to
> prevent unnecessary wear and tear to the following keys
> on my keyboard: [ A,E, I, P,  R, T, V]
> 
> I prefer it, not to expose those class or struct members
> which should not be accessible outside the class or struct
> 
> Currently, to prevent access to private Items,
> I have to type the word “private” too many times:
> 
> class  House
> {
> private var rooms = 5
>   private var roofTiles = 11201
>   private let paint =   UIColor.Blue;
> private var yearTax: Money = “323,56"
> private let garageVolume = 60.0
> 
> init(..) {.. }
> 
>  private func calculateTax() {...}
> 
>  public func roomsUnoccupied() -> Int {…}
> 
> func roofData(……) {…}
> 
>  private func  a{…} 
> }
> 
> To set the scope of a list of members I suggest the
> “in-line scope modifiers”  (anyone with a better name for it?) 
> 
> For example if one has a source line containing the word
> “private:” then all the following member declarations will
> be “private” until another inline scope modifier is encountered
> with one “default scope” to escape from it. like in the following example”
> 
> The compiler can detect that it is an inline scope modifier, because it ends 
> with a colon
> 
> “Normal” scope modifiers, that is the ones which precede the member’s name 
> directly should imho not be allowed within such a scope block.
> unless they would override for that specific item, but that looks ugly. 
> 
> getter & setters and init should appear in default scope
> (or with no in-line scope modifiers)
> 
> Inline scope modifiers can be specified as often as
> desired and in arbitrary sequence. 
> 
> 
> class  House
> {
>  init(..) {.. }
> private:// <——  In-line scope 
> modifier all following declarations are private here.
> var rooms = 5
>   var roofTiles = 11201
>   let paint =   UIColor.Blue;
> var yearTax: Money = “323,56"
> func calculateTax() {…}
> func  a{…} 
> 
>   public: // <——  In-line 
> scope modifier
>  var garageVolume = 60.0  
>  func roomsUnoccupied() -> Int {…}
>  func roofData(……) {…}
> 
>   defaultscope: // <—— Return to default 
> scope (only needed when preceding inline scope modifiers are present. )
>  
>   func sellHouse(buyer: CustomerID)   
> }
> 
> See? looks a lot better, don’t you think so?  
> it also makes sources more readable because one can 
> now conveniently group items.
> 
> 100% source compatible with whatever scope 
> mechanism now or in the future is or will be deployed.
> 
> 
> (The idea is not exactly new, a similar construct is available in Object 
> Pascal.)  
> 
> ?
> 
> Kind Regards
> TedvG
> 
> 
> 
> 
> 
> 
>  
> ___
> 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] Introducing the "Unwrap or Die" operator to the standard library

[Rien via swift-evolution]

I would not use it.
Somehow it gives me the creeps to leave something like ‘fatalError’ in a 
shipping application.
During development it could make sense, but then again I like to keep 
development and shipping the same as much as possible.

Regards,
Rien

Site: http://balancingrock.nl
Blog: http://swiftrien.blogspot.com
Github: http://github.com/Balancingrock
Project: http://swiftfire.nl - An HTTP(S) web server framework in Swift







> On 27 Jun 2017, at 19:16, Erica Sadun via swift-evolution 
>  wrote:
> 
> Using an operator to provide feedback on the context of a failed unwrap has 
> become a commonly implemented approach in the Swift developer Community. What 
> are your thoughts about adopting this widely-used operator into the standard 
> library?
> 
> guard !lastItem.isEmpty else { return }
> let lastItem = array.last !! "Array must be non-empty"
> 
> Details here:  https://gist.github.com/erica/423e4b1c63b95c4c90338cdff4939a9b
> 
> Thank you for your thoughtful feedback, -- 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] [Meta] Let's talk TouchBar + Unicode

[Rien via swift-evolution]

> On 29 Oct 2016, at 04:22, Xiaodi Wu via swift-evolution 
>  wrote:
> 
> The other has to do with expanding Swift standard library and core library 
> APIs beyond the ASCII character set. I'm -1 on that for the reasons I've 
> outlined above. Reworded, a very good reason to limit the standard library 
> itself to ASCII APIs is the same reason we limit the library to (a restricted 
> subset of) U.S. English. We do not all share a common first language or 
> recognize the same characters, but these are reasonable common denominators 
> with historical precedent in computer science *and* reasonably wide 
> international recognition.

+1, Well said.


Regards,
Rien

Site: http://balancingrock.nl
Blog: http://swiftrien.blogspot.com
Github: http://github.com/Swiftrien
Project: http://swiftfire.nl




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

Re: [swift-evolution] guard let x = x

[Rien via swift-evolution]

+1

Can “unwrap” be used anywhere else?
If not, why not remove the “guard” altogether?
I.e.

unwrap foobar else { … }

Regards,
Rien

Site: http://balancingrock.nl
Blog: http://swiftrien.blogspot.com
Github: http://github.com/Swiftrien
Project: http://swiftfire.nl




> On 29 Oct 2016, at 00:34, Erica Sadun via swift-evolution 
>  wrote:
> 
> 
>> On Oct 26, 2016, at 11:39 AM, Chris Lattner via swift-evolution 
>>  wrote:
>> 
>> 
>>> On Oct 26, 2016, at 10:23 AM, Joshua Alvarado  
>>> wrote:
>>> 
>>> In your example the keyword only makes sense if you are shadowing the 
>>> optional variable. How would unwrap work with a different name?
>> 
>> It wouldn’t: “unwrap” would never include an equal sign.  If you want to do 
>> that, use a standard "if let”.
>> 
>> -Chris
> 
> So I can stop thinking about this. Gist is here: 
> https://gist.github.com/erica/db9ce92b3d23cb20799460f603c0ae7c
> 
> -- E
> 
> 
> Introducing unwrap
> 
>   • Proposal: TBD
>   • Author: Erica Sadun, Chris Lattner, David Goodine
>   • Status: TBD
>   • Review manager: TBD
> Introduction
> 
> This proposal introduces unwrap, simplifying common shadowing and allowing a 
> unified syntax for one-item associated values such as Result types.
> 
> Swift-evolution thread: guard let x = x
> 
> Motivation
> 
> Swift lacks a unified, safe way to bind an optional or single-value 
> enumeration to a shadowed varaiable that is guaranteed to be the same name. 
> Introducing unwrap ensures the conditionally bound item does not accidentally 
> shadow any other item. 
> 
> Compare:
> 
> guard let foobar = foobar else { …
>  }
> 
> guard unwrap foobar else { … }
> Using unwrap eliminates repetition ("foobar = foobar" fails DRY principles) 
> and retains clarity. The keyword is common, simple to understand, and easy to 
> search for if Swift users are unfamiliar with it.
> 
> This syntax simplifies one-item associated value enumerations by offering a 
> common syntax. Compare:
> 
> enum Result { case success(T), error(Error
> ) }
> 
> 
> guard case let .success(value) = result else { ...
>  }
> 
> guard unwrap result else { ... }
> In the latter case result is bound to the wrapped value. Again, it is simpler 
> and clearer, even with non-Optional types.
> 
> Detailed Design
> 
> unwrap can be used with any one-value enumeration. The unwrapped value is 
> bound to the same symbol as the associated type.
> 
> enum TypeName { case anycase(T), anothercase(U) }
> 
> // First and second are type `TypeName`
> let first = TypeName.anyCase(value1)
> let second = TypeName. anothercase(value2)
> 
> guard unwrap first else { ... }
> // first is now shadowed as type T
> 
> guard unwrap second else { ... }
> // second is now shadowed as type U
> 
> Impact on Existing Code
> 
> This change is additive and has no impact on existing code other than 
> intentional refactoring.
> 
> Timeline
> 
> This proposal is additive and not suited for consideration until Swift 4 
> phase 2
> 
> Alternatives Considered
> 
>   • Using a bind keyword. Past discussions were held in the first week of 
> February 2016.
>   • Fixing pattern matching grammar
>   • Not using this approach
> 
> ___
> 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] [Meta] Let's talk TouchBar + Unicode

[Rien via swift-evolution]

> 
> Swift is a language being designed for the next 20-30 years, we shouldn’t be 
> limiting ourselves based on technology that is already being replaced (as you 
> mentioned many of the devices people use everyday already have a soft 
> keyboard… and Ive said the TouchBar was just the beginning of a new 
> direction).  We need to aim for where the puck is going to be…
> 

Hmm, I have engineering problems today. There will be engineering problems in 
20 and 30 years as well, but I rather have a tool that is geared towards 
today’s problems. It would be even better if that tool is flexible enough so 
that it can adapt to the requirements as they change.

The difference between a puck and the future of engineering is that you can 
make a very good prediction about where a puck is going to be based on 
direction and speed. It is completely impossible to predict where the future of 
programming is going to be in 20 years time.

Let Swift be a flexible tool, don’t write anything in stone, and don’t try to 
predict the future.
If requirements change, let Swift change. But don’t try to be 20 years ahead of 
what we need today.

Regards,
Rien

Site: http://balancingrock.nl
Blog: http://swiftrien.blogspot.com
Github: http://github.com/Swiftrien
Project: http://swiftfire.nl




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

Re: [swift-evolution] guard let x = x

[Rien via swift-evolution]

If using “unwrap” in itself, then it should be statement that only unwraps, 
hence the

Regards,
Rien

Site: http://balancingrock.nl
Blog: http://swiftrien.blogspot.com
Github: http://github.com/Swiftrien
Project: http://swiftfire.nl




> On 02 Nov 2016, at 02:47, Dany St-Amant via swift-evolution 
>  wrote:
> 
> 
>> Le 31 oct. 2016 à 17:44, Erica Sadun via swift-evolution 
>>  a écrit :
>> 
>> 
>>> On Oct 31, 2016, at 1:51 PM, Xiaodi Wu via swift-evolution 
>>>  wrote:
>>> 
>>> An alternative that would seem to satisfy some objections is to have a 
>>> distinct "unwrap" statement--as in: "unwrap x else { ... }".
>> 
>> I'd be against this alternative as it is doing the work of a guard statement 
>> (including the "must exit scope" rule) with a new keyword and unneeded 
>> redundancy.
>> 
>> Adding "unwrap" is local. It performs one very common task with added safety 
>> (avoids unintended shadow effects) and introduces succinctness and clarity. 
>> In other words, it is a highly focused changed with a measurable benefit in 
>> use.
>> 
>> Compare:
>> 
>> * "Introduce the unwrap statement that acts like guard but is limited to 
>> optionals" creates unnecessary language verbosity.
>> 
>> * "guard x else ", meaning "treat optional values differently than all other 
>> items in a conditional list", fails because it obscures rather than adds 
>> intent. Worse, it would lead to issues with Boolean optionals whose wrapped 
>> value is later used within the same condition.
>> 
>> Xiaodi, you mentioned an alternative approach and I'd love a peek at what 
>> that is.
> 
> Also with the 'guard unwrap', the following code make sense:
> 
> guard unwrap x, x == 10 else { return }
> 
> With a lone unwrap it would not.
> 
> unwrap x, x == 10 else { return }
> 
> I personally do not like shadowing, but a standalone 'unwrap!' could be of 
> interest to those loving life in the shadows. Beside the shadowing itself, it 
> should not be any worst than any of the other '!' usage. The feasibility of 
> such depends of course on how the compiler manages its variable scoping.
> 
> On further thought, if we were to make the, sorry bad word coming, 
> code-breaking change to disallow legacy shadowing 'let x=x' and force the 
> shadowing to be done exclusively via this 'unwrap' keyword, it could make it 
> easier for projects/companies to ban shadowing.
> 
> Dany
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

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

Re: [swift-evolution] guard let x = x

[Rien via swift-evolution]

Please ignore, the mail was sent in error.

> On 02 Nov 2016, at 07:13, Rien via swift-evolution 
>  wrote:
> 
> If using “unwrap” in itself, then it should be statement that only unwraps, 
> hence the
> 
> Regards,
> Rien
> 
> Site: http://balancingrock.nl
> Blog: http://swiftrien.blogspot.com
> Github: http://github.com/Swiftrien
> Project: http://swiftfire.nl
> 
> 

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

Re: [swift-evolution] [Proposal] Type Narrowing

[Rien via swift-evolution]

> On 09 Nov 2016, at 07:51, David Hart via swift-evolution 
>  wrote:
> 
> 
>> On 3 Nov 2016, at 20:23, Nevin Brackett-Rozinsky via swift-evolution 
>>  wrote:
>> 
>> This looks like a lot of complexity for very little gain.
>> 
>> Aside from any implementation concerns, this proposal substantially 
>> increases the cognitive load on developers. To figure out what a piece of 
>> code means, someone reading it will have to mentally keep track of a “type 
>> stack” for every variable. That is the opposite of “clarity at the point of 
>> use”.
> 
> Very well said. I think this is perhaps the number one complaint I have about 
> the proposal.

Exactly.
-1.


Regards,
Rien

Site: http://balancingrock.nl
Blog: http://swiftrien.blogspot.com
Github: http://github.com/Swiftrien
Project: http://swiftfire.nl




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

Re: [swift-evolution] [Proposal] Type Narrowing

[Rien via swift-evolution]

> On 09 Nov 2016, at 10:51, Haravikk via swift-evolution 
>  wrote:
> 
> 
>> On 8 Nov 2016, at 12:22, ilya  wrote:
>> 
>> (1) You can define different methods with the same name on T and Optional 
>> (description is such an example). Then what does this do?
>> 
>> // someMethod is defined both for T and T?
>> // var foo: T?
>> if foo != nil {
>> foo.someMethod()
>> }
>> 
>> I say there is a clear expectation that foo.someMethod() should call the 
>> method of T?, even inside the if block, since this is how the dot works. 
>> However, according to the proposal it will call another method (or become an 
>> error?).
>> 
>> I think the languages that use optional narrowing are the ones where T? is 
>> not a separate type, so that it cannot have its own methods.
> 
> Hmm, that is definitely a wrinkle in the plan; it's very much an edge case 
> (someone defining something on optionals that they probably shouldn't) but 
> not an easy one to resolve. I suppose I'll have to amend the proposal to 
> suggest type widening in that case, such that you would need to use ! or ? as 
> normal to specify the unwrapped value. The tricky part is that it means the 
> value would have to be widened from the start, otherwise you'd be accessing 
> the value in two different ways in the same block of code, which would mean 
> that narrowing would need to be blocked if there's an incompatible statement 
> further down… ugh, perhaps a keyword will be necessary then? I was really 
> hoping to avoid having to add one though.
> 
>> (2) Should this work?
>> 
>> // compilcatedStuff is a method of T
>> // class A { var foo: T? }
>> 
>> if foo != nil {
>> foo.compilcatedStuff()
>> foo.compilcatedStuff()
>> foo.compilcatedStuff()
>> }
>> 
>> Suppose the compiler doesn't have enough information about compilcatedStuff 
>> to know what happens inside. Then it's possible that foo.compilcatedStuff 
>> will actually change foo (for example, foo could be a relationship and 
>> compilcatedStuff may be deleting the relationship). So, what is the 
>> suggestion for this example? Perhaps
>> 
>> if foo != nil {
>> foo.compilcatedStuff()
>> foo?.compilcatedStuff()
>> foo?.compilcatedStuff()
>> }
>> 
>> or some other choice?
> 
> What do you imagine being inside .complicatedStuff()? It shouldn't be 
> possible for it to change foo to nil, as even if .complicatedStuff() 
> reassigned this, it would be doing so as type T.
> 
>> On 9 Nov 2016, at 06:51, David Hart  wrote:
>>> On 3 Nov 2016, at 20:23, Nevin Brackett-Rozinsky via swift-evolution 
>>>  wrote:
>>> 
>>> This looks like a lot of complexity for very little gain.
>>> 
>>> Aside from any implementation concerns, this proposal substantially 
>>> increases the cognitive load on developers. To figure out what a piece of 
>>> code means, someone reading it will have to mentally keep track of a “type 
>>> stack” for every variable. That is the opposite of “clarity at the point of 
>>> use”.
>> 
>> Very well said. I think this is perhaps the number one complaint I have 
>> about the proposal.
> 
> Did you see my response to this? There should be no particular cognitive load 
> increase; think of the feature like type inference, the idea here is that the 
> type-checker is gaining the same knowledge that you already have, i.e- you 
> know something isn't nil, so the type-checker should too.

Locally in short routines yes.
But in larger modules and non-local this does not apply.
Imo it should always be possible to look at a type declaration and -from that- 
derive all necessary knowledge about the type.
Besides when using a narrowed type as a parameter for an optional it must be 
automatically be widened again? hence you would mentally keep track of the 
status of that variable.





Regards,
Rien

Site: http://balancingrock.nl
Blog: http://swiftrien.blogspot.com
Github: http://github.com/Swiftrien
Project: http://swiftfire.nl




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

Re: [swift-evolution] [Proposal] Type Narrowing

[Rien via swift-evolution]

I get narrowing, and have admittedly often wished for it myself. Hence I have 
kept out of this discussion.
But the argument for cognitive overload is imo convincing.

When we create examples, there is almost no (or even negative) cognitive load 
associated with narrowing.
However when you get a piece of code in front of you with 10+ optionals, 5 
if-statements deep with loops intermixed, and you have to find where the 
nil-error occurs?
It would drive me nuts… especially in these kind of cases:

if foo != nil {
…
foo = newFoo()
…
if foo != nil {
…
}
}

Mind you, I am against automagic narrowing because I like things to be simple, 
but it is not a make or break deal.

Btw, I think that using a keyword makes it more palatable.

if unwrap foo {
…
foo = newFoo()
…
if unwrap foo {
…
}
}

Now it is clear that something is done to foo, its no longer a compare with 
side effects but an operation on foo itself.

Regards,
Rien

Site: http://balancingrock.nl
Blog: http://swiftrien.blogspot.com
Github: http://github.com/Swiftrien
Project: http://swiftfire.nl




> On 09 Nov 2016, at 15:28, Haravikk  wrote:
> 
> 
>> On 9 Nov 2016, at 12:19, Rien  wrote:
>>> On 9 Nov 2016, at 06:51, David Hart  wrote:
 On 3 Nov 2016, at 20:23, Nevin Brackett-Rozinsky via swift-evolution 
  wrote:
 
 This looks like a lot of complexity for very little gain.
 
 Aside from any implementation concerns, this proposal substantially 
 increases the cognitive load on developers. To figure out what a piece of 
 code means, someone reading it will have to mentally keep track of a “type 
 stack” for every variable. That is the opposite of “clarity at the point 
 of use”.
 
 Very well said. I think this is perhaps the number one complaint I have 
 about the proposal.
>>> 
>>> Did you see my response to this? There should be no particular cognitive 
>>> load increase; think of the feature like type inference, the idea here is 
>>> that the type-checker is gaining the same knowledge that you already have, 
>>> i.e- you know something isn't nil, so the type-checker should too.
>> 
>> Locally in short routines yes.
>> But in larger modules and non-local this does not apply.
> 
> I'm not sure what you mean; type-narrowing doesn't occur across scopes, 
> ultimately you will always have some starting type where the variable was 
> declared as a property, function argument or local variable, and it is narrow 
> only where it is used, and the narrowing only occurs within that scope for as 
> long as it is relevant.
> 
> In other words, the narrowing is always local. If you know your method takes 
> an optional string for example then you know that that variable is still an 
> optional string throughout that method, type-narrowing just helps to 
> guarantee that it is nil or non-nil where you expect it to be.
> 
>> Imo it should always be possible to look at a type declaration and -from 
>> that- derive all necessary knowledge about the type.
> 
> As I say, narrowing never changes the type; if you have a variable with a 
> declared type of Foo, that is narrowed to Bar, then it is because Bar extends 
> Foo and thus is compatible with it, giving you access to any additional 
> methods of Bar without interfering with what you know of Foo.
> 
>> Besides when using a narrowed type as a parameter for an optional it must be 
>> automatically be widened again? hence you would mentally keep track of the 
>> status of that variable.
> 
> I'm not sure I follow this question; do you mean something like this:
> 
>   func someMethod(foo:Foo?) {
>   var bar:Foo? = nil // bar is Optional.none
>   if (foo != nil) { // foo is Optional.some
>   bar = foo // both foo and bar are Optional.some
>   }
>   // both foo and bar are Optional (alternative branch 
> places no mutual guarantee on type)
>   if bar != nil { // bar is Optional.some
>   bar.someMutatingMethod()
>   }
>   }
> 
> But these are all things that the developer knows; bar can't be non-nil until 
> a value for it is set, foo is definitely non-nil within the block etc. The 
> only difference here is that instead of the developer having to use ! 
> unnecessarily (or risk making a mistake) they can just use their knowledge of 
> what it is to interact directly, as the type-checker will now also know the 
> same thing.
> 
> However, with the Optional to T method shadowing issue it seems we 
> probably will need to require a keyword, or at the very least restrict 
> automatic narrowing to polymorphism. For optionals the code will have to look 
> something like this:
> 
>   func someMethod(foo:Foo?) {
>   var bar:Foo? = nil
>   if unwrap foo {
>   bar = foo
>   }
> 
>   if unwrap bar {

Re: [swift-evolution] [Pitch] Named subscripts

[Rien via swift-evolution]

> On 18 Nov 2016, at 10:25, Adrian Zubarev via swift-evolution 
>  wrote:
> 
> Thank you guys for all your suggestions so far.
> 
> I understand the idea behind the generic subscript here, they are neat and 
> highly needed, but even this approach won’t solve my issue of clarity here.
> 
> The Array I extend here has an Element of type Value which is an enum that 
> wraps other types around (part of BSON).
> 
> I’d have to insert a huge pattern matching switch into that generic subscript 
> and unwrap every possible type. Don’t get me wrong, this would work, because 
> the result type is an optional, where I just can return nil if nothing 
> matches.
> 
> But again I lose the clarity from the readers prospective, because I don’t 
> know by reading code like array[at: 123] = someValue what kind of subscript 
> I’m using here. 
> 

Is that necessary?
Either the user knows the type of his ‘someValue’ or he does not. If not then I 
assume that he does not need to know. If he needs to know then inspection 
functions can make the discovery process simple.
In general I try to hide implementation details that do not matter to the user.

Rien.

> As already suggested, the view workaround would result in the exact the same 
> syntax I look for, but it has it own downsides as I already mentioned (+ 
> every time you’d need to instantiate a new view).
> 
> 
> 
> 
> -- 
> Adrian Zubarev
> Sent with Airmail
> 
> Am 18. November 2016 um 09:55:00, Haravikk (swift-evolut...@haravikk.me) 
> schrieb:
> 
>> Could this be addressed by allowing generic constraints on subscripts?
>> For example, with methods we can currently do:
>> 
>> struct Foo {
>> var values:[Any] = []
>> 
>> func get(at:Int) -> T? {
>> return values.indices.contains(at) ? values[at] as? T : nil
>> }
>> 
>> func get(at:Int, as theType:T.Type) -> T? {
>> return values.indices.contains(at) ? values[at] as? T : nil
>> }
>> 
>> mutating func set(at:Int, to:T) {
>> if values.indices.contains(at) { values[at] = to }
>> }
>> }
>> 
>> let foo = Foo(values: [1.5, 2.5, 3.5, 1, 2, 3])
>> let a = foo.get(at: 0, as: Double.self)
>> let b:Double = foo.get(at: 1)!
>> let c:Int? = foo.get(at: 2)
>> let d = foo.get(at: 3, as: Double.self)
>> let e:Int = foo.get(at: 4)!
>> let f = foo.get(at: 5, as: Int.self)
>> i.e- the type is inferred from the call-site either with an explicit 
>> variable type, or by passing in the expected type as the second argument, 
>> which I think is a pretty neat way to do it.
>> 
>> If we could do the same with subscripts we could do something like:
>> 
>> struct Foo {
>> var values:[Any] = []
>> 
>> subscript(_ at:Int) -> T? {
>> get { return values.indices.contains(at) ? values[at] as? T : nil }
>> set { if values.indices.contains(at) { values[at] = newValue } }
>> }
>> 
>> subscript(_ at:Int, as theType:T.Type) -> T? {
>> return values.indices.contains(at) ? values[at] as? T : nil
>> }
>> }
>> 
>> let foo = Foo(values: [1.5, 2.5, 3.5, 1, 2, 3])
>> let a = foo[0, as: Double.self]
>> let b:Double = foo[1]!
>> let c:Int? = foo[2]
>> let d = foo[3, as: Double.self]
>> let e:Int = foo[4]!
>> let f = foo[5, as: Int.self]
>> 
>> Are generic constraints on subscripts part of the generics manifesto?
>> 
>>> On 17 Nov 2016, at 20:14, Adrian Zubarev via swift-evolution 
>>>  wrote:
>>> 
>>> Dear Swift community,
>>> 
>>> while building a framework for BSON I had the following idea.
>>> 
>>> Here is a snippet of some code I do have in my module:
>>> 
>>> extension Array where Element == Document.Value {
>>>   
>>> public func double(at index: Int) -> Double? {
>>>   
>>> guard self.startIndex <= index && index < self.endIndex else { 
>>> return nil }
>>>   
>>> if case .double(let double) = self[index] {
>>>   
>>> return double
>>> }
>>> return nil
>>> }
>>>   
>>> …
>>> }
>>> 
>>> This function is used to query the array and check if the element at the 
>>> given index is of a specific type. Now I would like also to implement a 
>>> semi-schema setter.
>>> 
>>> The problem that I see, is the ugliness of the subscript I’d create.
>>> 
>>> Currently the code would read nicely let d = array.double(at: 42), but 
>>> after change to a subscript the API would look odd array[doubleAt: 42] = 
>>> 5.0.
>>> 
>>> Don’t get me wrong here, I also have methods with larger names like public 
>>> func scopedJavaScript(at index: Int) -> …. You can easily imagine that such 
>>> subscripts would look ugly array[scopedJavaScriptAt: 123] = ….
>>> 
>>> I propose to align the design of subscript with functions where one could 
>>> optionally give subscript a name.
>>> 
>>> func name(label parameter: Type) -> ReturnType
>>> 
>>> subscript optionalName(label parameter: Type) -> ReturnType
>>> 
>>> This change would make my API nice and clean. array.scopedJavaScript[at: 
>>> 213] = …
>>> 
>>> This also might be the opportunity to rethink the labeling rule on 
>>> subscripts, but this 

Re: [swift-evolution] [Pitch] Named subscripts

[Rien via swift-evolution]

> On 18 Nov 2016, at 11:45, Adrian Zubarev via swift-evolution 
>  wrote:
> 
> The reason here is because the setter acts like semi-schema setter.

Ah, ok.
Just wondered because I had a similar case in SwifterJSON. Eventually I settled 
for the absence of user-supplied type information while creating the JSON 
object. On read however, type information must be specified for safety 
(semi-schema read).

> 
> For the given array example:
> 
> array.double[at: 42] // would return a nil, if the index is out of bounds, or 
> if the wrapped `Value` instance at the given index is not `.double(Double)`
> 
> array.double[at: 42] = 2.0 // would update the value iff the wrapped `Value` 
> instance is `.double(Double)`, otherwise the setter will do nothing
> 
> This is a semi-schema approach and different from overriding any existing 
> value at the given index like array[42] = .double(2.0)
> 
> About the mutation problem you can find the short talk here, right at the 
> bottom. 
> 
> If there is no setter for your view, array.double[at: 42] = 2.0 simply won’t 
> work.
> 
> Please proof me wrong here, if there is a better way to solve the problem. :)
> 
> I appreciate any suggestions.
> 
> So far we had no concrete arguments agains optionally named subscripts. 
> Anything you dislike about that? 
> 

No, in fact +1

Regards,
Rien

Site: http://balancingrock.nl
Blog: http://swiftrien.blogspot.com
Github: http://github.com/Swiftrien
Project: http://swiftfire.nl

> Personally I don’t think they hurt any Swiftiness at all.
> 
> 
> 
> 
> -- 
> Adrian Zubarev
> Sent with Airmail
> 
> Am 18. November 2016 um 10:39:17, Xiaodi Wu (xiaodi...@gmail.com) schrieb:
> 
>> Sorry, can you explain what you
>> mean when you say you must have a setter? Why would you mutate the
>> view and not the array itself (`foo[42] = .double(42)` as opposed
>> to `foo.double[42] = 42`)?
>> 
>> 
>> On Fri, Nov 18, 2016 at 03:25 Adrian Zubarev via swift-evolution 
>>  wrote:
>> Thank you guys for all your suggestions so far.
>> 
>> I understand the idea behind the generic subscript here, they are neat and 
>> highly needed, but even this approach won’t solve my issue of clarity here.
>> 
>> The Array I extend here has an Element of type Value which is an enum that 
>> wraps other types around (part of BSON).
>> 
>> I’d have to insert a huge pattern matching switch into that generic 
>> subscript and unwrap every possible type. Don’t get me wrong, this would 
>> work, because the result type is an optional, where I just can return nil if 
>> nothing matches.
>> 
>> But again I lose the clarity from the readers prospective, because I don’t 
>> know by reading code like array[at: 123] = someValue what kind of subscript 
>> I’m using here.
>> 
>> As already suggested, the view workaround would result in the exact the same 
>> syntax I look for, but it has it own downsides as I already mentioned (+ 
>> every time you’d need to instantiate a new view).
>> 
>> 
>> 
>> 
>> -- 
>> Adrian Zubarev
>> Sent with Airmail
>> 
>> Am 18. November 2016 um 09:55:00, Haravikk (swift-evolut...@haravikk.me) 
>> schrieb:
>> 
>>> Could this be addressed by allowing generic constraints on subscripts?
>>> For example, with methods we can currently do:
>>> 
>>> struct Foo {
>>> var values:[Any] = []
>>> 
>>> func get(at:Int) -> T? {
>>> return values.indices.contains(at) ? values[at] as? T : nil
>>> }
>>> 
>>> func get(at:Int, as theType:T.Type) -> T? {
>>> return values.indices.contains(at) ? values[at] as? T : nil
>>> }
>>> 
>>> mutating func set(at:Int, to:T) {
>>> if values.indices.contains(at) { values[at] = to }
>>> }
>>> }
>>> 
>>> let foo = Foo(values: [1.5, 2.5, 3.5, 1, 2, 3])
>>> let a = foo.get(at: 0, as: Double.self)
>>> let b:Double = foo.get(at: 1)!
>>> let c:Int? = foo.get(at: 2)
>>> let d = foo.get(at: 3, as: Double.self)
>>> let e:Int = foo.get(at: 4)!
>>> let f = foo.get(at: 5, as: Int.self)
>>> i.e- the type is inferred from the call-site either with an explicit 
>>> variable type, or by passing in the expected type as the second argument, 
>>> which I think is a pretty neat way to do it.
>>> 
>>> If we could do the same with subscripts we could do something like:
>>> 
>>> struct Foo {
>>> var values:[Any] = []
>>> 
>>> subscript(_ at:Int) -> T? {
>>> get { return values.indices.contains(at) ? values[at] as? T : nil }
>>> set { if values.indices.contains(at) { values[at] = newValue } }
>>> }
>>> 
>>> subscript(_ at:Int, as theType:T.Type) -> T? {
>>> return values.indices.contains(at) ? values[at] as? T : nil
>>> }
>>> }
>>> 
>>> let foo = Foo(values: [1.5, 2.5, 3.5, 1, 2, 3])
>>> let a = foo[0, as: Double.self]
>>> let b:Double = foo[1]!
>>> let c:Int? = foo[2]
>>> let d = foo[3, as: Double.self]
>>> let e:Int = foo[4]!
>>> let f = foo[5, as: Int.self]
>>> 
>>> Are generic constraints on subscripts part of the generics manifesto?
>>> 
 On 17 Nov 2016, at 20:14, Adrian Zubarev via swift-evolution 
  wrote:
 
 Dear Swift community,
 
 wh

Re: [swift-evolution] Proposal: Allow "flat" declaration of nested types

[Rien via swift-evolution]

Imo, it does not need extreme nested code to be useful. I find that more than 1 
level of nesting tends to create obfuscation. Probably because we loose the 
ability to associate type C with type A. By allowing "struct A.B.C" it is very 
clear that C does indeed depend on A.
However, I can already see questions coming: how to refer to struct A elements 
and can we introduce new scope visibility rules?
Still, I like this way of programming, so for me its a +1

Regards,
Rien

Site: http://balancingrock.nl
Blog: http://swiftrien.blogspot.com
Github: http://github.com/Swiftrien
Project: http://swiftfire.nl




> On 20 Nov 2016, at 04:18, Robert Widmann via swift-evolution 
>  wrote:
> 
> I think this is an interesting proposal, but I don't write enough 
> extremely-nested code to know that it will do much more than save you some 
> whitespace - as you say.  What situation have you run into specifically where 
> this kind of code is both called-for and headache-inducing?
> 
> ~Robert Widmann
> 
> 2016/11/19 18:48、Alexander Doloz via swift-evolution 
>  のメッセージ:
> 
>> Hello, Swift community!
>> 
>> Right now, when we declare nested types in Swift, we have to literally nest 
>> them:
>> 
>> // Swift 3
>> struct A {
>>   var a = 0
>>   struct B {
>>   var b = 0
>>   struct C {
>>   var c = 0
>>   func someFunc() {
>>   if something {
>> 
>>   }
>>   }
>>   }
>>   }
>> }
>> 
>> By nesting types this way we waste amount of indents we can do without 
>> losing readability. In the example above, code inside if statement will 
>> already be far away from left border. 
>> I propose to allow do nested types like this:
>> 
>> // Proposal
>> struct A {
>>   var a = 0
>> }
>> 
>> struct A.B {
>>   var b = 0
>> }
>> 
>> struct A.B.C {
>>   var c = 0
>>   func someFunc() {
>>   if something {
>> 
>>   }
>>   }
>> }
>> 
>> No more unnecessary indentation. 
>> Of course, the old way should also continue to work. 
>> 
>> 
>> ___
>> 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 "flat" declaration of nested types

[Rien via swift-evolution]

Sure you can do that, but I rather write:

struct A.B {…}

than

extension A { struct B {…} }

The first seems much “swiftier” to me.
In fact, now that this “obvious” dot-notation has been pointed out, I wonder 
why this was not the initial implementation instead of the “extension” keyword.
Was the dot-notation considered? and if so, what was the rationale for choosing 
the “extension” keyword? Is it worth reconsidering?

Regards,
Rien

Site: http://balancingrock.nl
Blog: http://swiftrien.blogspot.com
Github: http://github.com/Swiftrien
Project: http://swiftfire.nl




> On 20 Nov 2016, at 19:05, Derrick Ho  wrote:
> 
> Alexander, I took your code and "flattened" it with what currently exists in 
> Swift 3.  Is this not flat enough for you?
> 
> struct A {
>var a = 0
> }
> 
> extension A {
>struct B {
>   var b = "Bee"
>}
> }
> 
> extension A.B {
>struct C {
>   var c = 0
>   func someFunc() {
>  print("something")
>   }
>}
> }
> 
> A().a // print 0
> A.B().b // Print "Bee"
> A.B.C().someFunc() // Print "something"
> 
> 
> 
> On Sun, Nov 20, 2016 at 10:23 AM Alexander Doloz via swift-evolution 
>  wrote:
> About scope visibility rules – I think, for now this new syntax should behave 
> exactly like the old. What’s possible with old syntax should be possible with 
> the new and vice versa.
> To Robert Widmann’s question about real situation where such syntax will be 
> useful – right now I have a project where nested types are used. They are 
> good for my situation, but:
> 1. When they appear directly in the outer type I have to take extra effort to 
> distinguish between properties and methods of outer type vs. properties and 
> methods of inner type.
> 2. And yes, indents. I don’t do something crazy - I have only I place where 3 
> types are nested. But even if there are 2 types, it becomes inconvenient to 
> read code in the methods of the last nested type.
> New syntax solves this issues.
> > 20 нояб. 2016 г., в 16:00, Rien  написал(а):
> >
> > Imo, it does not need extreme nested code to be useful. I find that more 
> > than 1 level of nesting tends to create obfuscation. Probably because we 
> > loose the ability to associate type C with type A. By allowing "struct 
> > A.B.C" it is very clear that C does indeed depend on A.
> > However, I can already see questions coming: how to refer to struct A 
> > elements and can we introduce new scope visibility rules?
> > Still, I like this way of programming, so for me its a +1
> >
> > Regards,
> > Rien
> >
> > Site: http://balancingrock.nl
> > Blog: http://swiftrien.blogspot.com
> > Github: http://github.com/Swiftrien
> > Project: http://swiftfire.nl
> >
> >
> >
> >
> >> On 20 Nov 2016, at 04:18, Robert Widmann via swift-evolution 
> >>  wrote:
> >>
> >> I think this is an interesting proposal, but I don't write enough 
> >> extremely-nested code to know that it will do much more than save you some 
> >> whitespace - as you say.  What situation have you run into specifically 
> >> where this kind of code is both called-for and headache-inducing?
> >>
> >> ~Robert Widmann
> >>
> >> 2016/11/19 18:48、Alexander Doloz via swift-evolution 
> >>  のメッセージ:
> >>
> >>> Hello, Swift community!
> >>>
> >>> Right now, when we declare nested types in Swift, we have to literally 
> >>> nest them:
> >>>
> >>> // Swift 3
> >>> struct A {
> >>>  var a = 0
> >>>  struct B {
> >>>  var b = 0
> >>>  struct C {
> >>>  var c = 0
> >>>  func someFunc() {
> >>>  if something {
> >>>
> >>>  }
> >>>  }
> >>>  }
> >>>  }
> >>> }
> >>>
> >>> By nesting types this way we waste amount of indents we can do without 
> >>> losing readability. In the example above, code inside if statement will 
> >>> already be far away from left border.
> >>> I propose to allow do nested types like this:
> >>>
> >>> // Proposal
> >>> struct A {
> >>>  var a = 0
> >>> }
> >>>
> >>> struct A.B {
> >>>  var b = 0
> >>> }
> >>>
> >>> struct A.B.C {
> >>>  var c = 0
> >>>  func someFunc() {
> >>>  if something {
> >>>
> >>>  }
> >>>  }
> >>> }
> >>>
> >>> No more unnecessary indentation.
> >>> Of course, the old way should also continue to work.
> >>>
> >>>
> >>> ___
> >>> swift-evolution mailing list
> >>> swift-evolution@swift.org
> >>> https://lists.swift.org/mailman/listinfo/swift-evolution
> >> ___
> >> swift-evolution mailing list
> >> swift-evolution@swift.org
> >> https://lists.swift.org/mailman/listinfo/swift-evolution
> >
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

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

Re: [swift-evolution] Proposal: Allow "flat" declaration of nested types

[Rien via swift-evolution]

> On 21 Nov 2016, at 11:52, Jeremy Pereira  
> wrote:
> 
> 
>> On 21 Nov 2016, at 08:42, Rien via swift-evolution 
>>  wrote:
>> 
>> Sure you can do that, but I rather write:
>> 
>> struct A.B {…}
>> 
>> than
>> 
>> extension A { struct B {…} }
>> 
>> The first seems much “swiftier” to me.
> 
> Hmm, objectively, it’s not “swiftier” is it, because Swift has had the 
> extension syntax since day 1 and not the dot syntax. What you actually mean 
> is “it looks nicer to me” which is an entirely subjective position, one with 
> which I agree, but I don’t think such arguments should carry much weight. 
> 
> Actually, I’d like to see “it seems more swifty” and equivalent expressions 
> banned from the list. The concept isn’t well enough defined for a serious 
> discussion on the merits of proposed language features. /rant

Agreed, won’t use it anymore.

In swift the dot-notation seems to be the preferred way of expressing 
hierarchical relationships. Why not allow the use of the dot-notation for 
inner-type definitions?


>> In fact, now that this “obvious” dot-notation has been pointed out, I wonder 
>> why this was not the initial implementation instead of the “extension” 
>> keyword.
> 
> The extension keyword is needed in the case where you are extending an 
> existing type to conform to a protocol. Given that we already have (and need) 
> the extension form and we can already do 
> 
> extension A.B { struct C { … } }
> 
> is there an objective justification for adding a redundant way of doing the 
> same thing?

I do not see it as the same thing.
Creating an extension for a protocol is conceptually different from defining an 
inner type.
It is common to use a different syntax for same-functionaly if the underlying 
concept is different enough. For example the “if” and “guard” statements.

Regards,
Rien

Site: http://balancingrock.nl
Blog: http://swiftrien.blogspot.com
Github: http://github.com/Swiftrien
Project: http://swiftfire.nl




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

Re: [swift-evolution] [pitch] Implementation composition

[Rien via swift-evolution]

I like that.

Have you considered the following?

protocol foobar {
func foo() …
func bar() ...
}

class A: foobar { …}

class B: foobar {
let a = A() implements foobar.foo
let b = A() implements foobar.bar
}

Regards,
Rien

Site: http://balancingrock.nl
Blog: http://swiftrien.blogspot.com
Github: http://github.com/Swiftrien
Project: http://swiftfire.nl




> On 25 Nov 2016, at 16:33, Jay Abbott via swift-evolution 
>  wrote:
> 
> We already have a great way to compose APIs using protocol composition, and 
> we can supply default implementations for protocol methods, but what if we 
> want to compose implementations from existing types?
> 
> Say I have two disparate protocols:
> 
> protocol A 
> {
> 
> func methodA1()
> 
> 
> func methodA2()
> 
> }
> 
> protocol B 
> {
> 
> func methodB1()
> 
> 
> func methodB2()
> 
> }
> 
> And I also have a selection of classes that implement them, but let’s just 
> consider two:
> 
> class ImplementsA : A 
> {
> 
> func methodA1() 
> {
> 
> print("A1"
> )
> }
> 
> func methodA2() 
> {
> 
> print("A2"
> )
> }
> }
> 
> class ImplementsB : B 
> {
> 
> func methodB1() 
> {
> 
> print("B1"
> )
> }
> 
> func methodB2() 
> {
> 
> print("B2"
> )
> }
> }
> 
> And I have a composed interface:
> 
> typealias Useful = A & B
> Now I want to implement a Useful class by composing it from the two chosen 
> implementations of A and B:
> 
> class MyClass : Useful 
> {
> private 
> let a = ImplementsA
> ()
> private 
> let b = ImplementsB
> ()
> 
> public 
> func methodA1() 
> {
> a.methodA1()
> }
> public 
> func methodA2() 
> {
> a.methodA2()
> }
> public 
> func methodB1() 
> {
> b.methodB1()
> }
> public 
> func methodB2() 
> {
> b.methodB2()
> 
> // I want this to do what 'b' does, plus some
> 
> 
> // extra work in MyClass implementations of B
> 
> 
> print("Extra"
> )
> }
> }
> 
> Not too bad - but that could get pretty tedious if I had 5 protocols to 
> implement with 5 methods each. Much nicer would be:
> 
> class MyClass : Useful 
> {
> private 
> let a = ImplementsA() implements A
> 
> private 
> let b = ImplementsB() implements B
> 
> 
> public 
> func methodB2() 
> {
> b.methodB2()
> 
> // I want this to do whatever 'b' does, plus some
> 
> 
> // extra work in MyClass implementations of B
> 
> 
> print("Extra"
> )
> }
> }
> 
> The idea is that implements SomeProtocol after a member variable will 
> synthesize all the methods that aren’t explicitly implemented from 
> SomeProtcol by forwarding the call to that member. Or something more 
> efficient if possible.
> 
> You could also implement protocols using other classes that only partially 
> implement them:
> 
> class PartlyImplementsB 
> {
> 
> func methodB1() 
> {
> 
> print("B1"
> )
> }
> }
> 
> class MyClass : Useful 
> {
> private 
> let a = ImplementsA() implements A
> 
> private 
> let b = PartlyImplementsB() implements B
> 
> 
> public 
> func methodB2() 
> {
> 
> print("I have to implement this because `b` does not."
> )
> }
> }
> 
> The way this would work is find the intersection between all methods in the 
> protocol and all methods in the implementing member, then subtract all 
> methods already explicitly implemented in the class, and synthesize those. 
> That way if you had another class AlmostImplementsB that implements methodB2 
> you could simply do:
> 
> private let a = ImplementsA() implements A
> 
> private 
> let b1 = PartlyImplementsB() implements B
> 
> private 
> let b2 = AlmostImplementsB() implements B
> However, if the synthesis process finds that it’s synthesizing a method 
> twice, for example in this case…
> 
> protocol C 
> {
> 
> func methodC1()
> 
> 
> func methodC2()
> 
> 
> func methodC3()
> 
> }
> 
> class PartlyImplementsC 
> {
> 
> func methodC1() 
> {
> 
> print("C1(partly)"
> )
> }
> 
> func methodC2() 
> {
> 
> print("C2(partly)"
> )
> }
> }
> 
> class AlmostImplementsC 
> {
> 
> func methodC2() 
> {
> 
> print("C2(almost)"
> )
> }
> 
> func methodC3() 
> {
> 
> print("C3(almost)"
> )
> }
> }
> 
> class MyClass : C 
> {
> private 
> let cPartly = PartlyImplementsC() implements C
> 
> private 
> let cAlmost = AlmostImplementsC() implements C
> 
> }
> 
> …then the compiler would emit an error and you would have to explicitly 
> implement methodC2 to prevent it from being double-synthesized. You could of 
> course have your own custom implementation or choose which member to call as 
> your explicit implementation.
> 
> Regarding access: I think it would implement them as public, as this seems 
> obvious for a protocol, but I guess there’s a possibility you might want them 
> to be internal, so perhaps 

Re: [swift-evolution] Swift evolution proposal: introduce typeprivate access control level

[Rien via swift-evolution]

And the funny thing is, we don’t actually _need_ access control levels.

The only purpose of access control is to enhance security/reliability by 
imposing restrictions on other programmers (API users).

It seems to me that in almost all discussions the arguments are mostly 
backwards: i.e. formulated from the perspective of the API users. Maybe because 
just about all programmers are API users of the OS-API? Anyway…

What I would like to see is a complete overhaul of the access control and 
rewrite it entirely from the perspective of the API provider.
I.e. give a more fine grained control to the API writer in the sense that he 
can specify exactly which other piece of code has access. I consider it 
dangerous by default to open up a scope just because another class needs 
occasional access. (i.e. give -for example- module access just because there is 
1 other class in the module that needs that access. Inadvertently opening up 
access to all other classes in that module.)

An access control list could do just that. Perhaps something like:

access(type, MyFriendClass(get))

The above would provide access to the entire type (but not any children) and 
read-only from MyFriendClass.

A quick -off the cuff- list of access levels:

local: access only to local scope (default)
type: Only the type in which it is defined (no children)
child: The type and its children
: Access is granted to the type named
file: Access is limited to this file only
: Access is granted to the named file
module: Access is granted to the entire module
: Access is granted to the module with the given name
public: Access is granted to everybody

Further access specification could be made possible through the use of the 
dot-notation:

.
.
..

Read/write control through a parameter passing notation:

.([[get],][set])

Examples:

access(type) var count: Int // entire type can read/write
access(type(get), type.incrementer) var count: Int  // Entire type can read, 
only the incrementer function has read/write
access(module, FriendType, public(get)) var count: Int  // Entire module can 
read/write, FriendType can read/write, others can only read

Regards,
Rien

Site: http://balancingrock.nl
Blog: http://swiftrien.blogspot.com
Github: http://github.com/Swiftrien
Project: http://swiftfire.nl




> On 01 Dec 2016, at 21:38, Brandon Knope via swift-evolution 
>  wrote:
> 
> Is anyone starting to think the current access control model will become more 
> burdensome over time?
> 
> People will want to add and subtract to it for years to come...which tells me 
> it's not very flexible. I'm beginning to feel like it is an old style model 
> trying to fit into a modern language. 
> 
> For example, fileprivate and private encourage stuffing a lot of code into 
> one file just to use that access control level. If you want to break this 
> into more manageable chunks you have to make it internal or move it into a 
> new module which is very complicated to do in Xcode (I.e requiring a new 
> target like a framework). 
> 
> This keeps leading me back to having submodules or creating modules on 
> demand. I think that would open up this system to great complexity.
> 
> Want to keep something private to a specific class but private to anything 
> outside of it? Make it internal to the same "submodule". 
> 
> I think we could keep tacking on things to access control, but I don't think 
> it is really solving everyone's needs. I think a more flexible system would 
> allow people to adapt it to their needs instead of structuring everything 
> around a rigid system that forces you to do it swift's way. 
> 
> On Nov 29, 2016, at 10:24 AM, Gonçalo Alvarez Peixoto via swift-evolution 
>  wrote:
> 
>> Hello, everyone!
>> 
>> I would like to introduce a new proposal to swift evolution, but first I 
>> would love to run it by all of you so I get everyone's feedback and enrich 
>> it.
>> 
>> This proposal consists of introducing a new typeprivate access control level 
>> which allows for members to be accessed in all extensions of a given type, 
>> whether lying within or in another file.
>> 
>> You'll find the proposal draft in:
>> https://github.com/goncaloalvarez/swift-evolution/blob/master/proposals/-introduce-typeprivate-access-control-level.md
>> 
>> Thanks in advance for taking the time to evaluate the proposal.
>> 
>> Best regards,
>> Gonçalo
>> ___
>> 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] Any consideration for directoryprivate as a compliment to fileprivate?

[Rien via swift-evolution]

Will discprivate be next? and then systemprivate? 

-1

Regards,
Rien

Site: http://balancingrock.nl
Blog: http://swiftrien.blogspot.com
Github: http://github.com/Swiftrien
Project: http://swiftfire.nl




> On 08 Dec 2016, at 12:27, Adrian Zubarev via swift-evolution 
>  wrote:
> 
> Personal statement: –1
> 
> 
> 
> 
> -- 
> Adrian Zubarev
> Sent with Airmail
> 
> Am 8. Dezember 2016 um 12:26:17, Aron Lindberg (ar...@me.com) schrieb:
> 
>> I think this is a great idea!
>> 
>> I would prefer calling it folderprivate tho.
>> 
>>> On 8 Dec 2016, at 08.29, Adrian Zubarev via swift-evolution 
>>>  wrote:
>>> 
>>> Whoops I meant directoryprivate not dictionaryprivate. I’m probably still 
>>> sleepy. 
>>> 
>>> 
>>> 
>>> 
>>> -- 
>>> Adrian Zubarev
>>> Sent with Airmail
>>> 
>>> Am 8. Dezember 2016 um 08:18:24, Adrian Zubarev 
>>> (adrian.zuba...@devandartist.com) schrieb:
>>> 
 You haven’t seen this in the list because no one requested 
 dictionaryprivate yet. :D
 
 @core-team: See what you have done with >>file<>>> typerprivate, typepublic all these requests for new access modifiers. 
 
 Instead of just going with
 
 private
 private(file)
 
 // for new one
 private(type)
 
 I know there would be some people that would forget about (file/type) and 
 write only private everywhere, which is probably the main reason why we 
 have fileprivate now.
 
 Anyways let’s be a little more constructive here.
 
 Hi Jim, regarding your request, it feels like this is something that falls 
 into the topic of submodules. :) Correct me if I’m wrong here.
 
 
 
 -- 
 Adrian Zubarev
 Sent with Airmail
 
 Am 8. Dezember 2016 um 07:50:07, Jim Malak via swift-evolution 
 (swift-evolution@swift.org) schrieb:
 
> My apologies up front if I am going about this incorrectly. I have been 
> exploring extensions in Swift 3 both as a part of protocol-oriented 
> programming and as a way to encapsulate related code to improve 
> readability and maintainablity of otherwise more complex classes I have 
> designed. I am able to encapsulate methods and calculated properties in 
> extensions and restrict their use to the object type I am extending as 
> long as everything is in one file via fileprivate. 
> 
> I would like to be able to have my class or structure file in a directory 
> that contains my associated extensions  (also in separate files) and be 
> able to restrict the access  of appropriate properties and  methods to 
> that common directory. This would allow the same level encapsulation as 
> fileprivate with the benifit of being able to organize code into 
> sepereate files based on function.
> 
> I did not see this in the commonly rejected list but am unsure if this is 
> something that is out of scope for 4.0. Is this something I can write up 
> a proposal for? Is there some other approach that I missed that I should 
> be using instead?
> 
> Kind regards,
> Jim Malak
> 
> 
> ___
> 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] Any consideration for directoryprivate as a compliment to fileprivate?

[Rien via swift-evolution]

My standard reply is that when a type implementation gets this big, it is quite 
possible that the design is sub optimal.

An equate operation between types almost always means that they have something 
in common that can be isolated into its own file which then also includes the 
equate operation.

Regards,
Rien

Site: http://balancingrock.nl
Blog: http://swiftrien.blogspot.com
Github: http://github.com/Swiftrien
Project: http://swiftfire.nl




> On 08 Dec 2016, at 13:52, Aron Lindberg  wrote:
> 
> I realise the general opinion here seems to be that we don't want any more 
> changes to the access modifiers and I can understand why, but please take a 
> look at the use case below:
> 
> "fileprivate" is needed for certain things like Equatable since the equatable 
> function might need to know about private properties in a class. Lets say I 
> have two structs:
> 
> struct A {
> ...
> }
> 
> struct B {
> ...
> }
> 
> Both are rather big so I declare each in a separate file (File A, File B), 
> but I need to implement an equals function between these two structs that 
> need access to private properties in both structs. This leaves me with two 
> options:
> 
> a) Move the two structs into one file and use fileprivate and implement the 
> equals function here. The result is one long messy file.
> b) Move the two files into a separate module and use "internal" for the 
> variables I need acces to. This feels like overkill and struct A/B might have 
> dependencies that make this inconvenient.
> 
> Am I missing a more optimal solution here? 
> 
> My point is there are legit use cases of fileprivate there might lead to one 
> really big file, with several classes. Having a folderprivate access level 
> would be one possible solution to this.
> 
>> On 8 Dec 2016, at 13.22, Rien via swift-evolution 
>>  wrote:
>> 
>> Will discprivate be next? and then systemprivate? 
>> 
>> -1
>> 
>> Regards,
>> Rien
>> 
>> Site: http://balancingrock.nl
>> Blog: http://swiftrien.blogspot.com
>> Github: http://github.com/Swiftrien
>> Project: http://swiftfire.nl
>> 
>> 
>> 
>> 
>>> On 08 Dec 2016, at 12:27, Adrian Zubarev via swift-evolution 
>>>  wrote:
>>> 
>>> Personal statement: –1
>>> 
>>> 
>>> 
>>> 
>>> -- 
>>> Adrian Zubarev
>>> Sent with Airmail
>>> 
>>> Am 8. Dezember 2016 um 12:26:17, Aron Lindberg (ar...@me.com) schrieb:
>>> 
>>>> I think this is a great idea!
>>>> 
>>>> I would prefer calling it folderprivate tho.
>>>> 
>>>>> On 8 Dec 2016, at 08.29, Adrian Zubarev via swift-evolution 
>>>>>  wrote:
>>>>> 
>>>>> Whoops I meant directoryprivate not dictionaryprivate. I’m probably still 
>>>>> sleepy. 
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> -- 
>>>>> Adrian Zubarev
>>>>> Sent with Airmail
>>>>> 
>>>>> Am 8. Dezember 2016 um 08:18:24, Adrian Zubarev 
>>>>> (adrian.zuba...@devandartist.com) schrieb:
>>>>> 
>>>>>> You haven’t seen this in the list because no one requested 
>>>>>> dictionaryprivate yet. :D
>>>>>> 
>>>>>> @core-team: See what you have done with >>file<>>>>> typerprivate, typepublic all these requests for new access modifiers. 
>>>>>> 
>>>>>> Instead of just going with
>>>>>> 
>>>>>> private
>>>>>> private(file)
>>>>>> 
>>>>>> // for new one
>>>>>> private(type)
>>>>>> 
>>>>>> I know there would be some people that would forget about (file/type) 
>>>>>> and write only private everywhere, which is probably the main reason why 
>>>>>> we have fileprivate now.
>>>>>> 
>>>>>> Anyways let’s be a little more constructive here.
>>>>>> 
>>>>>> Hi Jim, regarding your request, it feels like this is something that 
>>>>>> falls into the topic of submodules. :) Correct me if I’m wrong here.
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> -- 
>>>>>> Adrian Zubarev
>>>>>> Sent with Airmail
>>>>>> 
>>>>>> Am 8. Dezember 2016 um 07:50:07, Jim Malak via swift-evolutio

Re: [swift-evolution] adding automated-testing of uncompilable features in XCTest

[Rien via swift-evolution]

> On 12 Dec 2016, at 07:23, Benjamin Spratling via swift-evolution 
>  wrote:
> 
> 
> 
> -Ben
> 
> Sent from my iPhone.
> 
>> On Dec 11, 2016, at 11:43 PM, Brian Gesiak  wrote:
> 
>> Maybe your goal is to ensure that other programmers don't accidentally 
>> change the accessibility levels. Again, I think because they're 
>> straightforward, I don't think there's much danger there.
>> 
>> To me, tests for accessibility would be redundant. It would be like adding a 
>> test to verify that my struct 'Foo' has a member named 'bar'. If I ever 
>> decided to rename 'Foo.bar', I would have to update the test. But I would 
>> never "accidentally" rename 'Foo.bar' -- if I changed the name, it's because 
>> I modified the code for that purpose. A test adds overhead, but no benefit.
>> 
>> I feel the same about the 'mutating', 'weak', 'unowned', and 'final'.
>> 
>> It's definitely subjective, though. You might feel that the tests I describe 
>> above are valuable, and you're entitled to that opinion.
> 
> 
> I have been in some situations recently in which encapsulation was 
> untestable, and on a team with >10 developers and no automated test to catch 
> that change, there were issues.  In the end we shipped knowing there was a 
> bug, because 15 weeks of work had been based on it, and it would have 
> required a redesign to fix.
> 
> If I need a test that there is a property named 'bar', I can write a test 
> which accesses the member, and even specify a required type and explicitly 
> test whether the property does or does not conform to the protocol.  Even if 
> it's private, I can use a Mirror to extract its value.
> 
> My motivation is: I got tired of hearing "if you did it right, it would have 
> worked", which I now view as an excuse for lack of good design (in most 
> cases).  For the past several months, I have been investigating design 
> patterns which prevent developers from making common mistakes,

That is a very elusive goal.
The best way to do this is through hiring competent people…
One of the quotes I like in this regard: a monkey with a tool is still a monkey…

But I know, we all have to work with the hand we are dealt with. Nevertheless 
it is easy to sink a lot of work in this subject with little to show for it. 
People will make mistakes, no matter how good the tool. I have often felt that 
we need a certain balance, i.e. the tool should hurt you when making a mistake, 
but then it should not hurt so much that you die. That spurs good practises by 
the programmer who otherwise might become complacent. I know I get complacent 
with some Swift/Xcode features… and I hate it when I do, but I still do it…

Btw I have a lot of Ada experience. I love that language. It does way more in 
enforcing a proper design and catching programmers misttakes. However it never 
has gotten much traction for general applications. I blame that on the 
invisibility of avoided error’s…

Just rambling, no real point here… well, maybe one: don’t aim for perfection, 
but make sure it hurts when perfection is not achieved.

That way we will get paid for experience… :-o)

Rien.

> and how to write tests to catch changes to those patterns.  I can't even 
> count the number of unfathomable bugs I've fixed merely by improving the 
> design.  Swift is notable in that its compiler can enforce many of these 
> patterns, so I prefer it over Obj-C.  Proper encapsulation is one such 
> technique, and it turns out it's untestable.
> 
> Thanks for your suggestion about researching how other languages do this.  
> I'll see what I can do, though the only experience I have in any of the ones 
> you mentioned is pre-11 C++, so if anyone else knows how such checks are 
> done, I'd greatly appreciate hearing from you.
> 
> -Ben
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

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

Re: [swift-evolution] Add ability to validate collection indices

[Rien via swift-evolution]

Solutions that work only part of the time will raise expectations of the user 
only to crush hem later when they fail.
It will likely generate a number of “bug” reports that must then be explained.

I would suggest that functionality like this should only be applied to custom 
types, never on the build-in types.

Regards,
Rien

Site: http://balancingrock.nl
Blog: http://swiftrien.blogspot.com
Github: http://github.com/Swiftrien
Project: http://swiftfire.nl




> On 18 Dec 2016, at 10:12, Haravikk via swift-evolution 
>  wrote:
> 
> On 16 Dec 2016, at 14:51, Anton Zhilin via swift-evolution 
>  wrote:
>> 
>> It will be impossible without huge additional overhead.
>> I assume that "invalidated" means "no more points to that element".
>> 
>> Consider that an element is inserted in the middle of an Array.
>> Assuming enough capacity, all iterators after that one will be invalidated.
>> But all new iterators pointing to the same spots will be valid.
>> How do you differentiate between the "old" ones and the "new" ones?
>> 
>> I see only one general approach to this:
>> 1. Make iterator type a class
>> 2. Add to the collection, an array of all iterators, which have been created 
>> (and are being used)
>> 3. Add a "valid" flag to iterator
>> 4. On most operations on the collection, it will walk through its iterators, 
>> marking some as "invalid".
>> 
>> It's a safe way to eliminate some "out of bounds" errors, but it's just 
>> utterly rediculous.
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> 
> There was one idea I was exploring but never quite came up with a final 
> design for, which would be the ability for types to "tag" and invalidate 
> values that they return.
> 
> In essence, a collection might return an index and tag it as "indices", and a 
> later call to remove, add etc. might invalidate all values tagged as 
> "indices", and provide some guidance on what to do about it. The Swift 
> compiler will make a best effort to track these tags to provide warnings.
> 
> I was thinking something like this (heavily cut down):
> 
>   struct Foo : Collection {
>   func index(_ i:Index, offsetBy n:IndexDistance) -> Index 
> @tag("indices") { return i + n }
>   @invalidates("indices") func remove(at:Index) { /* Remove an 
> element */ }
>   }
> 
>   var foo = Foo()
>   let index = foo.index(foo.startIndex, offsetBy: 5)
>   foo.remove(at: index) // This is fine
>   foo.remove(at: index) // Warning: indices of foo have been invalidated
> 
> In other words, the variable index is linked (in the compiler, not at 
> run-time) to the type instance that created it by the specified tag 
> "indices". Now, when that type invalidates "indices" that variable is 
> effectively marked as invalid, thus any attempt to use it will produce a 
> warning that it may no longer be valid. Of course in the case of simple 
> indices it should be fine, though technically speaking you're still doing 
> something that could still fail at runtime.
> 
> The idea here is that, in the simpler cases at least, the compiler gains some 
> awareness of index invalidation, allowing us to potentially avoid run-time 
> errors entirely; naturally it gets more complex if the indices are passed 
> around, but as long as it is still possible to track where they came from 
> (e.g- if it's a collection held by a class reference) then it can still work. 
> This feature could also be used to detect use of an index for the wrong type 
> or instance; i.e- if two instances have the same index type, indices may not 
> be compatible between the two, currently mixing and matching them isn't a 
> compiler error, but can fail unexpectedly at runtime, though there's probably 
> a simpler solution to that specific case (e.g- some way to make the type 
> checker to treat their indices as if they were different types).
> ___
> 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] Add ability to validate collection indices

[Rien via swift-evolution]

I should clarify:

“works only part of the time” was meant to say that it does not cover all 
cases. Sometimes a warning will be given and sometimes not. When referring to 
time I was thinking of the programmer, not of compilation or execution time.

I think that “partially detectable” features increase the cognitive workload 
rather than decreasing it. If that is the case then I would rather do without.

Regards,
Rien

Site: http://balancingrock.nl
Blog: http://swiftrien.blogspot.com
Github: http://github.com/Swiftrien
Project: http://swiftfire.nl




> On 18 Dec 2016, at 12:39, Haravikk  wrote:
> 
> 
>> On 18 Dec 2016, at 10:04, Rien  wrote:
>> 
>> Solutions that work only part of the time will raise expectations of the 
>> user only to crush hem later when they fail.
>> It will likely generate a number of “bug” reports that must then be 
>> explained.
>> 
>> I would suggest that functionality like this should only be applied to 
>> custom types, never on the build-in types.
>> 
>> Regards,
>> Rien
> 
> It's not so much that it only works part of the time, but more that in 
> situations where the "link" would be broken we would need to issue a warning, 
> which could get annoying given that currently we have no way to suppress 
> these.
> 
> This is why I stopped working on it as there's a lot of details to hammer 
> out; I do think it's feasible, but there's a lot to consider. For example, 
> indices could be treated in a manner similar to non-escaping closures, in 
> that you can't store or pass them in any way that would break this link to 
> the parent, unless you use a keyword or attribute to explicitly handle them 
> in an "unsafe" way.
> 
> So it's not so much that it only works "part of the time", but rather that it 
> relies on a type of inference, and needs some way to correctly (and usefully) 
> handle situations where that inference can't be performed, which is why I put 
> it to one side as it was taking up too much time.
> 
> If I ever do have more time I might put up a more formal thread to discuss it 
> properly; I do think it's feasible, and possible to make it work well in most 
> common cases, the question mark is just how best to handle those cases where 
> either more data is needed, or the warning needs to be overridden somehow.
> 
>>> On 18 Dec 2016, at 10:12, Haravikk via swift-evolution 
>>>  wrote:
 On 16 Dec 2016, at 14:51, Anton Zhilin via swift-evolution 
  wrote:
 It will be impossible without huge additional overhead.
 I assume that "invalidated" means "no more points to that element".
 
 Consider that an element is inserted in the middle of an Array.
 Assuming enough capacity, all iterators after that one will be invalidated.
 But all new iterators pointing to the same spots will be valid.
 How do you differentiate between the "old" ones and the "new" ones?
 
 I see only one general approach to this:
 1. Make iterator type a class
 2. Add to the collection, an array of all iterators, which have been 
 created (and are being used)
 3. Add a "valid" flag to iterator
 4. On most operations on the collection, it will walk through its 
 iterators, marking some as "invalid".
 
 It's a safe way to eliminate some "out of bounds" errors, but it's just 
 utterly rediculous.
 ___
 swift-evolution mailing list
 swift-evolution@swift.org
 https://lists.swift.org/mailman/listinfo/swift-evolution
>>> 
>>> There was one idea I was exploring but never quite came up with a final 
>>> design for, which would be the ability for types to "tag" and invalidate 
>>> values that they return.
>>> 
>>> In essence, a collection might return an index and tag it as "indices", and 
>>> a later call to remove, add etc. might invalidate all values tagged as 
>>> "indices", and provide some guidance on what to do about it. The Swift 
>>> compiler will make a best effort to track these tags to provide warnings.
>>> 
>>> I was thinking something like this (heavily cut down):
>>> 
>>> struct Foo : Collection {
>>> func index(_ i:Index, offsetBy n:IndexDistance) -> Index 
>>> @tag("indices") { return i + n }
>>> @invalidates("indices") func remove(at:Index) { /* Remove an 
>>> element */ }
>>> }
>>> 
>>> var foo = Foo()
>>> let index = foo.index(foo.startIndex, offsetBy: 5)
>>> foo.remove(at: index) // This is fine
>>> foo.remove(at: index) // Warning: indices of foo have been invalidated
>>> 
>>> In other words, the variable index is linked (in the compiler, not at 
>>> run-time) to the type instance that created it by the specified tag 
>>> "indices". Now, when that type invalidates "indices" that variable is 
>>> effectively marked as invalid, thus any attempt to use it will produce a 
>>> warning that it may no longer be valid. Of course in the case of simple 
>>> indices it should be fine, though technically speaking you

Re: [swift-evolution] URL Literals

[Rien via swift-evolution]

I like where this is going!
+1

Regards,
Rien

Site: http://balancingrock.nl
Blog: http://swiftrien.blogspot.com
Github: http://github.com/Swiftrien
Project: http://swiftfire.nl




> On 19 Dec 2016, at 08:41, David Sweeris via swift-evolution 
>  wrote:
> 
> 
>> On Dec 17, 2016, at 1:12 PM, Micah Hainline via swift-evolution 
>>  wrote:
>> 
>> I'd love a fleshed out elegant example for URL that shows what a complete 
>> implementation of that special init method would look like. 
> 
> Sorry this took so long… the weekend kinda got away from me.
> 
> Anyway, I was thinking something like this (which has been very simplified on 
> account of my regexing being sub-sketchy, and me not knowing exactly what’s 
> valid in an URL anyway):
> #literalpatterns += (name: “URLLiteralType”, components: (name: url, type: 
> StringLiteralType, pattern: 
> “(http|https)://(www.)?[a-z|A-Z|0-9]+.(com|org|net)(/[a-z|A-Z|0-9]+)*(/[a-z|A-Z|0-9]+.[a-z|A-Z|0-9]+)?”),
>  protocol: ExpressibleByURLLiteral)
> This would let the compiler know pretty much everything it needs to know… 
> that the “new” type is called “URLLiteralType", that it starts out life as 
> young StringLiteralType with a bright future in the computer industry, that 
> in order to succeed it has to match a given pattern, and what protocol a type 
> has to conform to in order to use an URLLiteral. In practice, the compiler 
> would synthesize a struct containing the specified members and validate the 
> literal with the specified pattern before making an “instance” of it (since 
> we’re talking about literals and compile-time code here, I’m pretty sure that 
> “instance" the wrong terminology… pardon my ignorance)
> struct URLLiteralType: {
> let url: StringLiteralType
> }
> A tuple would be better, IMHO, but according to the playground, 
> single-element tuples can’t have element labels. As for the implementation of 
> the init function:
> init(urlLiteral value: URLLiteralType) {
> let urlString = value.url
> //Do whatever URL is doing now, except there’s no need to check for 
> errors since the compiler pre-validated it for us
> }
> 
> If it’d be more useful, the pattern could be split into multiple pieces:
> #literalpatterns += (name: “URLLiteralType”,
>  components: ((name: “`protocol`", type: 
> StringLiteralType, pattern: “(http|https)”),
>   (name: _,type: 
> StringLiteralType, pattern: “://”),
>   (name: “domain", type: 
> StringLiteralType, pattern: “(www.)?[a-z|A-Z|0-9]+.(com|org|net)”),
>   (name: “path”,   type: 
> StringLiteralType, pattern: 
> "(/[a-z|A-Z|0-9]+)*(/[a-z|A-Z|0-9]+.[a-z|A-Z|0-9]+)?”))
>  protocol: ExpressibleByURLLiteral)
> This would result in URLLiteralType looking like this:
> struct URLLiteralType: {
> let `protocol`: StringLiteralType
> let domain: StringLiteralType
> let path: StringLiteralType
> }
> And in the init would start out like this:
> init(urlLiteral value: URLLiteralType) {
> let protocolType = value.protocol
> let domain = value.domain
> let path = value.path
> //Do whatever with the components
> }
> 
> The “base” types of literals like Int or String that don’t refine 
> pre-existing literal types would still need a bit of compiler magic (or at 
> least a different mechanism for becoming actual types), but as long as a type 
> doesn’t take advantage of reference semantics in its stored properties or 
> something, I *think* pretty much any data type could become “literalizeable” 
> with something like this. Oh, and there’s nothing particularly magical about 
> regular expressions as far as this idea is concerned; they’re just usually 
> the first thing that comes to mind when I think of pattern matching in a 
> string. 
> 
> I know this looks like a lot of code, but the scary-looking parts with the 
> regex stuff only has to be written once for each “type” of literal… types 
> that want to be expressible by such a literal just have to write an init 
> function.
> 
> 
> 
> 
> 
> While I was writing this up, it occurred to me that another solution would be 
> to have a set of "ExpressibleByValidated*Literal” protocols, where the init 
> is failable and has to be 
> @pure/@constexpr/@whateverthecompilerneedstorunitatcompiletime. That way the 
> literal can be validated simply by calling the init and checking if it 
> returns nil. Make `URL` conform to `ExpressibleByValidatedStringLiteral`, and 
> you'll get the complie-time validation functionality just by copying 
> whatever’s in the current `URL.init?(string: String)` function.
> 
> - 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

Re: [swift-evolution] "with" operator a la O'Caml?

[Rien via swift-evolution]

A little more work, but I like this pattern.

struct Person {

let name: String
let address: String
let phone: String

func name(_ n: String) -> Person {
return Person(name: n, address: self.address, phone: self.phone)
}

func address(_ a: String) -> Person {
return Person(name: self.name, address: a, phone: self.phone)
}

func phone(_ p: String) -> Person {
return Person(name: self.name, address: self.address, phone: p)
}
}

let p1 = Person(name: "Andrew", address: "Milkyway", phone: "031234")

let p2 = p1.name("Bart")

let p3 = p2.name("Jack").address("Earth”)

Regards,
Rien

Site: http://balancingrock.nl
Blog: http://swiftrien.blogspot.com
Github: http://github.com/Swiftrien
Project: http://swiftfire.nl




> On 18 Dec 2016, at 02:40, Andy Chou via swift-evolution 
>  wrote:
> 
> I like that structs are value types in Swift, this encourages the use of 
> immutable data. O'Caml has an operator "with" that allows for copying an 
> existing struct with a change to one field. I looked at Lenses for this 
> functionality and it seems like a lot to digest for something so simple. I 
> also tried to implement this using a constructor, or a function, and it was 
> not obvious how to do so without a lot of code duplication.
> 
> What's I'm looking for is something like this (not necessarily with this 
> syntax):
> 
> struct Person {
>let name: String
>let address: String
>let phone: String
> }
> 
> func f() {
>let andy = Person(name: "Andy", address: "1 Battery St., San Francisco, 
> CA", phone: "1234567")
>let chris = andy.with(name: "Chris")
>let dave = andy.with(address: "50 Townsend St., San Francisco, CA")
> }
> 
> I tried to implement a "with" function like this but default arguments cannot 
> reference properties of self. Same problem trying to do this in a constructor.
> 
> Obviously it's possible to create an entirely new Person specifying the 
> values from an existing Person, but this is very tedious with structures with 
> many properties.
> 
> Anyone taken a look at this before? Any suggestions?
> 
> Andy
> 
> ___
> 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] Add the DefaultConstructible protocol to the standard library

[Rien via swift-evolution]

+1

Why? well… that is difficult. Mainly because it “feels” right.
Having read a lot of the discussion (but not all) it seems impossible to make a 
“must have” case for it. But on a more conceptual level this feels similar to 
the discovery of zero in mathematics.

Regards,
Rien

Site: http://balancingrock.nl
Blog: http://swiftrien.blogspot.com
Github: http://github.com/Swiftrien
Project: http://swiftfire.nl




> On 27 Dec 2016, at 04:01, Daniel Leping via swift-evolution 
>  wrote:
> 
> I can totally agree that it's not something to deal with Zero concept.
> 
> Though discussion was completely lost for another use case of _generic 
> factories_.
> 
> Also, the interesting part is that discussion brought us to the question if 
> Bool.init(), Int.init() and alike should be removed. I'm 100% positive here 
> as it brings a lot of uncertainty.
> 
> In general, I think if we remove inits described above, DefaultConstructable 
> will be more appealing. I don't see it as a Zero, but rather as a default 
> factory.
> 
> Best,
> Daniel
> 
> On Tue, 27 Dec 2016 at 3:30 Adam Nemecek via swift-evolution 
>  wrote:
> > Huh? You just said that one usage scenario was the allocation of buffers of 
> > known size. If you're unsatisfied with the API for that, you're welcome to 
> > propose better ones. The point is that this is not a convincing use case, 
> > as you claim, for `DefaultConstructible`, but rather for better buffer APIs.
> 
> I've brought up several situation where I'd use these. I don't want a better 
> buffer API, I want a way of expressing myself in a way that seems natural to 
> me.
> 
> > There is no nexus between comparability and "some sort of origin or zero" 
> > from which to measure absolute distance, as you state.
> 
> There is. Elements are equal if the distance between them is zero. Why does 
> Comparability also require Equatability?
> 
> > Ooh boy. There is no worldview in music that "doesn't say anything about 
> > intervals," I can assure you of that.
> 
> https://github.com/midiguchi/midiguchi
> 
> Do you see the zip operation? Could you tell me what it does? Note that I 
> have no relationship to this project. I can find more if I really try. So now 
> there is a precedence, so what's next? Are you going to tell me that this 
> doesn't count? Why not?  I was aware of this library even before this 
> discussion btw.
> 
> > No, I mean that you are incorrect.
> 
> Well if you say so it must be true. Lol. 
> 
> > What closure property? My question was, why are you not using `Strideable`? 
> > You are describing its semantics. I'm not sure what closure you are 
> > referring to.
> 
> Algebraic closure.
> 
> > As I explained earlier, your argument _is_ circular. But it's clear now you 
> > will not accept that being point out to you by multiple people 
> > independently.
> 
> It's not circular, it's I use data point to point out that this is a common 
> pattern.
> 
> 
> 
> On Mon, Dec 26, 2016 at 1:43 PM, Xiaodi Wu  wrote:
> On Mon, Dec 26, 2016 at 4:28 PM, Adam Nemecek  wrote:
> > `ManagedBuffer` is the standard library base class that offers facilities 
> > for managing buffers. If there's a concrete use case that isn't served, 
> > then the argument would be to improve `ManagedBuffer` or to design other 
> > types or protocols for that use case, not to add a protocol to conform 
> > every type that implements `init()`.
> 
> I'd prefer not to deal with raw storage unless necessary. 
> 
> Huh? You just said that one usage scenario was the allocation of buffers of 
> known size. If you're unsatisfied with the API for that, you're welcome to 
> propose better ones. The point is that this is not a convincing use case, as 
> you claim, for `DefaultConstructible`, but rather for better buffer APIs.
>  
> > The distance between two values of type T does not itself need to be of 
> > type T,
> 
> Never said otherwise.
> 
> > Moreover, one can have distances being strideable opaque types that can't 
> > even be initialized 
> 
> You sure can. Doesn't disprove any of my points.
> 
> Sure it does. You asserted that where a type is comparable, it "generally" 
> makes sense to measure distance from "some sort of origin or zero." And I'm 
> showing you why it does not generally make sense at all. There is no nexus 
> between comparability and "some sort of origin or zero" from which to measure 
> absolute distance, as you state.
> 
> > This example does not make sense, computationally or musically. 
> 
> You mean that it does not make any sense to you.
> 
> No, I mean that you are incorrect.
>  
> I have two midi streams (and they are midi) and I want to use one midi note 
> to transpose the other.
> 
> There is no such concept in music theory as "using one note to transpose the 
> other." Sorry.
>  
> I'm pretty sure that I can find a machine that does this in hardware if I 
> really try. Does the fact that such machine might exist imbue the concept of 
> midi addition with any meaning? 
> 
> > You are des

Re: [swift-evolution] Consolidate Code for Each Case in Enum

[Rien via swift-evolution]

I have mixed feelings about this. I would like to see a solution to the 
exploding switch statements in an enum, and we have talked about that before on 
this list. However the solution as suggested seems deficient to me.

First, A developer would have to look at an enum “extension” in order to be 
able to know what to do with the enum. And those extensions can be in different 
files? So at the very least the enum would need to carry the full spec of what 
it can do.

I also dislike the use of the keyword “extension” here. It does not extend 
anything imo.

And thirdly, I dislike having to repeat the function definitions for every enum 
case, that is even more verbose than “switch case”.

Other than that, I would support the simplification of enums as such :-)

Regards,
Rien

Site: http://balancingrock.nl
Blog: http://swiftrien.blogspot.com
Github: http://github.com/Swiftrien
Project: http://swiftfire.nl




> On 07 Jan 2017, at 07:59, Tim Shadel via swift-evolution 
>  wrote:
> 
> Idea: Consolidate the Code for Each Case in an Enum
> ​
> # Motivation:
> ​
> Consolidate all code related to a single enum case in one spot. This makes it 
> easier to ensure that all the pieces mesh coherently across that one case.
> ​
> # Background:
> ​
> Enum cases _feel_ like separately defined, but tightly related structs 
> because each case can have distinct associated values. They have special 
> privileges that a family of structs doesn't have, like `self = .otherCase`. 
> Enums are really awesome.
> ​
> # Proposed Solution:
> ​
> Any `func` or dynamic `var` that provides a unique response per `case` uses a 
> `switch` to do so. I propose to hide that standard `switch` behind some 
> syntactic sugar. Possibly `extension MyEnum.myCase`, assuming that nothing 
> extra is allowed there (protocol conformance, generic constraints, etc.).
> ​
> Here's a typical example of a (simplified) enum that represents 2 states, and 
> conforms to 2 protocols, each requiring different dynamic values based on the 
> case of the enum. In both places, an outer `switch` is used to select the 
> current enum case, and the logic within each branch further determines the 
> value returned.
> ​
> ```
> protocol State {
> mutating func react(to event: Event)
> }
> ​
> enum TokenState: State, CustomStringConvertible {
> ​
> case expired(at: Date)
> case validated(token: String)
> ​
> var description: String {
>   switch self {
> case let .expired(at):
> return "Expired at \(at)"
> case let .validated(token):
> return "Token \(token) has been validated."
>   }
> }
> ​
> mutating func react(to event: Event) {
> switch self {
> case .expired:
> switch event {
> case _ as TokenRefreshed:
> self = .validated(token: event.token)
> default:
> break
> }
> case .validated:
> switch event {
> case _ as TokenRejected:
> self = .expired(at: Date())
> case _ as UserLoggedOut:
> self = .expired(at: Date())
> default:
> break
> }
> }
> }
> 
> }
> ```
> ​
> If we instead allow all the code for each enum case to be consolidated, this 
> new code looks much more like the rest of the code we write in Swift. Real 
> world enums frequently have many more cases, and as the number of enum cases 
> grows consolidating all their logic is increasingly helpful. The following 
> proposal is identical to the code above, it simply "hides" the outer switch 
> statement of each value.
> ​
> ```
> enum TokenState: State, CustomStringConvertible {
> case expired(at: Date)
> case validated(token: String)
> }
> ​
> extension TokenState.expired {
> ​
> var description: String {
>   return "Token expired at \(self.at)"
> }
>   
> mutating func react(to event: Event) {
> switch event {
> case _ as TokenRefreshed:
> self = .untested(token: event.token)
> default:
> break
> }
> }
> ​
> }
> ​
> extension TokenState.validated {
>   
> var description: String {
>   return "Token \(self.token) has been validated."
> }
>   
> mutating func react(to event: Event) {
> switch event {
> case _ as TokenRejected:
> self = .expired(at: Date())
> case _ as UserLoggedOut:
> self = .expired(at: Date())
> default:
> break
> }
> }
> 
> }
> ```
> ​
> I've also shown automatic binding of each case's associated values to 
> properties available on `self` ... but maybe it's better if they're bound to 
> variable references captured the way a closure does. I'm not an expert in 
> this part.
> ​
> Back to the meat of the idea, what happens when a case isn't extended, or 
> only partially extended? Because it's simply a fancy `switch`

[swift-evolution] Cancelable named defer statements

[Rien via swift-evolution]

Is there any interest in a proposal to introduce a named defer statement that 
can be cancelled?

Lately I find myself writing this kind of code:

func openFile(kind: String) -> UnsafeMutablePointer? {

var file = fopen("MyFile.txt", "r")

var closeFile = true

defer { if closeFile { fclose(file) } }

if fileIsNotValid(file) { return nil }

if fileDoesNotContainsData(file, kind) { return nil }

if fileDataOutOfDate(file) { return nil }

// Prevent the deferred handler from closing the file
closeFile = false

return file
}

Which imo would be much cleaner if we were able to write:

func openFile(kind: String) -> UnsafeMutablePointer? {

var file = fopen("MyFile.txt", "r")

CLOSE_FILE: defer { fclose(file) }

if fileIsNotValid(file) { return nil }

if fileDoesNotContainsData(file, kind) { return nil }

if fileDataOutOfDate(file) { return nil }

// Prevent the deferred handler from closing the file
cancel CLOSE_FILE

return file
}

Regards,
Rien

Site: http://balancingrock.nl
Blog: http://swiftrien.blogspot.com
Github: http://github.com/Swiftrien
Project: http://swiftfire.nl
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Proposal draft] Use obtain let instead if let construction

[Rien via swift-evolution]

-1, ‘obtain' obfuscates the meaning of the “if” statement. Since it would 
(conceptually) introduce a new statement that is very similar to the ‘if’ 
statement and ‘guard’ statement it would probably cause even more confusion.

Regards,
Rien

Site: http://balancingrock.nl
Blog: http://swiftrien.blogspot.com
Github: http://github.com/Swiftrien
Project: http://swiftfire.nl




> On 08 Jan 2017, at 08:07, Carlos García via swift-evolution 
>  wrote:
> 
> I just realized my mistake in the example, I've corrected it
> 
>> On 08 Jan 2017, at 07:46, Carlos García  wrote:
>> 
>> Hi Javier,
>> 
>> Maybe I’m not explained correctly in email. The change is not a "guard let”  
>> replacement, instead it is a “if let” replacement.
>> 
>> Best,
>> Carlos
>> 
>>> On 08 Jan 2017, at 05:45, Javier Soto  wrote:
>>> 
>>> Based on your examples I think you were thinking about the "guard" keyword, 
>>> instead of "if"?
>>> 
>>> `If let foo = bar else` is not a valid construction. `if let foo = bar { } 
>>> else {}` may have been what you meant, but in this case it is clear that 
>>> this is just like a regular if, combined with unwrapping an optional.
>>> On Sat, Jan 7, 2017 at 7:12 PM thislooksfun via swift-evolution 
>>>  wrote:
>>> -1 from me, I think that it makes perfect sense the way it is.
>>> 
>>> More specifically, I read `if let safe = optional` as "if optional can be 
>>> unwrapped into safe, then ..."
>>> I think `obtain let` is more confusing, as it's not clear that it's a 
>>> conditional from that keyword. Plus to me, "obtain" seems like it would be 
>>> getting something from somewhere else, not always locally, maybe use an 
>>> `unwrap` keyword in there somewhere, if you want it to be very clear what's 
>>> happening?
>>> 
>>> -thislooksfun (tlf)
>>> 
 On Jan 7, 2017, at 8:46 PM, Carlos García via swift-evolution 
  wrote:
 
 Hi all,
 
 Here’s a draft proposal to change 
 if let construction for obtain let. Proposal is at:
 https://github.com/carlosypunto/swift-evolution/blob/obtain-let-instead-if-let/proposals/-Use-obtain-let-instead-if-let-constructions.md
 
 
 I would like to see what you think and get help with "
 Effect on ABI stability" and "Effect on API resilience
 " points
 
 Carlos
 
 
 ___
 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
>>> -- 
>>> Javier Soto
>> 
> 
> ___
> 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] Consolidate Code for Each Case in Enum

[Rien via swift-evolution]

+1

Site: http://balancingrock.nl
Blog: http://swiftrien.blogspot.com
Github: http://github.com/Swiftrien
Project: http://swiftfire.nl




> On 13 Jan 2017, at 03:01, Tim Shadel via swift-evolution 
>  wrote:
> 
> Fantastic points, all. Let me reply to a few.
> 
> First, the odd situations you mentioned with the defaults were spot on. I had 
> seen them, and thought a bit about it, but having you write it out in code 
> made it obvious that they're pretty harmful. I've removed defaults entirely 
> (see the updated Alternatives and Errors sections). This is actually a really 
> good indicator of whether you should use this syntax or not. If you'll save a 
> noticeable amount of space by using a default, then this isn't the syntax for 
> your situation.
> 
> To make that more obvious, I've added a Mixed Use Example 
> (https://gist.github.com/timshadel/5a5a8e085a6fd591483a933e603c2562#mixed-use-example)
>  showing how simple it is to use the existing syntax when you have a default 
> and a small number of exceptions, alongside the case block syntax for things 
> that are unique for each case. So, to summarize, I think that forcing the 
> additional code for each case is a good thing so that this syntax remains the 
> exception used when needed, instead of becoming the rule.
> 
> Now to your other points. The intent isn't to alter the amount of code 
> required to accomplish the task (code *complexity*), but to simplify 
> *maintenance and understanding* by allowing you to organize the code either 
> by property or by case (according to the merits of the code and your 
> judgement). Indeed, I try to highlight in the proposal that this usually 
> _increases_ code verbosity slightly in favor of the readability gained by 
> shifting the code layout.
> 
> Finally, to your point about attaching properties to values (also echoed in 
> David's musings about tagged unions vs Swift enums), it is different, but I'm 
> not sure of a cleaner way to group all the code related to a single case for 
> complex enums. In another light, no other type in Swift makes such heavy use 
> of `switch` statements as a mechanism to organize code, and so this starts to 
> make enum code look more like the rest of the code you find in Swift 
> projects, which could be a good thing for long-term readability.
> 
> 
>> On Jan 11, 2017, at 9:22 AM, Tony Allevato  wrote:
>> 
>> I'll summarize my thoughts for now, after thinking about it for a bit longer:
>> 
>> Plusses:
>> + In some cases it's nicer to have the ability to group functionality at 
>> each case rather than spread across methods lower in the type definition. 
>> I've written enums that were like state machines where being able to have 
>> the next state transition and other associated data grouped with the case 
>> would have made the code a bit cleaner, IMO.
>> + This is the cleanest syntax I've seen proposed for this idea.
>> 
>> Things that worry me:
>> – It's a new way to express the same idea without necessarily *simplifying* 
>> it in terms of code complexity.
>> – It adds a fair amount of complexity to the compiler, to build the implicit 
>> self-switch and merge the implementations for each partial property/function.
>> – It would be the first time, I believe, in Swift where properties/method 
>> implementations are attached to *values* rather than just to the *type*. 
>> That's quite a departure from the way we model these concepts.
>> – The use of the type-defined implementation as the default when a 
>> case-defined implementation is omitted can lead to some bizarre 
>> combinations, which I think need to be addressed in the proposal. Consider 
>> this:
>> 
>> ```
>> enum Foo {
>>   var description: String {
>> switch self {
>> case .bar: return "bar"
>> case .baz: return "baz"
>> default: return ""
>>   }
>>   
>>   case bar
>>   case baz
>>   case quux {
>> var description: String { return "quux" }
>>   }
>> }
>> ```
>> 
>> Should the user be able to omit the `default` case because everything is 
>> exhaustively covered without it? *Conceptually* yes, but that would require 
>> the compiler to analyze the switch statement inside `description` and 
>> understand that, which is probably not feasible for anything but the 
>> simplest examples (and perhaps not even for those). Otherwise, it would 
>> presumably transform the implementation to this:
>> 
>> ```
>>   var description: String {
>> switch self {
>> case .quux: return "quux"
>> default:
>>   switch self {
>>   case .bar: return "bar"
>>   case .baz: return "baz"
>>   default: return ""
>> }
>>   }
>> ```
>> 
>> ...which produces the expected output, but the generated code might not be 
>> ideal.
>> 
>> That makes me question whether we should allow default implementations at 
>> all. If we didn't allow it, we potentially require the user to write *more* 
>> code because they would have to duplicate the defaults under each case 
>> separately. But it opens a do

Re: [swift-evolution] Throws? and throws!

[Rien via swift-evolution]

-1

I think the basic type system should remain free of such constructs.

I.e. if a Throws? is necessary on a + operation between integers, then the 
integers should be encapsulated into their own type.

In fact I am thinking lately of the “need” for a new type system in parallel to 
the current type system specifically for arithmetic. It would consist of 
Naturals, Reals, Imaginary etc. These new types would also have Nan and 
Infinite as members and use these to deal with out-of-bounds situations. 
Besides, it should be possible to constrain a subtype of them to a predefined 
ranges etc.

While these are just ‘thoughts’ at the moment, I did come to the conclusion 
that “one size fits all” is not the correct approach.
And I apply the same thinking to the suggested Throws?.
Imo it would introduce side effects into the current type system that would 
only benefit a small subset of users, and it would -probably- not completely 
satisfy those user fully. Hence a new arithmetic based type system would 
probably be better. And until (if ever) such a system is available it would imo 
be better to keep things as they are and implement specific mathematical 
requirements in wrappers.

Regards,
Rien

Site: http://balancingrock.nl
Blog: http://swiftrien.blogspot.com
Github: http://github.com/Swiftrien
Project: http://swiftfire.nl




> On 12 Jan 2017, at 23:58, Jonathan Hull via swift-evolution 
>  wrote:
> 
> I really like swift’s error handling system overall. It strikes a good 
> balance between safety and usability.
> 
> There are some cases where it would be nice to throw errors, but errors are 
> rarely expected in most use cases, so the overhead of ‘try’, etc… would make 
> things unusable. Thus fatalError or optionals are used instead.  For example, 
> operators like ‘+’ could never throw because adding ’try’ everywhere would 
> make arithmetic unbearable. But in a few cases it would make my algorithm 
> much cleaner if I just assume it will work and then catch overflow/underflow 
> errors if they happen, and resolve each of them with special cases.  Or 
> perhaps I am dealing with user entered values, and want to stop the 
> calculation and display a user visible error (e.g. a symbol in a spreadsheet 
> cell) instead of crashing.
> 
> I would like to propose adding ‘throws?’ and ‘throws!’ variants to ‘throws’.
> 
> These would be used for cases where error handling is not the default desired 
> behavior, but having it as an option is desired occasionally.  Essentially, 
> the user would no longer have to preface the call with ‘try’, as the compiler 
> would implicitly add ‘try?’ or ‘try!’ respectively.
> 
> Thus, the function would act like a non-throwing function (either trapping or 
> returning an optional in the case of error), but the user could add ‘try’ to 
> the call to override that behavior and deal with the error more explicitly.
> 
> Another example would be bounds checking on arrays.  If subscripting arrays 
> was marked as ‘throws!’ then it would have the same default behavior it does 
> now (trapping on bounds error).  But a user could add ‘try?’ to return nil 
> for a bounds error in cases where they explicitly want that, or they could 
> add ‘try’ to deal with it as an error using do-catch.
> 
> I think this would really increase the availability of error handling in 
> areas where it is impractical right now…
> 
> Thanks,
> Jon
> ___
> 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] protocol-oriented integers (take 2)

[Rien via swift-evolution]

+1

Any change of including “ranged integers”?
I.e. an integer with a value that must fit in a predefined range?

Regards,
Rien

Site: http://balancingrock.nl
Blog: http://swiftrien.blogspot.com
Github: http://github.com/Swiftrien
Project: http://swiftfire.nl




> On 13 Jan 2017, at 21:47, Max Moiseev via swift-evolution 
>  wrote:
> 
> Hi everyone,
> 
> Back in June 2016 we discussed the new design of the integer types for the 
> standard library. It even resulted in acceptance of SE-0104 for Swift 3. 
> Unfortunately we were not able to implement it in time for the release.
> 
> But it was not forgotten, although, as time went by, a few changes needed to 
> be made in order to reflect the current state of the language.
> Without further introduction, please welcome the refined proposal to make 
> integers in Swift more suitable for generic programming.
> 
> Available in this gist 
> https://gist.github.com/moiseev/62ffe3c91b66866fdebf6f3fcc7cad8c and also 
> inlined below.
> 
> Max
> 
> Protocol-oriented integers (take 2)
> 
>   • Proposal: SE-
>   • Authors: Dave Abrahams, Maxim Moiseev
>   • Review Manager: TBD
>   • Status: Awaiting review
>   • Bug: SR-3196
>   • Previous Proposal: SE-0104
> Introduction
> 
> This proposal is an evolution of SE-0104. The goal is still to clean up 
> Swifts integer APIs and make them more useful for generic programming.
> 
> The language has evolved in ways that affect integers APIs since the time the 
> original proposal was approved for Swift 3. We also attempted to implement 
> the proposed model in the standard library and found that some essential APIs 
> were missing, whereas others could be safely removed.
> 
> Major changes to the APIs introduced by this proposal (as compared to 
> SE-0104) are listed in a dedicated section.
> 
> Motivation
> 
> Swift's integer protocols don't currently provide a suitable basis for 
> generic programming. See this blog post for an example of an attempt to 
> implement a generic algorithm over integers.
> 
> The way the Arithmetic protocol is defined, it does not generalize to 
> floating point numbers and also slows down compilation by requiring every 
> concrete type to provide an implementation of arithmetic operators, thus 
> polluting the overload set.
> 
> Converting from one integer type to another is performed using the concept of 
> the 'maximum width integer' (see MaxInt), which is an artificial limitation. 
> The very existence of MaxInt makes it unclear what to do should someone 
> implement Int256, for example.
> 
> Another annoying problem is the inability to use integers of different types 
> in comparison and bit-shift operations. For example, the following snippets 
> won't compile:
> 
> var x: Int8 = 42
> let y = 1
> let z = 0
> 
> 
> x 
> <<= y   // error: binary operator '<<=' cannot be applied to operands of type 
> 'Int8' and 'Int'
> if x > z { ... }  // error: binary operator '>' cannot be applied to operands 
> of type 'Int8' and 'Int'
> Currently, bit-shifting a negative number of (or too many) bits causes a trap 
> on some platforms, which makes low-level bit manipulations needlessly 
> dangerous and unpredictable.
> 
> Finally, the current design predates many of the improvements that came since 
> Swift 1, and hasn't been revised since then.
> 
> Proposed solution
> 
> We propose a new model that does not have above mentioned problems and is 
> more easily extensible.
> 
> +--+  +-+
> +-->+  Arithmetic  |  | Comparable  |
> |   |   (+,-,*,/)  |  | (==,<,>,...)|
> |   +-++  +---+-+
> | ^   ^
> +---++|   |
> |  SignedArithmetic  |  +-+---+---+
> | (unary -)  |  |BinaryInteger|
> +--+-+  |(words,%,bitwise,...)|
>^++---+-+--+
>| +---^   ^ ^---+
>| |   | |
> +--+-+++-+---+  +--++
> |  SignedInteger  ||  FixedWidthInteger  |  |  UnsignedInteger  |
> | ||(endianness,overflow,...)|  |   |
> +---+-++-++--+  +-+-+
> ^^^   ^
> |||   |
> |||   |
>+++-++-+---+-+
>|Int family |-+  |UInt family|-+
>+---+ |  +---+ |
>  +---++---+
> 
> There are several benefits provided by this model over the old one:
> 
>   • It allows mixing integer types in generic functions.
> 
> The possibility to initialize instan

Re: [swift-evolution] Generic Subscripts

[Rien via swift-evolution]

> On 14 Jan 2017, at 18:45, Anton Zhilin via swift-evolution 
>  wrote:
> 
> I’m not sure, but I think that in this case the specific type of these values 
> is determined at runtime.
> Then a safe approach would be separate string: String?, bool: Bool?, int: 
> Int? computed properties, as it’s done in JSON parsers.

Yup. This is what I do:

var json = VJson()
var name: String?

json[“books”][1][“title”] &= “THHGTTG” 

and the reverse

name &= json[“books”][1][“title"]

The overloaded operator ‘&=‘ takes care of the types. (‘=‘ cannot be overloaded)



> 
> if let bookCount = row.value(named: "bookCount").int {
> ...
> }
> if let bookCount = row["bookCount"].int {
> ...
> }
> let bookCount = 
> row.int
> ("bookCount")!   // crash if database is corrupt
> 
> Additionally, this is an overall bad example of generics. Fields of database 
> tables can only map to a limited set of static types in Swift, which are 
> supported by database adapter.
> 
> 2017-01-14 16:50 GMT+03:00 Gwendal Roué via swift-evolution 
> :
> 
> 
> 
> This is a consequence of your vision of subscript. If interesting, it is also 
> limiting for no real purpose.
> 
> As the developer of a Swift database library, I'd like to offer a better API 
> than the following:
> 
> // Current state of affairs
> let name: String = row.value(named: "name")
> let bookCount: Int = row.value(named: "bookCount")
> let hasBooks: Bool = row.value(named: "bookCount")
> 
> Instead, I wish I could offer GRDB.swift would let its users write:
> 
> // With improved subscripts
> let name: String = row["name"]
> let bookCount: Int = row["bookCount"]
> let hasBooks: Bool = row["bookCount"]
> 
> And this requires genericity on return type.
> 
> Gwendal
> 
> 
> ___
> 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

Regards,
Rien

Site: http://balancingrock.nl
Blog: http://swiftrien.blogspot.com
Github: http://github.com/Swiftrien
Project: http://swiftfire.nl




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

Re: [swift-evolution] [Proposal] Replace all Swift comments by end notes.

[Rien via swift-evolution]

-1

Comments should be part of the “flow of thought”.
Moving them away from where they are needed is counter productive.

Note that you can never force a bad programmer to become good.

Regards,
Rien

Site: http://balancingrock.nl
Blog: http://swiftrien.blogspot.com
Github: http://github.com/Swiftrien
Project: http://swiftfire.nl




> On 17 Jan 2017, at 12:30, Alex Blewitt via swift-evolution 
>  wrote:
> 
> On 16 Jan 2017, at 15:28, Amir Michail via swift-evolution 
>  wrote:
>> 
>> Why not replace all Swift comments by end notes at the end of each source 
>> file so as to minimize the impact of misleading/outdated comments on code 
>> comprehension?
> 
> A strong -1 from me. Moving comments aside from the place where the code is 
> defined is going to maximise outdated comments, not minimise it.
> 
>> You don’t necessarily need to scroll to the end of the source file to read a 
>> referenced end note in the code since the IDE could show a popup whenever 
>> the mouse pointer lingers over an end note reference (e.g., a number/label).
>> 
>> Maybe this would encourage programmers to write more self-explanatory code 
>> while keeping (end note) comments to a minimum?
> 
> This proposal would certainly discourage having accurate comments.
> 
> Alex
> ___
> 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] Preconditions aborting process in server scenarios [was: Throws? and throws!]

[Rien via swift-evolution]

I am a bit ambivalent on this, on the one hand I think that “catch all, bring 
down thread only” stimulate careless programming, and on the other hand it did 
save my beacon on more than one occasion.

In a perfect world we should do without this kind of feature.

In the real world we need it to meet deadlines imposed by people who don’t 
understand software design….

Regards,
Rien

Site: http://balancingrock.nl
Blog: http://swiftrien.blogspot.com
Github: http://github.com/Swiftrien
Project: http://swiftfire.nl




> On 17 Jan 2017, at 23:45, Jonathan Hull via swift-evolution 
>  wrote:
> 
> Bringing it back towards the initial post, what if there was a separation 
> from true needs-to-take-down-the-entire-system trapping and things like 
> out-of-bounds and overflow errors which could stop at thread/actor bounds (or 
> in some cases even be recovered)?  
> 
> The latter were the ones I was targeting with my proposal.  They live in this 
> grey area, because honestly, they should be throwing errors if not for the 
> performance overhead and usability issues.  My solution was to give the 
> compiler a way to know that this was the desired behavior and optimize the 
> throwing away unless it was explicitly requested.
> 
> I guess another option would be to introduce a new concept for this grey type 
> of error.  Maybe instead of ‘fatalError’ you have something with a different 
> name saying “this should only take down the current actor”… and then you add 
> a well defined process for cleanup.
> 
> I would still really like to see the ability to turn this type of thing into 
> normal throwing error handling, so maybe something like ‘fatalThrow’ which 
> takes the same information as ‘throw’, so that it can be converted to a 
> standard throw by the caller, but otherwise traps and takes down the actor.  
> That would make certain types of algorithms much simpler for me.
> 
> Thanks,
> Jon
> 
>> On Jan 17, 2017, at 11:49 AM, Dave Abrahams via swift-evolution 
>>  wrote:
>> 
>> 
>> on Mon Jan 16 2017, Chris Lattner  wrote:
>> 
 On Jan 16, 2017, at 3:57 PM, David Waite via swift-evolution
>>>  wrote:
 
 My interpretation is that he was advocating a future where a
 precondition’s failure killed less than the entire process. Instead,
 shut down some smaller portion like a thread, actor, or container
>>> 
 like .Net's app domains (which for those more familiar with
 Javascript could be loosely compared with Web Workers).
 
 Today - if you wanted a Swift server where overflowing addition
 didn’t interrupt your service for multiple users, you would need to
 use something like a pre-fork model (with each request handled by a
 separate swift process)
 
 That's the difference between CLI and desktop apps where the process
 is providing services for a single user, and a server where it may
 be providing a service for thousands or millions of users.
>>> 
>>> Agreed, I’d also really like to see this some day.  It seems like a
>>> natural outgrowth of the concurrency model, if it goes the direction
>>> of actors.  
>>> 
>>> If you’re interested, I speculated on this direction in this talk:
>>> http://researcher.watson.ibm.com/researcher/files/us-lmandel/lattner.pdf
>>> 
>> 
>> I totally support the idea of emergency shutown measures
>> (e.g. save document for recovery), 
>> 
>> In general, though, when a precondition is violated, it means your
>> program state is compromised in an arbitrarily bad way.  Unfortunately,
>> that applies equally across process boundaries as it does across thread
>> boundaries, if there's some kind of static guarantee of safety as might
>> be provided by actors.  This means you need a way to make decisions
>> about which kinds of precondition violations should be considered
>> recoverable as long as you're willing to abandon the job, and which
>> really do need to be fatal for the whole process... and I don't know if
>> anyone's really ever figured that problem out.  It'd be cool if Swift
>> could solve it.
>> 
>> -- 
>> -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

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

Re: [swift-evolution] Testing enum cases with associated values

[Rien via swift-evolution]

A guy named Matthias recently commented this on my blog:

func == (left: Enum3, right: Enum3) -> Bool {
switch (left, right) {
case (.ONE, .ONE):
return true
case (.TWO(let str1), .TWO(let str2)):
return str1 == str2
default:
return false
}
}

http://swiftrien.blogspot.nl/2015/05/swift-enum-compare-design-pattern.html

Regards,
Rien

Site: http://balancingrock.nl
Blog: http://swiftrien.blogspot.com
Github: http://github.com/Swiftrien
Project: http://swiftfire.nl




> On 18 Jan 2017, at 01:15, Andy Chou via swift-evolution 
>  wrote:
> 
> Enums with associated values can be very useful in Swift, but once you add 
> associated values you lose some properties, especially equality:
> 
> ```
> enum AuthenticationResponse {
>case success
>case alert(Alert)
>case reauthenticate
> }
> ```
> 
> Testing for a specific case requires a switch statement or the if pattern 
> match syntax:
> 
>   if case .success = response { … }
> 
> But while this works well for control flow, it doesn’t work well for cases 
> where we want a Bool, such as assert(). There are also common situations with 
> lists and libraries like RxSwift where a filtering function uses a Bool 
> valued closure. In these situations the best we can do is write functions 
> like:
> 
> ```
> enum AuthenticationResponse {
>case success
>case alert(Alert)
>case reauthenticate
> 
>var isSuccess: Bool {
>if case .success = self {
>return true
>} else {
>return false
>}
>}
> 
>var isReauthenticate: Bool {
>if case .reauthenticate = self {
>return true
>} else {
>return false
>}
>}
> 
>var isAlert: Bool {
>if case .alert(_) = self {
>return true
>} else {
>return false
>}
>}
> }
> ```
> Any suggestions better than writing out each of these functions explicitly?
> 
> The conditional conformances proposal coming in Swift 4 solves some of this 
> issue, but not completely. If Alert isn’t Equatable, it is still useful to 
> test whether the result is .success.  For example:
> 
>   assert(response == .success)
> 
> This is perfectly intelligible and I would argue that equality should be 
> defined for enums with associated values omitted:
> 
>   assert(response == .alert)
> 
> Here we are ignoring the associated values, and merely checking if the enum 
> case is the same.
> 
> Andy
> 
> ___
> 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] Preconditions aborting process in server scenarios [was: Throws? and throws!]

[Rien via swift-evolution]

> On 18 Jan 2017, at 08:54, Jonathan Hull via swift-evolution 
>  wrote:
> 
> 
>> On Jan 17, 2017, at 7:13 PM, Dave Abrahams  wrote:
>> 
>> 
>> on Tue Jan 17 2017, Jonathan Hull  wrote:
>> 
>>> Bringing it back towards the initial post, what if there was a
>>> separation from true needs-to-take-down-the-entire-system trapping and
>>> things like out-of-bounds and overflow errors which could stop at
>>> thread/actor bounds (or in some cases even be recovered)?
>>> 
>>> The latter were the ones I was targeting with my proposal.  They live
>>> in this grey area, because honestly, they should be throwing errors if
>>> not for the performance overhead and usability issues.  
>> 
>> I fundamentally disagree with that statement.  There is value in
>> declaring certain program behaviors illegal, and in general for things
>> like out-of-bounds access and overflow no sensible recovery (where
>> “recovery” means something that would allow the program to continue
>> reliably) is possible.  
> 
> I think we do fundamentally disagree.  I know I come from a very different 
> background (Human-Computer Interaction & Human Factors) than most people 
> here, and I am kind of the odd man out, but I have never understood this 
> viewpoint for anything but the most severe cases where the system itself is 
> in danger of being compromised (certainly not for an index out of bounds).  
> In my mind “fail fast” is great for iterating in development builds, but once 
> you are deploying, the user’s needs should come ahead of the programmer’s.
> 
> Shouldn’t a system be as robust as possible

Yes

> and try to minimize the fallout from any failure point?

That is in direct conflict with the robustness
Once an error is detected that is not handled by the immediate code, it must be 
assumed that a worst-case scenario happened. And further damage to the user can 
only be prevent by bringing down the app. Even if that means losing all work in 
progress.

A compromised system must be prevent from accessing any resources. Once a 
system is compromised the risk to the user is *much* higher than simply loosing 
work in progress. He might loose his job, career, etc.

Rien.


>  I don’t consider crashing and losing all of the user’s data minimal.  It 
> used to be that something like dividing by zero took down the entire machine. 
>  Now we mimic that by crashing the application, even though it isn’t strictly 
> necessary.  Wouldn’t it be even better if we only took down the current 
> operation, notified the user about what happened and continue on?
> 
> Swift does a great job of using forcing functions (like optionals) to make 
> some errors impossible, and this is literally the opposite of that. This 
> requires the programmer to remember to add a check that the number is within 
> certain bounds, but there is no reminder for them to do that.  The failure is 
> silent (i.e. there isn’t a ‘!’ or ’try' to mark that it is a possibility), at 
> runtime, under certain conditions and not others.  It is a recipe for bugs 
> which cause a crash for the user.
> 
> If we wanted fool-proof arrays, then the subscript would return an optional, 
> forcing the programmer to think about and deal with the possibility of 
> out-of-bounds failure (that is how we handle dictionary lookups after all).  
> If I remember correctly, we don’t do that because of performance. Instead we 
> ask the programmer to remember to check against the array count first, just 
> like we used to ask the programmer to remember to check for nil pointers in 
> C++.
> 
> The idea that a programmer can or should be perfect is a lovely fantasy…  My 
> CS teachers always talked about how it would encourage bad programming if 
> there wasn’t punishment for making these types of mistakes.
> 
> I don’t see the value in punishing the user for the programmer’s mistake, and 
> I have rarely seen a case where sensible recovery wouldn’t be possible (given 
> Swift’s error handling).  In most real-world applications, you would just end 
> up cancelling whatever operation was happening, reverting to the state before 
> it, and notifying the user of the problem.  The programming languages which 
> get into trouble are the ones which treat everything as valid, so they just 
> keep barreling on, overwriting data or something like that.  We don’t have 
> that problem though, since we have sensible error handling that can be used 
> to fail an operation and get things back to a previous state (or better yet, 
> avoiding overwriting the state until after the operation has succeeded).  We 
> should aim for robustness, and crashing isn’t robust.
> 
> Please note: I am not saying we allow memory access out of bounds. We are 
> still triggering an error state when these things happen (either returning 
> nil or throwing an error), we’re just not crashing the entire program because 
> of it.
> 
> 
> 
>> 
>>> My solution was to give the compiler a way to know that this was the
>>> desired behavior and opti

Re: [swift-evolution] [draft] Compound Names For Enum Cases

[Rien via swift-evolution]

Would this be allowed ?

enum foo {
case bar(num: Int)
case bar(str: String)
case vee(val: Bool)
}

If so, would this still be allowed ?

var a: foo = ...
switch a {
case vee: ...
case bar: ...
}


Regards,
Rien

Site: http://balancingrock.nl
Blog: http://swiftrien.blogspot.com
Github: http://github.com/Swiftrien
Project: http://swiftfire.nl




> On 19 Jan 2017, at 19:37, Daniel Duan via swift-evolution 
>  wrote:
> 
> Hi all,
> 
> Here’s a short proposal for fixing an inconsistency in Swift’s enum. Please 
> share you feedback :)
> 
> (Updating/rendered version: 
> https://github.com/dduan/swift-evolution/blob/compound-names-for-enum-cases/proposals/-Compound-Names-For-Enum-Cases.md)
> 
> 
> ## Introduction
> 
> Argument labels are part of its function's declaration name. An enum case
> declares a function that can be used to construct enum values. For cases with
> associated values, their labels should be part of the constructor name, 
> similar
> to "normal" function and methods. In Swift 3, however, this is not true. This
> proposal aim to change that.
> 
> ## Motivation
> 
> After SE-0111, Swift function's fully qualified name consists of its base name
> and all argument labels. As a example, one can invoke a function with its
> fully name:
> 
> ```swift
> func f(x: Int, y: Int) {}
> 
> f(x: y:)(0, 0) // Okay, this is equivalent to f(x: 0, y: 0)
> ```
> 
> This, however, is not true when enum cases with associated value were
> constructed:
> 
> ```swift
> enum Foo {
> case bar(x: Int, y: Int)
> }
> 
> Foo.bar(x: y:)(0, 0) // Does not compile as of Swift 3
> ```
> 
> Here, the declared name for the case is `foo`; it has a tuple with two labeled
> fields as its associated value. `x` and `y` aren't part of the case name. This
> inconsistency may surprise some users.
> 
> Using tuple to implement associated value also limits us from certain layout
> optimizations as each payload need to be a tuple first, as opposed to simply 
> be
> unique to the enum.
> 
> ## Proposed solution
> 
> Include labels in enum case's declaration name. In the last example, `bar`'s
> full name would become `bar(x:y:)`, `x` and `y` will no longer be labels in a
> tuple. The compiler may also stop using tuple to represent associated values.
> 
> ## Detailed design
> 
> When labels are present in enum cases, they are now part of case's declared 
> name
> instead of being labels for fields in a tuple. In details, when constructing 
> an
> enum value with the case name, label names must either be supplied in the
> argument list it self, or as part of the full name.
> 
> ```swift
> Foo.bar(x: 0, y: 0) // Okay, the Swift 3 way.
> Foo.bar(x: y:)(0, 0) // Equivalent to the previous line.
> Foo.bar(x: y:)(x: 0, y: 0) // This would be an error, however.
> ```
> 
> Note that since the labels aren't part of a tuple, they no longer participate 
> in
> type checking, similar to functions:
> 
> ```swift
> let f = Foo.bar // f has type (Int, Int) -> Foo
> f(0, 0) // Okay!
> f(x: 0, y: 0) // Won't compile.
> ```
> 
> ## Source compatibility
> 
> Since type-checking rules on labeled tuple is stricter than that on function
> argument labels, existing enum value construction by case name remain valid.
> This change is source compatible with Swift 3.
> 
> ## Effect on ABI stability and resilience
> 
> This change introduces compound names for enum cases, which affects their
> declaration's name mangling.
> 
> The compiler may also choose to change enum payload's representation from 
> tuple.
> This may open up more space for improving enum's memory layout.
> 
> ## Alternatives considered
> 
> Keep current behaviors, which means we live with the inconsistency.
> 
> ___
> 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] Strings in Swift 4

[Rien via swift-evolution]

Wow, I fully support the intention (becoming better than Perl) but I cannot 
comment on the contents without studying it for a couple of days…

Regards,
Rien

Site: http://balancingrock.nl
Blog: http://swiftrien.blogspot.com
Github: http://github.com/Swiftrien
Project: http://swiftfire.nl




> On 20 Jan 2017, at 03:56, Ben Cohen via swift-evolution 
>  wrote:
> 
> Hi all,
> 
> Below is our take on a design manifesto for Strings in Swift 4 and beyond.
> 
> Probably best read in rendered markdown on GitHub:
> https://github.com/apple/swift/blob/master/docs/StringManifesto.md
> 
> We’re eager to hear everyone’s thoughts.
> 
> Regards,
> Ben and Dave
> 
> 
> # String Processing For Swift 4
> 
> * Authors: [Dave Abrahams](https://github.com/dabrahams), [Ben 
> Cohen](https://github.com/airspeedswift)
> 
> The goal of re-evaluating Strings for Swift 4 has been fairly ill-defined thus
> far, with just this short blurb in the
> [list of 
> goals](https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160725/025676.html):
> 
>> **String re-evaluation**: String is one of the most important fundamental
>> types in the language.  The standard library leads have numerous ideas of how
>> to improve the programming model for it, without jeopardizing the goals of
>> providing a unicode-correct-by-default model.  Our goal is to be better at
>> string processing than Perl!
> 
> For Swift 4 and beyond we want to improve three dimensions of text processing:
> 
>  1. Ergonomics
>  2. Correctness
>  3. Performance
> 
> This document is meant to both provide a sense of the long-term vision 
> (including undecided issues and possible approaches), and to define the scope 
> of
> work that could be done in the Swift 4 timeframe.
> 
> ## General Principles
> 
> ### Ergonomics
> 
> It's worth noting that ergonomics and correctness are mutually-reinforcing.  
> An
> API that is easy to use—but incorrectly—cannot be considered an ergonomic
> success.  Conversely, an API that's simply hard to use is also hard to use
> correctly.  Acheiving optimal performance without compromising ergonomics or
> correctness is a greater challenge.
> 
> Consistency with the Swift language and idioms is also important for
> ergonomics. There are several places both in the standard library and in the
> foundation additions to `String` where patterns and practices found elsewhere
> could be applied to improve usability and familiarity.
> 
> ### API Surface Area
> 
> Primary data types such as `String` should have APIs that are easily 
> understood
> given a signature and a one-line summary.  Today, `String` fails that test.  
> As
> you can see, the Standard Library and Foundation both contribute 
> significantly to
> its overall complexity.
> 
> **Method Arity** | **Standard Library** | **Foundation**
> ---|:---:|:---:
> 0: `ƒ()` | 5 | 7
> 1: `ƒ(:)` | 19 | 48
> 2: `ƒ(::)` | 13 | 19
> 3: `ƒ(:::)` | 5 | 11
> 4: `ƒ()` | 1 | 7
> 5: `ƒ(:)` | - | 2
> 6: `ƒ(::)` | - | 1
> 
> **API Kind** | **Standard Library** | **Foundation**
> ---|:---:|:---:
> `init` | 41 | 18
> `func` | 42 | 55
> `subscript` | 9 | 0
> `var` | 26 | 14
> 
> **Total: 205 APIs**
> 
> By contrast, `Int` has 80 APIs, none with more than two parameters.[0] String 
> processing is complex enough; users shouldn't have
> to press through physical API sprawl just to get started.
> 
> Many of the choices detailed below contribute to solving this problem,
> including:
> 
>  * Restoring `Collection` conformance and dropping the `.characters` view.
>  * Providing a more general, composable slicing syntax.
>  * Altering `Comparable` so that parameterized
>(e.g. case-insensitive) comparison fits smoothly into the basic syntax.
>  * Clearly separating language-dependent operations on text produced 
>by and for humans from language-independent
>operations on text produced by and for machine processing.
>  * Relocating APIs that fall outside the domain of basic string processing and
>discouraging the proliferation of ad-hoc extensions.
> 
> 
> ### Batteries Included
> 
> While `String` is available to all programs out-of-the-box, crucial APIs for
> basic string processing tasks are still inaccessible until `Foundation` is
> imported.  While it makes sense that `Foundation` is needed for 
> domain-specific
> jobs such as
> [linguistic 
> tagging](https://developer.apple.com/reference/foundation/nslinguistictagger),
> one should not need to import anything to, for example, do case-insensitive
> comparison.
> 
> ### Unicode Compliance and Platform Support
> 
> The Unicode standard provides a crucial objective reference point for what
> constitutes correct behavior in an extremely complex domain, so
> Unicode-correctness is, and will remain, a fundamental design principle behind
> Swift's `String`.  That said, the Unicode standard is an evolving document, so
> this objective reference-point is not fixed.[1] While
> many of the most important operations—e.g. string hashing, equal

Re: [swift-evolution] Annotation of Warnings/Errors

[Rien via swift-evolution]

OTOH, looking at fixit and error messages can also aid in understanding Swift 
better.
Seeing what happens when it happens is something I find quite useful.

Not that I have anything against the proposal, but I do wonder if that is the 
best usage of available resources. 

A BIG OT warning:

If people are so easily put off, they probably are not very suited to being a 
programmer/sw-engineer. It might be good for them to drop out asap so they can 
pursue something more fitting to their personality… I have met a lot of people 
that would have been better off not to get into programming. It would have been 
better for them and for the projects they worked on.

Regards,
Rien

Site: http://balancingrock.nl
Blog: http://swiftrien.blogspot.com
Github: http://github.com/Balancingrock
Project: http://swiftfire.nl





> On 26 Jan 2017, at 00:46, Jonathan Hull via swift-evolution 
>  wrote:
> 
> One of the biggest issues that I saw while teaching Swift to newbies (most 
> had not programmed before) is confusion based on the early warnings/errors 
> that swift/xcode gives you as they type.  What would happen is that they 
> would type a variable, and it would say… “You haven’t used this variable” and 
> so they would just click the fixit because they trust the compiler more than 
> they trust themselves.  This would lead to a point where they were very 
> confused because some of the code was code they had thought through, and some 
> of it was changed by random fixits in ways they didn’t understand… and so it 
> would lead to more errors/fixits until they had errors which couldn’t be 
> fixed.
> 
> By the end of the semester they had learned to ignore the warnings until they 
> were finished, but it took a couple of months to get there, and was a big 
> deterrent to new users… (Also, learning to ignore warnings ignorer to use a 
> system seems like an anti-pattern)
> 
> I have a good friend who is an expert perl programmer who tried Swift and 
> eventually gave up because he couldn’t figure out which errors to ignore (and 
> which might just disappear a minute later) and which he needed to pay 
> attention to. He was overwhelmed by the sheer number, and they didn’t seem 
> trustworthy to him (“Swift is full of lies!” he would say of the warnings… 
> which is a mantra I find myself parroting when I get those 
> appearing/disappearing errors).
> 
> 
> To fix this, I propose adding a way to annotate warnings/errors to say how 
> immediate they need to be:
> • Immediate - This error should always be shown
> • DifferentLine - This error should only be shown once the cursor is on a 
> different line
> • DifferentScope - This error should only be shown once the cursor is in a 
> different scope from this line
> • DifferentFunction - This error should only be shown once the cursor is in a 
> different function
> 
> So the “You haven’t used this variable” warning would be marked 
> .differentScope, meaning that it would only show up once you had clicked away 
> from the scope. The reason for this is that while you are in the same scope, 
> it is fairly likely that you are still going to use the variable… so the 
> warning is premature. Once I have left the scope, it makes sense to warn me.
> 
> Similarly, the “You need a return value” error would be marked 
> .differentFunction because you are likely to add one while typing the 
> function. But a type mismatch with the return value would either be 
> .immediate or .differentLine because you have made an error that isn’t likely 
> to be fixed with more typing on other lines.
> 
> I think this will cut way down on the number of warnings/errors that need to 
> be ignored, which should increase trust in the system overall.
> 
> To be clear, I am only proposing adding the annotation to Swift (probably 
> with a default of .differentLine). The compiler would not repress the 
> warning/error itself… just vend it with a way to retrieve the annotation.  
> IDE makers like Apple/Xcode would then be free to use that extra information 
> in their UI if desired.
> 
> Thanks,
> Jon
> ___
> 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] The lack of namespaces is leading people astray

[Rien via swift-evolution]

I have been known to mimic namespaces as well, however now that SPM is here, I 
no longer see a need for it.

Still, I won’t object to it.

Regards,
Rien

Site: http://balancingrock.nl
Blog: http://swiftrien.blogspot.com
Github: http://github.com/Balancingrock
Project: http://swiftfire.nl





> On 01 Feb 2017, at 06:30, David Sweeris via swift-evolution 
>  wrote:
> 
> 
>> On Jan 30, 2017, at 5:55 AM, Tuur Anton via swift-evolution 
>>  wrote:
>> 
>> The lack of namespaces is making people create all kinds of "design 
>> patterns".
>> 
>> struct API {
>> static let endpoint = "http://example.com/api";
>> }
>> 
>> Here is an "improvement" to the above "design pattern" to prevent 
>> instantiating API:
>> 
>> struct API {
>> private init() {}
>> static let endpoint = "http://example.com/api";
>> }
>> 
>> Finally, here is another "improvement" that uses enum instead of struct to 
>> avoid having to write the private initializer:
>> 
>> enum API {
>> static let endpoint = "http://example.com/api";
>> }
>> 
>> I doubt any of you find this beautiful. Yet these "design patterns" (just 
>> hacks IMO) are spreading like the plague because of the lack of namespaces.
>> 
>> What do you think?
> 
> Personally, I’m in favor of namespaces, but it’s more of a “seems like a good 
> idea” thing than “I need this because ”, at least from my PoV. I’m 
> inclined to just defer to the core team’s judgement on this one.
> 
> On the plus side though, if we ever do get formal namespaces, it should be 
> relatively simple to search for enums with no cases and give a fixit.
> 
> - 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] Warning when omitting default case for imported enums

[Rien via swift-evolution]

-1

Reason 1: the “negative” behaviour you describe is actually exactly what I want 
to happen.
Reason 2: Introducing a warning would also necessitate a warning suppression in 
order to have your code compile without warnings. But when you suppress, the 
purpose of the warning is nul and void.

PS: I would suggest not to use an enum in cases where this is really annoying 
and replace the enums with constants.
 
Regards,
Rien

Site: http://balancingrock.nl
Blog: http://swiftrien.blogspot.com
Github: http://github.com/Balancingrock
Project: http://swiftfire.nl





> On 07 Feb 2017, at 16:12, Tanner Nelson via swift-evolution 
>  wrote:
> 
> Hello Swift Evolution,
> 
> I'd like to propose that a warning be emitted when default cases are omitted 
> for enums from other modules. 
> 
> What this would look like:
> 
> OtherModule:
> ```
> public enum SomeEnum {
> case one
> case two
> }
> 
> public let global: SomeEnum = .one
> ```
> 
> executable:
> ```
> import OtherModule
> 
> switch OtherModule.global {
> case .one: break
> case .two: break
> ^ ⚠︎ Warning: Default case recommended for imported enums. Fix-it: 
> Add `default: break`
> }
> ```
> 
> Why:
> 
> Allowing the omission of a default case in an exhaustive switch makes the 
> addition of a new case to the enum a breaking change. 
> In other words, if you're exhaustively switching on an enum from an imported 
> library, the imported library can break your code by adding a new case to 
> that enum (which the library authors may erroneously view as an 
> additive/minor-bump change).
> 
> Background:
> 
> As a maintainer of a Swift framework, public enums have been a pain point in 
> maintaining semver. They've made it difficult to implement additive features 
> and have necessitated the avoidance of enums in our future public API plans.
> 
> Related Twitter thread: 
> https://twitter.com/tanner0101/status/796860273760104454
> 
> Looking forward to hearing your thoughts.
> 
> Best,
> Tanner
> 
> Tanner Nelson
> Vapor 
> +1 (435) 773-2831
> 
> 
> 
> 
> 
> 
> 
> ___
> 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