Re: [swift-evolution] Swift source mentorship program

[Jay Abbott via swift-evolution]

I think that "we don't have time to implement this time-saving
project-accelerating quality-improving thing" is widely recognised as an
anti-pattern (or anti-process if that’s a thing) these days, and I’d hope
Apple would find a way to avoid this problem. :)
​

On Mon, 14 Aug 2017 at 21:44 Jacob Williams <ponybo...@gmail.com> wrote:

> A Swift developer has actually started a blog series about the swift
> compiler. The links to his post were posted in one of the evolution topics
> a little while ago. The series is incomplete, but it gives a lot of
> explanations about the various parts of the swift compiler.
>
>
> https://medium.com/@slavapestov/the-secret-life-of-types-in-swift-ff83c3c000a5
>
> https://medium.com/@slavapestov/how-to-talk-to-your-kids-about-sil-type-use-6b45f7595f43
>
> I wholeheartedly agree that a mentorship program would be extremely useful
> for helping others get up-to-speed with the swift compiler. I myself wished
> I understood it better. The only problem is that with something so large
> and complex, it would take a lot of time and effort to document and create
> a tutorial for it. I wish that this would happen, but I don’t know that
> anyone at Apple has the time and there probably aren’t very many people
> outside of apple with the know-how and time to write a tutorial as a hobby.
> I hope that I’m wrong though.
>
>
> On Aug 14, 2017, at 2:35 PM, Jay Abbott via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> I think we should have some kind of mentorship program for the swift
> source. I'm confident that my following statement doesn't apply to just me:
>
> "I'd love to get involved in the source a lot more, and my previous
> efforts to browse around and understand it a bit better have been thwarted
> by lack of time, a specific goal/direction, and no proper commitment (all
> my own failings of course). I'd be happy to learn the code and implement
> proposals, but I really want someone to turn to when I need some help and
> guidance."
>
> In addition to the core team, I think there are a few others who know the
> code well enough, and who may be willing to mentor and share that knowledge
> further. Having a specific mentor makes it much easier to get to a level
> where you feel comfortable talking to the wider development community on
> swift-dev for example.
>
> There would need to be some level of self-starting bar, which would need
> to be supported by some documentation to read, and some simple
> tasks/tutorials to complete (For example create a branch which removes an
> existing feature and a tutorial to re-implement it, that touches a few key
> areas of the code-base). The swift project and the evolution process would
> benefit by having more potential implementors, so writing such
> documentation and getting-started guides should be a high priority in order
> to help people get more involved. Once complete, it would be great to
> choose a proposal, find a mentor, and start work on it under their guidance.
>
> I believe effort focused in this area will have a high return, given the
> high quality and quantity of passion and talent I see in this list.
>
> ___
> 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] Swift source mentorship program

[Jay Abbott via swift-evolution]

I think we should have some kind of mentorship program for the swift
source. I'm confident that my following statement doesn't apply to just me:

"I'd love to get involved in the source a lot more, and my previous efforts
to browse around and understand it a bit better have been thwarted by lack
of time, a specific goal/direction, and no proper commitment (all my own
failings of course). I'd be happy to learn the code and implement
proposals, but I really want someone to turn to when I need some help and
guidance."

In addition to the core team, I think there are a few others who know the
code well enough, and who may be willing to mentor and share that knowledge
further. Having a specific mentor makes it much easier to get to a level
where you feel comfortable talking to the wider development community on
swift-dev for example.

There would need to be some level of self-starting bar, which would need to
be supported by some documentation to read, and some simple tasks/tutorials
to complete (For example create a branch which removes an existing feature
and a tutorial to re-implement it, that touches a few key areas of the
code-base). The swift project and the evolution process would benefit by
having more potential implementors, so writing such documentation and
getting-started guides should be a high priority in order to help people
get more involved. Once complete, it would be great to choose a proposal,
find a mentor, and start work on it under their guidance.

I believe effort focused in this area will have a high return, given the
high quality and quantity of passion and talent I see in this list.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Pitch] `let` in protocols

[Jay Abbott via swift-evolution]

I think if we start to discuss composition as part of the language, it
could solve this issue.

In my composition pitch I didn’t go into great detail (and nothing about
properties in components at this early stage - I figured I should start
simple and we can think it through further as a group), but if we had a
syntax for composing types out of components (implementations of
protocols), you could include a guarantee that a component were initialised
in init. This would also solve the partial initialisation issue - as a
component is a complete implementation of a particular protocol, which can
be fully initialised itself, before the composed type is fully initialised.
​

On Tue, 27 Jun 2017 at 00:00 Karl Wagner via swift-evolution <
swift-evolution@swift.org> wrote:

>
> On 26. Jun 2017, at 13:44, Karl Wagner  wrote:
>
>
> On 25. Jun 2017, at 22:13, Robert Bennett  wrote:
>
> For a concrete type, a partial initializer is a function that:
> Can set `let` instance variables
> May not refer to `self` in an rvalue
> Must set the same subset of instance variables regardless of the code path
> taken
>
> For a protocol, a partial initializer is simply a function that sets *any*
> subset of the instance variables. A protocol could provide a default
> implementation of one. In order for this `let` proposal to work, though, if
> a `let` variable is set in the protocol extension’s implementation of a
> (full) initializer, the protocol would need to provide at least one partial
> initializer that it does not provide an implementation for, so that a
> conforming type can fill in the gaps for all of the instance variables it
> defines that the protocol doesn’t require/know about. That way the compiler
> can have faith that a conforming type will be able to fully initialize
> itself with the default implementation of the required full initializer.
>
>
> I’ll say again: I think you’re approaching this from the wrong angle. You
> want stronger guarantees about mutability of properties, but the answer is
> not to make protocols be more restrictive about how conformers are written.
>
> What you are really asking for is the guarantee that some type which
> conforms to SomeProtocol has value-semantics. Once you have that guarantee,
> you know that you have a unique instance whose properties will only mutate
> if they are stored in a “var” property and you yourself mutate it.
>
> For example, an Array’s “count” property is technically a computed
> property, but in a “let”-declared Array you can treat it as a “let”
> constant because Arrays have value semantics. Your guarantees about
> properties only being set in the initialiser would automatically be
> fulfilled without the need of any additional alternate initialisation
> patterns.
>
> - Karl
>
>
> Just to expand on this a little bit, as I see it there are two parts to
> your problem. First, you were asking for some kind of
> partial-initialisation. Second, you (or somebody) mentioned that there
> might be optimisation benefits.
>
> Here’s a kind of partial initialisation you can use right now:
>
> public protocol SomeProtocol {
> var neverReallyMutatesAfterInit: String { get }
> }
>
> public extension SomeProtocol {
> static func withProtocolDefaults() -> SomeProtocol? {
> return (Self.self as? PartiallyInitializableSomeProtocol.Type).map
> { $0.withProtocolDefaults() }
> }
> }
>
> internal protocol PartiallyInitializableSomeProtocol: SomeProtocol {
>
> /// Creates an object with type-specific defaults.
> init()
>
> /// Allows customisation by the protocol after init.
> var neverReallyMutatesAfterInit: String { get set }
> }
>
> internal extension PartiallyInitializableSomeProtocol {
>  static func withProtocolDefaults() -> SomeProtocol {
> var newValue = Self()
> newValue.neverReallyMutatesAfterInit = "ProtocolDefault"
> return newValue
> }
> }
>
> public struct SomeConformer: PartiallyInitializableSomeProtocol {
> public internal(set) var neverReallyMutatesAfterInit = "TypeDefault"
> internal init() {}
> }
>
> (SomeConformer.self as
> SomeProtocol.Type).withProtocolDefaults()?.neverReallyMutatesAfterInit //
> "ProtocolDefault"
>
>
> With this example, the only way users of your library can obtain an
> instance is via the protocol function, which knows that it can construct a
> default instance and specialise the values.
>
> As far as optimisation goes - I have to correct myself, because even in a
> protocol existential whose underlying type is known to have value
> semantics, computed properties themselves might not. For all the compiler
> knows, they could be reading/writing from global state. So the compiler
> can’t really eliminate repeat accesses unless it knows the underlying
> implementation (or we give it more information about how the content
> mutates). People have asked about marking stored/computed properties in
> protocols before, and I’ve 

Re: [swift-evolution] [pitch] composition as part of the language

[Jay Abbott via swift-evolution]

Today I had a read through the various protocol forwarding threads in
December 2015, including Matthew Johnson's proposal, and some more recent
ones in which it was discussed.

I think the ideas are very similar in many ways - it's to improve the
experience of using composition and make it easier. The protocol forwarding
seems to be mostly about reducing boilerplate code, but I'd really like to
see composition become part of the language itself. One of the fantastic
thing about the evolution of programming languages is how programmers
discover many good and bad patterns, then we make new language features to
incorporate the good patterns and mitigate against the bad ones. Data and
pointer types, classes/objects, inheritance, abstract interfaces, to name
but a few are all derived from good disciplined practice, codified such
that they become easier, or required practices.

The protocol forwarding proposal is great, but it seems like the good
pattern/practice it is trying to aid (composition) would still be a
programmer discipline that sits atop that particular language feature. Does
anyone else think encouraging composition directly as a language feature
would be a good thing? A new platform-level on top of which we can develop
new good and bad patterns, to continue the evolution? It's apparent from
other active threads on this list that composition over inheritance is
still not widely followed. I still make this same mistake. I remember going
from C++ to Java (this was probably around 17 years ago now) I often wanted
multiple inheritance, but the language wouldn't let me and I soon realised
the error of my ways and the power of interfaces. This is the great power
of a well designed language feature - it forces programmers to improve
their thinking while making it easier to write better code at the same
time. These days we can easily compose interfaces (in Swift for example we
can adopt multiple protocols, or use protocol composition) but we still
can't easily compose implementations. We tend to use delegates for
composition, and auto-forwarding seems to be a good approach for making
this pattern easier, but composing a type's implementation from other
existing component implementations is subtly different to delegation.

So instead of wanting to inherit from a struct, or forward a protocol to
avoid boilerplate, I want composition to be a natural and easy way to think
of a particular type, and I want the language and compiler to nudge my
thinking towards this way when I start to do something stupid. Is anyone
with me on this or am I just out there talking crazy?

In the specifics of this case, there seem to be some issues with `Self`
parameters and return types in the protocol forwarding proposal. Also, the
idea of a lot of synthesized boilerplate to forward calls seems a bit
messy. Perhaps it would be good if composition were able to pull in
implementations like templates. So `Self` types become the type of the
composed type, and the compiler decides when it needs to generate a
type-specific version or when to use a generic version of an
implementation. And the intention would be very clear because a component
of a composition would be explicitly named something obvious like
`component`.

It'd be great to hear Matthew Johnson's thoughts on this, and anyone else
who has been involved with the forwarding discussions.


On Fri, 23 Jun 2017 at 14:29 Nevin Brackett-Rozinsky <
nevin.brackettrozin...@gmail.com> wrote:

> This sounds similar to automatic protocol forward, have you looked into
> prior discussions on that topic here?
>
> Nevin
>
>
> On Thu, Jun 22, 2017 at 10:56 PM, Jay Abbott via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>> Let's take a quick look at how we can achieve very simple compile-time
>> composition in Swift today.
>>
>> I want to define a `Doorman` behaviour, and I want to compose it from
>> other behaviours that are shared by some of my other staff types:
>>
>> ```swift
>> protocol Greeter {
>> func greet()
>> }
>> protocol Fareweller {
>> func farewell()
>> }
>> protocol Doorman: Greeter, Fareweller {}
>> ```
>>
>> Great - that's my interface defined, now some implementations that I can
>> compose my staff from:
>>
>> ```swift
>> protocol FriendlyGreeter: Greeter {}
>> extension FriendlyGreeter {
>> func greet() {
>> print("Hello and welcome")
>> }
>> }
>>
>> protocol FriendlyFareweller: Fareweller {}
>> extension FriendlyFareweller {
>> func farewell() {
>> print("I bid thee farewell")
>> }
>> }
>>
>> protocol InsultingGreeter: Greeter {}
>> extension InsultingGreeter {
>> func greet() {
>> print("You make me sick")
>

Re: [swift-evolution] ability to derive a class from a struct or other value type

[Jay Abbott via swift-evolution]

What you're really after isn't "inheriting" from structs, you want to
easily "compose" your classes (or structs) using the implementation from
other implementation structs (components). I made a separate post all about
this - how to make composition part of the language.

On Fri, 23 Jun 2017 at 01:15 Mike Kluev via swift-evolution <
swift-evolution@swift.org> wrote:

> On 23 June 2017 at 02:43, Tony Allevato  > wrote:
>
>> There's been talk about "protocol forwarding" that I think would achieve
>> a lot of these goals, without the sharp edges involved trying to define
>> inheritance between a class and a struct. The proposed feature would
>> eliminate the boilerplate you're talking about.
>>
>> I'm on my phone so I can't pull up links to old discussions, but Matthew
>> Johnson is who was pushing it so you may want to look back at what he's
>> said on the topic.
>>
>
> thanks, i skimmed through it now and will have a closer look later.
> does it address (2) though? (preexisting value types we can't change)
>
> as to the sharp edges: i do not see a single one in the "manual"
> implementation of this approach and the idea of this proposal is that it is
> equivalent to the manual implementation...
>
> Mike
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

[swift-evolution] [pitch] composition as part of the language

[Jay Abbott via swift-evolution]

Let's take a quick look at how we can achieve very simple compile-time
composition in Swift today.

I want to define a `Doorman` behaviour, and I want to compose it from other
behaviours that are shared by some of my other staff types:

```swift
protocol Greeter {
func greet()
}
protocol Fareweller {
func farewell()
}
protocol Doorman: Greeter, Fareweller {}
```

Great - that's my interface defined, now some implementations that I can
compose my staff from:

```swift
protocol FriendlyGreeter: Greeter {}
extension FriendlyGreeter {
func greet() {
print("Hello and welcome")
}
}

protocol FriendlyFareweller: Fareweller {}
extension FriendlyFareweller {
func farewell() {
print("I bid thee farewell")
}
}

protocol InsultingGreeter: Greeter {}
extension InsultingGreeter {
func greet() {
print("You make me sick")
}
}

protocol InsultingFareweller: Fareweller {}
extension InsultingFareweller {
func farewell() {
print("Get lost")
}
}
```

Now we have two kinds of `Greeter` and two kinds of `Fareweller` that can
be used to compose different `Doorman` types (and potentially other staff
types). Here's two examples:

```swift
struct FriendlyDoorman: Doorman, FriendlyGreeter, FriendlyFareweller {}
struct TrickingDoorman: Doorman, FriendlyGreeter, InsultingFareweller {}
```

I can instantiate and make use of these to perform their defined behaviours:

```swift
let friendly: Doorman = FriendlyDoorman()
let tricking: Doorman = TrickingDoorman()
friendly.greet() // Hello and welcome
friendly.farewell() // I bid thee farewell
tricking.greet() // Hello and welcome
tricking.farewell() // Get lost
```

It works! But there are some things that could be nicer:
* I don't really want `***Greeter` or `***Fareweller` to be sub-protocols
at all, these are supposed to be implementations - the only reason they are
protocols is so I can extend them with a default implementation and then
use more than one of them to compose my actual `Doorman` types. This
clutters up the namespace with unnecessary protocols, that have the same
interface as their parent.
* Since the `***Doorman` types need to be instantiable, they are structs. I
couldn't compose a `LobbyMultiTasker` from a `FriendlyDoorman` and a
`GrumpyPorter` at compile-time, the same easy way I composed the
`***Doorman` types. The manual solution would be to add properties for
`doormanDelegate` and `porterDelegate` and assign appropriate instances
(run-time composition), then add the boiler-plate to pass on the
`LobbyMultiTasker` behaviour to these delegates. This is also how the
compiler could implement this feature.
* Actually providing the implementations is optional for the protocols (the
extensions can happily be missing), meaning any error messages will appear
in the types that fail to fully implement the protocols, instead of here in
my `***Greeter` implementation.

So I'd like to discuss the possibility of a new category of types called
`component`, to allow compile-time composition; composition as part of the
language. The `***Greeter` and `***Fareweller` might look like this:

```swift
component FriendlyGreeter: Greeter {
func greet() {
print("Hello and welcome")
}
}

component FriendlyFareweller: Fareweller {
func farewell() {
print("I bid thee farewell")
}
}

component InsultingGreeter: Greeter {
func greet() {
print("You make me sick")
}
}

component InsultingFareweller: Fareweller {
func farewell() {
print("Get lost")
}
}
```

And the `TrickingDoorman` might look like this:

```swift
component TrickingDoorman: Doorman⎄(FriendlyGreeter, InsultingFareweller) {
// optionally override any Doorman-defined functions
}


```

Here's how I think they would work:

* Components must conform to at least one protocol.
* Components must provide an implementation for all the things from the
protocols - no part of it is 'abstract' - and they can't provide extra
things (although it might be useful to allow some kind of config-values,
but I'd say initially keep it simple).
* Components can be composed of other components and override some/all of
the borrowed behaviour. This should provide well defined
multiple-inheritence semantics (not sure of details), some syntax would be
required to allow the compiler to totally flatten the component, selecting
which "parent" implementations to use if needed to satisfy all the
protocols. Only the functions from the explicit protocols are pulled in,
not everything implemented in the "parent" components.
* Components can be instantiated and have value-semantics, like structs
(they are basically structs with extra features/checks). They can therefore
be used at compile-time but also at run-time for example `delegate =
MyComponent()` - so composed behaviour can be either static or dynamic,
also existing protocol-based `delegate` variables can have a component
instance assigned.
* Classes, structs, and enums can NOT 

[swift-evolution] out of scope proposals

[Jay Abbott via swift-evolution]

Hey all - I haven't been keeping up for a few months, but I just found a
small change in my swift-evolution repo that I made in response to a thread
here, but I obviously got distracted because I never committed it.

I added a file to track out-of-scope proposal discussions (idea is it would
link to threads on this list, and possibly other places), and linked it
from the README.

Would this still be useful? Shall I make a PR with it or just bin it?

Ta,
J
___
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

[Jay Abbott via swift-evolution]

>From a clarity at point of use point of view areAll is the best suggestion
so far. Even when other variables or methods aren’t named very well, it
suggests both the plural nature of the thing being operating on, and the
boolean nature of the return value, for example:

yourBase.areAll { $0.belong(to: us) }

It also tips the hat to all but without the confusing filter-like
expectations.
​

On Wed, 5 Apr 2017 at 23:45 Jonathan Hull via swift-evolution <
swift-evolution@swift.org> wrote:

> On that note: ‘containsOnly' is still my favorite by a wide margin.  I
> know it is longer than ‘all’, but it’s behavior is much clearer (especially
> for those of us who have never used or heard of ‘all’ in other languages),
> and it’s relationship with ‘contains’ is also very clear.
>
> Thanks,
> Jon
>
>
>
> On Apr 5, 2017, at 3:06 PM, Jarod Long via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> I don't think an argument label is sufficient to satisfy the first
> fundamental API design guideline: "Clarity at the point of use is your most
> important goal."
>
> The argument label is not visible at the point of use when using trailing
> closure syntax, so it provides no additional clarity there. Moving the
> argument label into the base method name solves that problem and I think is
> a clear case of satisfying the second fundamental guideline: "Clarity is
> more important than brevity."
>
> Jarod
>
> On Apr 5, 2017, 14:51 -0700, Kevin Nattinger via swift-evolution <
> swift-evolution@swift.org>, wrote:
>
> I definitely think we should stick with `all` and an appropriate argument
> label. It’s a term of art and the label makes it perfectly clear what to
> expect.
> That said, `all(match)` and `all(equal)` sound to me like they expect an
> object to compare each against (func all(equal needle: Element))
> I suggest something like `all(pass:)`.
>
> On Apr 5, 2017, at 4:34 PM, Brandon Trussell via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> I retract my gripes on the original names also.  The argument labels make
> the intent of the method clear.
>
> On Wed, Apr 5, 2017 at 11:23 AM, Thorsten Seitz via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> +1
>
> Am 03.04.2017 um 10:29 schrieb Daniel Duan via swift-evolution <
> swift-evolution@swift.org>:
>
> I want to retract my nitpickings on argument labels; `all(equal:)` and
> `all(match:)` are the best names for these methods.
>
> things all match condition?
> things all equal value?
>
> If we accept `all` as a term of art (which I think we should), along with
> these labels the use site are very readable!
>
> On Mar 31, 2017, at 6:38 PM, Daniel Duan via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> nit: should these names be `all(matching)`/`all(equalTo)` per API Design
> Guidelines?
>
> On Mar 31, 2017, at 8:28 AM, Ben Cohen via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> Hi,
>
> A short proposal for you as part of the algorithms theme. Hopefully
> non-controversial, aside from the naming of the method and arguments, about
> which controversy abounds. Online copy here:
> https://github.com/airspeedswift/swift-evolution/blob/9a778e904c9be8a3692edd19bb757b23c54aacbe/proposals/0162-all-algorithm.md
>
>
> Add an all algorithm to Sequence
>
>- Proposal: SE-
>- Authors: Ben Cohen 
>- Review Manager: TBD
>- Status: *Awaiting review*
>
> Introduction
>
> It is common to want to confirm that every element of a sequence equals a
> value, or matches a certain criteria. Many implementations of this can be
> found in use on github. This proposal adds such a method to Sequence.
> Motivation
>
> You can achieve this in Swift 3 with contains by negating both the
> criteria and the result:
>
> // every element is 9
> !nums.contains { $0 != 9 }// every element is odd
> !nums.contains { !isOdd($0) }
>
> but these are a readability nightmare. Additionally, developers may not
> make the leap to realize contains can be used this way, so may hand-roll
> their own for loop, which could be buggy, or compose other inefficient
> alternatives:
>
> // misses opportunity to bail early
> nums.reduce(true) { $0.0 && $0.1 == 9 }// the most straw-man travesty I could 
> think of...Set(nums).count == 1 && Set(nums).first == 9
>
> Proposed solution
>
> Introduce two algorithms on Sequence which test every element and return
> true if they match:
>
> nums.all(equal: 9)
> nums.all(match: isOdd)
>
> Detailed design
>
> ___
> 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
> 

Re: [swift-evolution] protocol-oriented integers (take 2)

[Jay Abbott via swift-evolution]

I barely understand any of this thread, so these might be silly questions,
or based on a total misunderstanding the goals here, but it seems to be
about: a) clever/advanced mathsy things; b) naming things; and c) the
standard library... my questions are:

Do specialised clever advanced mathsy libraries all work exactly the same,
or do they have slightly different behaviours or conventions or semantics
in different fields of study?

Is the the goal here to define a common/shared sub-set of specialised maths
libraries, but in the standard library? Would that be useful by itself?

Could it be possible that "naming things" in the standard library would
trample all over possible uses in external libraries, making it harder
rather than easier for specialised maths libraries to construct their
interfaces in a non-confusing way?


On Tue, 17 Jan 2017 at 01:39 Dave Abrahams via swift-evolution <
swift-evolution@swift.org> wrote:

>
> on Mon Jan 16 2017, Xiaodi Wu  wrote:
>
> > Strideable? I didn't think Strideable itself was going away. I'd be sad
> if
> > it did; for one, all the Unsafe*Pointers are Strideable and that has its
> > uses.
>
> Nobody's proposing to remove Strideable.
>
> --
> -Dave
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Code comments that check code validity.

[Jay Abbott via swift-evolution]

I think this would be an anti-feature , here are some reasons why:

   - If it is code you wrote as an idea for how something might be
   implemented in the future, then it should be manually tweaked/validated
   anyway when you put it back in. If things change slightly such that your
   old commented code breaks when you comment it back in this is a good thing,
   it forces you to check/amend the old code so that it functions properly in
   the updated environment that it now inhabits.
   - If it’s a significant amount of code then it really ought to be
   structured into something appropriate, like a function or a class, in which
   case it can happily live uncalled and not commented out. But it’s not a
   great practice to leave unused code lying around, unless you know it’s
   going to be used soon.
   - Commented code is often commented out specifically to make things
   compile while you tweak/break things somewhere else (i.e. commented out
   temporarily) - so of course you don’t want it to be compiled.
   - If you comment out code temporarily then it really should just mean
   temporarily, i.e. between now and your next commit to test something
   immediately. Source control means there’s no need for longer-lived
   commented out code. Unfinished code can live on a branch, old code that you
   might want to refer to or re-use later is in your source control history,
   and unused code should probably just be removed.
   - Code that is written and working and intended to be enabled later on
   should be activated by a feature-toggle (either a compile-time or a
   run-time one) rather than commented out.

​

On Sun, 15 Jan 2017 at 00:04 Amir Michail via swift-evolution <
swift-evolution@swift.org> wrote:

>
> On Jan 14, 2017, at 6:56 PM, Xiaodi Wu  wrote:
>
>
>
> On Sat, Jan 14, 2017 at 5:50 PM, Amir Michail  wrote:
>
>
> On Jan 14, 2017, at 6:46 PM, Xiaodi Wu  wrote:
>
> On Sat, Jan 14, 2017 at 5:35 PM, Amir Michail  wrote:
>
>
> > On Jan 14, 2017, at 6:28 PM, Xiaodi Wu  wrote:
> >
> > This has been brought up on this list before. The conclusion of the
> previous thread on this topic was that there is a way to do this:
> >
> > #if false
> > // put your code here
> > #endif
> >
>
> This would not check the code for compilability within the surrounding
> code. This requires more than a syntax check.
>
>
> I can't say I've ever needed that feature; could you share a concrete use
> case?
>
>
> Consider an array of levels for a game where some levels are commented out
> for possible future use. It would be nice to have such level entries
> continue to compile as the code elsewhere evolves and yet not be included
> in the executable.
>
>
> ```
> enum Levels: Int {
>   case foo = 1, bar, baz, boo
> }
>
> var levels: [Levels] = [
>   .foo,
>   .bar,
> ]
>
> // disabled
> _ = {
>   levels += [
> .baz,
> .boo,
> // this won't compile if you add:
> // .nonExistent,
>   ]
> }
> ```
>
>
> That’s helpful thanks! I still think code comments would be nice though.
>
>
> ___
> 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

[Jay Abbott via swift-evolution]

Thanks for pointing this out Tim. I had actually read the whole thread but
over a few days between other things and must have missed the relevant
updates.

I think you may be reacting to the very first draft. `extension` isn't used
> at all in the newest draft, and no code can exist outside the enum. In
> fact, there's a fair amount of similarity to your idea in the newest
> proposal.
>
> https://gist.github.com/timshadel/5a5a8e085a6fd591483a933e603c2562
>
>
Oh yes - this is much better! Lovely in fact. Although it does lose the
benefit of at-a-glance understanding of the cases present in the enum when
they are on one line each (when the code gets bigger than in the example
they will be quite a way apart).
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Allow ' in variable/constant names?

[Jay Abbott via swift-evolution]

Georgios - the problem with that character is that it's an apostrophe in
Unicode, not a single-quote. It was originally overloaded as both in ASCII
though hence commonly used as either, especially in programming languages.
I'm definitely with Ted Clancy on this one:
https://tedclancy.wordpress.com/2015/06/03/which-unicode-character-should-represent-the-english-apostrophe-and-why-the-unicode-committee-is-very-wrong/

I generally don't care what characters my editor/email client/browser/etc.
use when I type ' on the keyboard, because a human reader will understand
it, so I just do the quickest/easiest thing. But when I'm writing a TeX
document I take care to use an apostrophe where needed and left/right
single quotation marks where needed. And for coding I'd like to be precise,
specific, unambiguous, and technically correct, so either single or double
quotation marks (or ‹ and ›) would be acceptable for character literals. If
compiler can cope with double quotes for both string and character literals
in an unambiguous way then that's fine too.

On Thu, 12 Jan 2017 at 14:35 Georgios Moschovitis <
george.moschovi...@icloud.com> wrote:

> So yeah, solution is to make characters easier to type, not modify the
> language.
>
>
> +1
>
> If like me you don't have such a keyboard, you can always use ctrl+⌘+
>  and type ‘PRIME’ to find it, then pick it from recently
> used/favourites.
>
> Regarding the other point, I agree that character literals would be handy,
> but again I’m not sure if apostrophe is the right character to indicate it.
> Although it is familiar, perhaps LEFT SINGLE QUOTATION MARK and RIGHT
> SINGLE QUOTATION MARK would be better, they can be relatively easily typed
> with ⎇+] and ⎇+⇧+] respectively. Xcode could also convert two apostrophes
> into ‘’ for you and your fingers would quickly learn to type ' ' ← ‹char›.
>
> I think the single (ASCII) quote is standard enough for use as a character
> delimiter.
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Allow ' in variable/constant names?

[Jay Abbott via swift-evolution]

As Rob Mayoff pointed out, you can use MODIFIER LETTER PRIME - or PRIME,
DOUBLE PRIME, and TRIPLE PRIME - which makes more sense than an apostrophe.
Now if only there were a keyboard that had a touch-screen at the top which
could be used for typing context-sensitive characters that would otherwise
be difficult to type. So yeah, solution is to make characters easier to
type, not modify the language. If like me you don't have such a keyboard,
you can always use ctrl+⌘+ and type ‘PRIME’ to find it, then pick it
from recently used/favourites.

Regarding the other point, I agree that character literals would be handy,
but again I’m not sure if apostrophe is the right character to indicate it.
Although it is familiar, perhaps LEFT SINGLE QUOTATION MARK and RIGHT
SINGLE QUOTATION MARK would be better, they can be relatively easily typed
with ⎇+] and ⎇+⇧+] respectively. Xcode could also convert two apostrophes
into ‘’ for you and your fingers would quickly learn to type ' ' ← ‹char›.


On Wed, 11 Jan 2017 at 22:07 David Sweeris via swift-evolution <
swift-evolution@swift.org> wrote:


> On Jan 11, 2017, at 15:41, Joe Groff via swift-evolution <
swift-evolution@swift.org> wrote:
>
>
>> On Jan 11, 2017, at 5:16 AM, Charlie Monroe via swift-evolution <
swift-evolution@swift.org> wrote:
>>
>> -1. Why? Why not use foo2 instead? Is ' so much better?
>>
>> Instead, I'd personally love better character support in Swift in the
future and allow a Character literals using ' - just like in C, except with
Unicode support:
>>
>> let myChar = 'x' // Character
>> let myChar2 = '∃' // Character
>> let myChar3 = '\0' // NUL Character
>> let myChar4 = 'xyz' // Error from compiler
>
> These aren't necessarily mutually exclusive. If we require that an
identifier can't start with an apostrophe, then we can support identifiers
named `x'` and `'x'` as some kind of literal simultaneously.
>
> I'm sympathetic to this since I personally find x', x'', etc. more
attractive than x2, x3, etc. for totally superficial math weenie reasons,
but although the surface level language design is fairly straightforward,
the downstream tooling impact is nontrivial—we'd need a mangling for ' in
symbol names, simplified parsing tools would need to cope with ', tools
that attempt to parse out identifiers from error messages would have to
deal with apostrophe-unsafe output, etc. Not sure it's worth it.

Out of curiosity, instead of coming up with another mangling scheme, how
hard would it be to add ' support to the downstream tooling? It's all open
source, right?

- 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] Consolidate Code for Each Case in Enum

[Jay Abbott via swift-evolution]

I like the idea behind this, but I think the proposed syntax abuses
extension, which applies to types not individual cases. Putting the code
outside the enum also seems wrong, and it’s difficult to see how the
compiler would handle it, in particular ensuring exhaustiveness. So I have
come up with an alternate syntax using the example from the proposal that I
think works a bit better (or at least might inspire someone else to improve
it further):

enum TokenState {
case expired(at: Date)
case validated(token: String)

caseprotocol { // (1)
mutating func react(to event: Event)
var description: String
}
caseimpl<.expired(let at)> { // (2)
var description: String {
return "Expired at \(at)"
}
mutating func react(to event: Event) {
switch event {
case _ as TokenRefreshed:
self = .validated(token: event.token)
default: break
}
}
}
caseimpl<.validated(let token)> { // (3)
var description: String {
return "Token \(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
}
}
}
// (4)
}

I find this easier to parse manually, and I think the compiler would too…

   - At (1) it is equivalent to defining a normal protocol outside the
   enum. The enum itself would implicitly conform to this protocol. Calculated
   properties would be implicitly get-only in the protocol.
   - At (2) and (3) this would be equivalent to defining a static object
   that conforms to a compiler-modified version of the protocol, with static
   implementations of the getters/functions. Mutating functions would have an
   inout ref to self and they would all have any associated values sent in
   as per the let in the caseimpl declaration. The body would come directly
   from the programmer code.
   - At (4) the compiler would generate the enum’s implementation to
   conform to the protocol, this would switch on self and call the
   appropriate static functions. As per the original proposal.

It might be good if you don’t have to repeat all the func signatures in
each caseimpl - I considered a different syntax where you defined a casefunc
(similar to a typealias) like casefunc ReactTo = mutating func react(to
event: Event) then in the caseimpl you could just do ReactTo = { func body
here } but it didn’t seem to fit. Hopefully someone else will have some
ideas to reduce the repetition.
​
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Cancelable named defer statements

[Jay Abbott via swift-evolution]

A closure assigned to a variable is already a named handler…
Make it optional and it’s now a cancelable named handler…
Put it in a defer block and you have exactly what you want, a cancelable
named defer handler…

func doSomething(input: String) -> String? {

// Create a cancelable named defer handler
var namedDeferHandler: (() -> Void)? = { print("It didn't work,
but I've taken care of any cleaning up.") }
defer { namedDeferHandler?() }

// Check the input
if input == "" { return nil }

// Cancel the named defer handler
namedDeferHandler = nil

return "It worked!"
}

It’s very flexible, you can have multiple handlers and cancel only some of
them, include some non-optional code in the defer block itself, etc.
​

On Sat, 7 Jan 2017 at 18:45 Charles Srstka via swift-evolution <
swift-evolution@swift.org> wrote:

> > On Jan 7, 2017, at 12:40 PM, D. Felipe Torres via swift-evolution <
> swift-evolution@swift.org> wrote:
> >
> > Any cancelable defer addition we could come up with will need a
> flag/state to indicate so, which won't be that much different from what you
> wrote.
> >
> > Having said that, for your example may I suggest this approach instead:
> >
> > func openFile(kind: String) -> UnsafeMutablePointer? {
> >
> > var file = fopen("MyFile.txt", "r")
> > guard  fileIsValid(file)
> > && fileContainsData(file, kind)
> > && !fileDataOutOfDate(file) else {
> > fclose(file)
> > }
> >
> > return file
> > }
>
> Or:
>
> func openFile(kind: String) -> UnsafeMutablePointer? {
> var file = fopen("MyFile.txt", "r”)
>
> do {
> if fileIsNotValid(file) { throw MyError.fileIsNotValid }
>
> if fileDoesNotContainsData(file, kind) { throw
> MyError.doesNotContainData }
>
> if fileDataOutOfDate(file) { throw MyError.dataOutOfDate }
>
> return file
> } catch {
> fclose(file)
> }
> }
>
> 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] [Thoughts?][Phase2] default arguments and trailing closure syntax

[Jay Abbott via swift-evolution]

Some good arguments regarding warnings and multiple closures. But I can't
help that feel when designing an API, if you have to add a convenience
method that takes just one closure simply to call the real method, this is
exactly the sort of boilerplate code that default arguments are supposed to
replace.

On Thu, 5 Jan 2017 at 05:48 Douglas Gregor <dgre...@apple.com> wrote:

> On Jan 4, 2017, at 9:44 PM, Saagar Jha <saa...@saagarjha.com> wrote:
>
> So, then this should have a warning? I’m still not getting one.
>
> func foo(a: () -> (), b: (() -> ())? = nil, c: Int) {
> a()
> b?()
> }
>
> foo(a: {
> print(“Bar”)
> }, c: 0)
>
>
> If you give “c” a default value (e.g., “= 0”), it will give a warning.
>
> I’m happy for the warning to get more eager, so long as it also gets a
> Fix-It at the same time.
>
> - Doug
>
> Saagar Jha
>
>
>
> On Jan 4, 2017, at 9:34 PM, Douglas Gregor <dgre...@apple.com> wrote:
>
>
> On Jan 4, 2017, at 9:32 PM, Saagar Jha <saa...@saagarjha.com> wrote:
>
>
>
> Saagar Jha
>
>
>
> On Jan 4, 2017, at 8:35 PM, Douglas Gregor <dgre...@apple.com> wrote:
>
>
> On Jan 4, 2017, at 7:48 PM, Saagar Jha via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> Check out this thread
> <https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160606/020470.html>–it’s
> very similar to what you proposed, but it didn’t go anywhere. FWIW +1 to
> this as well as the ability to use multiple trailing closures like so:
>
> animate(identifier: “”, duration: 0, update: {
> // update
> }, completion: {
> // completion
> }
>
> Saagar Jha
>
>
>
> On Jan 4, 2017, at 6:25 PM, Jay Abbott via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> When you have a function with a closure and then another optional default =
> nil closure at the end, like this:
>
> open static func animate(identifier: String,
>  duration: Double,
>  update: @escaping AnimationUpdate,
>  completion: AnimationCompletion? = nil) {
>
> You can’t use trailing closure syntax for the update argument when
> leaving the completion argument out/default.
>
> This kind of breaks one of the benefits of default arguments, which is
> that you can add them to existing released functions without breaking the
> calling code. This means you have to add a separate convenience function
> without the extra argument, which is annoying and inelegant.
>
> Why not simply add the "completion" parameter before the trailing closure?
> That would still allow existing callers to work, without having to change
> the language.
>
> Another annoying thing is that you can easily miss this error if you
> happen to not use trailing closure syntax in your tests or other usage,
> because adding the extra default argument compiles fine for code that uses
> normal syntax.
>
> The Swift compiler warns when a parameter written as a closure type isn't
> the last parameter. The warning is actually disabled in the specific case
> above because you've written it using a typealias... maybe we should warn
> on such cases (it's worth a bug report). Regardless, in the majority of
> instances, you'll get a warning, so it won't be silent on disabling
> trailing closure syntax.
>
>
> Tried this out in the playground:
>
> func foo(a: () -> (), b: (() -> ())? = nil) {
> a()
> b?()
> }
>
> foo(a: {
> print(“Bar”)
> })
>
> and didn’t receive a warning for it, either.
>
>
> We don’t warn here because ‘foo’ does have a trailing closure… it’s for
> the second parameter. I guess we could still warn about ‘a’ (maybe lump it
> into the same bug about the typealias case).
>
> - Doug
>
>
>
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Partial class declaration

[Jay Abbott via swift-evolution]

I agree that partial classes would be a handy way to help split up an
implementation, and perhaps also of assistance if you want really
tight/clean access control within a class, using fileprivate. But this does
not replace the need for stored properties in extensions.

For example (I have done this in Obj-C) if you want to add drag+drop
functionality to UIView in such a way that all its subclasses automatically
support it. You could add the functions and the state, such as isDraggable
and dragFromParent and isDropTarget etc. Note this is just an example of a
use-case, extending a class from an external library.

The implementation previously discussed would use a side-allocation table
pointed at from the refcount portion of the object header and the flag set
to indicate the refcounts were moved inside the table (the same table would
also be needed for instances with weak refs anyway). Thus only instances
that actually made use of the extension stored-properties would bear the
cost of additional storage.
​

On Sat, 10 Dec 2016 at 21:48 Andrey Volodin via swift-evolution <
swift-evolution@swift.org> wrote:

> There is a lot of talk about stored properties in extensions. But do we
> really need them?
>
> Instead I think we can introduce something like partial classes from C#.
> It is an often case our classes go hell of a big and we have to move some
> methods to dedicated extensions to increase readability. It is also an
> often case that those methods have some stored properties they work with.
> This is often leads to a pattern where we have all stored properties
> declared in Class.swift and then we implement extensions in
> Class+Something.swift files.
>
> I bet partial classes should only be available within one module, so you
> can’t extend class from library, etc and work close to text-wide level,
> just to ease the code navigation. That is also will allow some code
> generation tricks, making it easy to create UI/Level designers for Swift.
> (for example you can generate some methods and properties of a Scene class
> in an editor and mix-in that in the user’s project.)
>
> Any thoughts?
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Jay Abbott via swift-evolution]

@Xiaodi @Tino
Apologies for my assumption that every developer already knows how to use
Trello - the “lists” contain “cards” and the cards can be opened and you
can add a more detailed description, comments, checklists, images, and
other stuff. The thing you see in the list is just the title/headline of
the card. Have another go.

https://trello.com/b/fmv4uV3n/swift-access-control

@Xiaodi
Feel free to add a new list called “Bad Features” if you want, and add one
card for each anti-feature, with a title and more detail/information in the
card description about why it’s bad.

I agree that friend classes in C++ were a horrible thing, but I think that
my suggestion of “detailed access control defined by the user in named
access-groups” would solve such problems, by allowing API authors to define
“friends” however they like, and name them Friends or ToDoFixThisProperly
or ThingsThatCanAccessMyProperty or MutableSubclasses or ImmutableSubclasses
(etc.). Rien also suggested pretty much the same thing, but with the
definition directly in the access(details go here about exactly what can
access) modifier instead of being defined in a named group.
​

On Sat, 3 Dec 2016 at 21:28 Tino Heth <2...@gmx.de> wrote:

>
> An interesting format. Since it's a list, I'm not sure how to go about
> commenting on the items already there with which I disagree. IMO, the
> format doesn't lend itself to discussion.
>
> I have to agree… although I fear the major problem isn't the format, but
> rather the spirit: I guess tools would help, but they do nothing without
> commitment for collaboration.
>
> But it is definitely worth a try. Imho the board is at least a small
> improvement over email when it's about collecting thoughts, so thank you,
> Jay (and let's hope for the best)
>
> - Tino
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Jay Abbott via swift-evolution]

No idea if this will be useful, or if it will work, but I created a public
trello board:

https://trello.com/b/fmv4uV3n/swift-access-control

   - Pre-populated with a few of the things already mentioned.
   - There’s a link on the board to gain edit access.

It’s possible this will be an utter disaster, or that nobody will use it at
all, so go ahead and add new lists/cards with abandon.
​

On Fri, 2 Dec 2016 at 22:38 Xiaodi Wu via swift-evolution <
swift-evolution@swift.org> wrote:

> Well, that's literally what I just mentioned above. I'd be fine with
> getting rid of private and fileprivate.
> On Fri, Dec 2, 2016 at 16:30 Jonathan Hull  wrote:
>
> On Dec 2, 2016, at 2:21 PM, Xiaodi Wu  wrote:
>
> I'm not sure why that last scenario couldn't be accommodated by
> submodules. Why wouldn't you put those two specific submodules in the same
> parent submodule?
>
>
> Why even have private and fileprivate? Why not just make everything
> internal?  Same reason…
>
>
>
> On Fri, Dec 2, 2016 at 15:35 Jonathan Hull via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> Assuming that this is true (I tend to agree), why do we need any extra
> syntax at all?  Couldn’t we just make everything accessible to extensions?
>
> Alternatively, if we do want to hide some things from extensions by
> default (to prevent accidental use), I had a proposal a while back which
> had a very simple way to control what is shared. Basically, you could have
> a special import statement which allows you to extend knowledge/access of
> the hidden parts to another file (you were also able to limit the range of
> this ability if needed).
>
> Most of the feedback at the time seemed to want submodules instead, but I
> still think there will still eventually be a need for something like this.
> As others have mentioned, the current system is inflexible (especially to
> the common use cases), causing people to keep requesting additions… and
> forcing them to give wider access than they want to in the mean time.  Even
> if we have sub-modules, someone will want to share with a specific other
> sub-module, but not make things public.
>
>
>
> On Dec 1, 2016, at 1:31 AM, Tino Heth via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>
> It also means that anybody who want to access your private var will just
> have to write an extension to expose it.
>
> imho this is wrong thinking:
> Access control is no tool to offer real "protection" — it can't stop
> someone who wants to break a system.
> Especially in the world of open source, it is merely an advice from the
> author not to do certain things.
> ___
> 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] Swift evolution proposal: introduce typeprivate access control level

[Jay Abbott via swift-evolution]

We really need a place for discussions that apply to deferred issues. Some
previous suggestions from myself and others have been:

   - A Discourse board
   - Tag emails [4.1] (or something else) if they are known to relate to
   deferred proposals.
   - A ‘deferred’ directory for complete proposals in the swift-evolution
   repo to give deferred topics more visibility and a central place for
   discussion around

Until then, I’ll just pile on…

I’ve previously suggested an idea similar to this where a type can define
its own named access groups and then use them for access control. I didn’t
flesh it out in full (as this is a deferred topic anyway) but the concept
was something along these lines…

A class might define a group called Subclasses and that would then be
available to use on properties/functions like access(Subclasses) and
another group called Friends used with access(Friends). This would give the
most flexibility and allow a potentially complex combination of access
controls to be moved elsewhere and re-used in the function definitions that
use it.

Here’s some throw-away syntax to demonstrate a few possibilities:

accessgroup Subclasses {
type: Self
extensions: true // Extensions of types matching 'type' can access
file: true // Anything in this file can access
}accessgroup Friends {
type: UIView, Bob!, Jeff // Any UIView or Jeff type (including
subtypes) and Bob (not including subtypes) can access.
}

This would be defined inside a type - so named groups are type-specific.
This structure can then be used to define whatever type of access we decide
would be useful - access by named modules / submodules? access by direct
subtypes only? access only from specific functions? access from
protocol-conforming types - only the functions of that protocol or any
function in the conforming class? etc.

You can go wild of course with what can be defined in an accessgroup - the
idea here is that we start simple and then discussions about adding other
access control features become a lot easier. We could even go so far as to
say that existing private internal etc. keywords are synonyms for
access(private), access(internal) where private and internal are
always-defined (reserved) accessgroup names.
​
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Jay Abbott via swift-evolution]

Tino,

In what way is this “hiding” protocol conformance? In the examples, MyClass
is declaring conformance to A and B via the Useful protocol composition.
Perhaps I should have made it clearer which bits are new/proposed: Only the
implements word is new here, the protocol composition syntax (A & B)
already exists.

You’re probably right that this is an additive (4.1) thing. But personally
I see no harm in building up a backlog of useful proposals to be reviewed
next year. The knowledge of what’s to come may also help influence thinking
on what’s to come next. Should such discussions be flagged as additive in
the subject somehow? I think I asked this before but forgot or missed if
there was a response.
On Fri, 25 Nov 2016 at 16:21 Tino Heth <2...@gmx.de> wrote:

Kotlin has a imho really nice solution for this: Because constructor
parameters appear right after the class declaration, you can refer to them
in the inheritance-clause.

Protocol conformance is a quite important aspect of a type, so I'm not sure
if it wise to allow "hiding" it — and I hope the promised macro-system will
allow forwarding, so that there is no special syntax needed.

Bottom line:
Imho it's not the right time for serious discussion (serious means: with
the goal of a accepted proposal ;-)

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

Re: [swift-evolution] Global init() functions

[Jay Abbott via swift-evolution]

Why not just say that this doesn't affect the removal of types (i.e. they
can still be discarded) and add something to prevent specific types being
discarded even if they're not statically used?

```swift
@nodiscard SomeType
```

This way, rather than a protocol opting in that anything implementing it is
automatically `@nodiscard` a program or library would declare some types as
non-discardable and could safely say "there will be at least 1
SomeProtocol" available" without saying what specific type it is in the
public interface/docs?


On Mon, 21 Nov 2016 at 22:50 John McCall via swift-evolution <
swift-evolution@swift.org> wrote:

> On Nov 20, 2016, at 6:40 AM, Alan Cabrera  wrote:
>
> On Nov 19, 2016, at 8:57 PM, John McCall  wrote:
>
> On Nov 19, 2016, at 6:03 PM, Alan Cabrera  wrote:
>
> On Nov 19, 2016, at 4:02 PM, John McCall  wrote:
>
> On Nov 19, 2016, at 3:31 PM, Alan Cabrera  wrote:
>
> On Nov 19, 2016, at 1:21 PM, John McCall  wrote:
>
> On Nov 19, 2016, at 10:07 AM, Alan Cabrera via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> On Nov 19, 2016, at 9:27 AM, Jean-Daniel  wrote:
>
>
> Le 19 nov. 2016 à 15:58, Alan Cabrera via swift-evolution <
> swift-evolution@swift.org> a écrit :
>
> I’m not sure if this was proposed or not; or even if this is a Swift-ly
> way of doing things.  It would be pretty handy to be able to declare init()
> functions in my module to register handlers.  It’s a common pattern in
> enterprise software.
>
> Currently, I have to generate a lot of boilerplate code to emulate the
> behavior.  I think it would be cleaner to have these global init()
> functions.
>
>
> I’d rather like a swift attribute equivalent to : __attribute__((
> constructor))
>
> It will not force me to call my initializer init, and moreover it will let
> me declare multiple functions so I would be able to register multiples
> handlers from a single module without having to group all the register call
> into a single init() function.
>
>
> I’m not quite following what “__attribute__((constructor))” means; it
> looks like an LLVM implementation bit.  Do you mean defining a new Swift
> declaration attribute named “constructor”?  If so, I *really* like that
> idea.  I think that the specific attribute name “constructor” may be a bit
> confusing though, since it’s not really constructing anything specific.
> Maybe “startup” would be a more descriptive attribute name?
>
> @startup
> func registerHandlers() {
> }
>
> The attribute would also help the compiler and IDEs prevent direct calling
> of the startup functions, thus reinforcing/focusing the startup functions’
> role as global startup functions.  Maybe global teardown functions would be
> helpful as well.
>
> I’m going to try goofing around with the idea on my fork.
>
>
> Some sort of reflective discovery would be better, I think.  Eager global
> initialization is superficially attractive — what could be simpler than
> just running some code at program launch? —  but as a program scales up and
> gains library dependencies, it very quickly runs into problems.  What if an
> initializer depends on another already having been run?  What if an
> initializer needs to be sensitive to the arguments or environment?  What if
> an initializer need to spawn a thread?  What if an initializer needs to do
> I/O?  What if an initializer fails?  Global initialization also has a lot
> of the same engineering drawbacks as global state, in that once you've
> introduced a dependency on it, it's extremely hard to root that out because
> entire APIs get built around the assumption that there's no need for an
> explicit initialization/configuration/whatever step.  And it's also quite
> bad for launch performance — perhaps not important for a server, but
> important for pretty much every other kind of program — since every
> subsystem eagerly initializes itself whether it's going to be used or not,
> and that initialization generally has terrible locality.
>
>
> Very good points.  I recognize the dangers.  However.
>
> Don’t these problems already exist given that user code can still execute
> at program startup?  It cannot be denied that the pattern is used and is
> extremely useful though, as you point out above, it should be used
> carefully.  Thinking on it, there are always pros and cons to most language
> features and one relies on best practices to avoid shooting oneself in the
> foot.  For each of the specters listed above, there are simple accepted
> practices that can be adopted to avoid them; most of those practices are
> already being employed for other situations.
>
> And the pattern is not just useful in enterprise software.  Complex
> applications’ app-delegate did-finish-launching methods are chucked full of
> hand stitched roll calls to framework initialization code.  This needlessly
> places a brittle 

[swift-evolution] [pitch] Implementation composition

[Jay Abbott via swift-evolution]

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 implements(internal) or implements(public)
would be better. Or perhaps someone can think of a better word because in
the partial case it is a little confusing - is there a single word that
means use-to-implement ?

Regarding value-types: I haven’t thought deeply about this for non-class
types, but it can probably work the same for those too.

Anyway, this could be used to provide a variety of implementations for
protocols, composed of different combinations of partial implementations,
then use those complete implementations to compose your larger/complex
types with the minimum of boilerplate forwarding code.

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

Re: [swift-evolution] SE proposal: Add @objc to enum strings

[Jay Abbott via swift-evolution]

It seems like a sensible/reasonable approach, but personally I don't care
about accessing Swift from Obj-C, or writing Swift that can be called from
Obj-C.

On Sun, 20 Nov 2016 at 18:15 Derrick Ho via swift-evolution <
swift-evolution@swift.org> wrote:

> Does anyone have any thoughts on this idea?
>
> I Made a draft proposal of this very idea
>
> https://github.com/wh1pch81n/swift-evolution/blob/master/proposals/-Swift-enum-strings-ported-to-Objective-c
>
> On Sat, Nov 19, 2016 at 2:44 PM Derrick Ho  wrote:
>
> [TL;DR]
> SE-0033 ports objective-c global strings to swift enums, but the reverse
> seems to be missing. There should be a swift construct that can be
> accessible by objective-c.
>
> [Proposal]
> In a previously implemented swift proposal, the concept of NS_STRING_ENUM
> and NS_EXTENSIBLE_STRING_ENUM was born.  (see:
> https://github.com/apple/swift-evolution/blob/master/proposals/0033-import-objc-constants.md
> )
>
> This would enable objective-c global strings to be ported over to swift as
> an enum and struct respectively.
>
> I always found it odd that this interoperability only worked in one
> direction.  I think that enum strings should be accessible to Objective-c
> when it is marked with  the @objc attribute.  When an enum string has @objc
> it should be ported over to objective-c as global strings.
>
> // Swift example
> @objc
> public enum Food: String {
>case Calamari
>case Fish
> }
>
> // Objective-c port
> typedef NSString *_Nonnull Food;
> static Food const Food_Calimari = @"Calimari";
> static Food const Food_Fish = @"Fish";
>
> The Objective-c port code could be added as part of the generated header
> file or a framework's umbrella header.
>
> When a structs is given the attribute @objcextstring it should become
> available to objective-c as a class.  This attribute will put restrictions
> on the struct such that it only has static constants and a mandatory
> property called rawValue.
>
> // Swift example
> @objcextstring
> public struct Planets {
> public let rawValue: String
> public static let Earth = Planets(rawValue: "Earth")
> public static let Venus = Planets(rawValue: "Venus")
> }
>
> // Objective-c port
> @interface Planets: NSObject
> + (instanceType)Earth;
> + (instanceType)Venus;
> @end
>
> @implementation Planets
> + (instanceType)Earth {
> return [[Planets alloc] initWithRawValue: @"Earth"];
> }
> + (instanceType)Venus {
> return [[Planets alloc] initWithRawValue:@"Venus"];
> }
> @end
>
> What do you guys thinks of this proposal?  Do you think it will enhance
> the objective-c to swift interoperability?
>
>
> ___
> 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-0145: Package Manager Version Pinning (Revised)

[Jay Abbott via swift-evolution]

> What is your evaluation of the proposal?

It seems like a sensible step on the way to more advanced workflow, stats,
testing, checking upgrades, and reporting features - without closing any
doors.

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

This is a better and more considered approach.

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

A quick reading, plus previous consideration of this issue when it has
caused both team and CI problems in other package managers.


On Sun, 20 Nov 2016 at 05:48 Anders Bertelrud via swift-evolution <
swift-evolution@swift.org> wrote:

> Hello Swift community,
>
> The review of "SE-0145: Package Manager Version Pinning" begins again
> after revisions, starting now and running through November 28th. The
> proposal is available here:
>
>
> https://github.com/apple/swift-evolution/blob/master/proposals/0145-package-manager-version-pinning.md
>
> Reviews are an important part of the Swift evolution process. All reviews
> should be sent to the swift-build-dev and swift-evolution mailing lists at
>
> https://lists.swift.org/mailman/listinfo/swift-build-dev
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
> or, if you would like to keep your feedback private, directly to the
> review manager.
>
> What goes into a review?
>
> The goal of the review process is to improve the proposal under review
> through constructive criticism and contribute to the direction of Swift.
> When writing your review, here are some questions you might want to answer
> in your review:
>
> * What is your evaluation of the proposal?
> * Is the problem being addressed significant enough to warrant a change to
> Swift?
> * Does this proposal fit well with the feel and direction of Swift?
> * If you have used other languages or libraries with a similar feature,
> how do you feel that this proposal compares to those?
> * How much effort did you put into your review? A glance, a quick reading,
> or an in-depth study?
>
> More information about the Swift evolution process is available at
>
> https://github.com/apple/swift-evolution/blob/master/process.md
>
> Thank you,
>
> Anders Bertelrud
> 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] Global init() functions

[Jay Abbott via swift-evolution]

Alan,

The other thread subject is "Getting a list of protocol conformers"

On Sun, 20 Nov 2016 at 14:40 Alan Cabrera via swift-evolution <
swift-evolution@swift.org> wrote:

> On Nov 19, 2016, at 8:57 PM, John McCall  wrote:
>
> On Nov 19, 2016, at 6:03 PM, Alan Cabrera  wrote:
>
> On Nov 19, 2016, at 4:02 PM, John McCall  wrote:
>
> On Nov 19, 2016, at 3:31 PM, Alan Cabrera  wrote:
>
> On Nov 19, 2016, at 1:21 PM, John McCall  wrote:
>
> On Nov 19, 2016, at 10:07 AM, Alan Cabrera via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> On Nov 19, 2016, at 9:27 AM, Jean-Daniel  wrote:
>
>
> Le 19 nov. 2016 à 15:58, Alan Cabrera via swift-evolution <
> swift-evolution@swift.org> a écrit :
>
> I’m not sure if this was proposed or not; or even if this is a Swift-ly
> way of doing things.  It would be pretty handy to be able to declare init()
> functions in my module to register handlers.  It’s a common pattern in
> enterprise software.
>
> Currently, I have to generate a lot of boilerplate code to emulate the
> behavior.  I think it would be cleaner to have these global init()
> functions.
>
>
> I’d rather like a swift attribute equivalent to : __attribute__((
> constructor))
>
> It will not force me to call my initializer init, and moreover it will let
> me declare multiple functions so I would be able to register multiples
> handlers from a single module without having to group all the register call
> into a single init() function.
>
>
> I’m not quite following what “__attribute__((constructor))” means; it
> looks like an LLVM implementation bit.  Do you mean defining a new Swift
> declaration attribute named “constructor”?  If so, I *really* like that
> idea.  I think that the specific attribute name “constructor” may be a bit
> confusing though, since it’s not really constructing anything specific.
> Maybe “startup” would be a more descriptive attribute name?
>
> @startup
> func registerHandlers() {
> }
>
> The attribute would also help the compiler and IDEs prevent direct calling
> of the startup functions, thus reinforcing/focusing the startup functions’
> role as global startup functions.  Maybe global teardown functions would be
> helpful as well.
>
> I’m going to try goofing around with the idea on my fork.
>
>
> Some sort of reflective discovery would be better, I think.  Eager global
> initialization is superficially attractive — what could be simpler than
> just running some code at program launch? —  but as a program scales up and
> gains library dependencies, it very quickly runs into problems.  What if an
> initializer depends on another already having been run?  What if an
> initializer needs to be sensitive to the arguments or environment?  What if
> an initializer need to spawn a thread?  What if an initializer needs to do
> I/O?  What if an initializer fails?  Global initialization also has a lot
> of the same engineering drawbacks as global state, in that once you've
> introduced a dependency on it, it's extremely hard to root that out because
> entire APIs get built around the assumption that there's no need for an
> explicit initialization/configuration/whatever step.  And it's also quite
> bad for launch performance — perhaps not important for a server, but
> important for pretty much every other kind of program — since every
> subsystem eagerly initializes itself whether it's going to be used or not,
> and that initialization generally has terrible locality.
>
>
> Very good points.  I recognize the dangers.  However.
>
> Don’t these problems already exist given that user code can still execute
> at program startup?  It cannot be denied that the pattern is used and is
> extremely useful though, as you point out above, it should be used
> carefully.  Thinking on it, there are always pros and cons to most language
> features and one relies on best practices to avoid shooting oneself in the
> foot.  For each of the specters listed above, there are simple accepted
> practices that can be adopted to avoid them; most of those practices are
> already being employed for other situations.
>
> And the pattern is not just useful in enterprise software.  Complex
> applications’ app-delegate did-finish-launching methods are chucked full of
> hand stitched roll calls to framework initialization code.  This needlessly
> places a brittle dependency/burden on the application developer in what
> should be a simple behind the scenes collaboration.
>
> One could argue that such a thing was never needed before.  I would point
> to CocoaPods, Carthage, and the other influx of enterprise influenced
> tooling and frameworks.  Today’s mobile applications are no longer simply
> todo apps.
>
> Global init() functions are a clean solution to what engineers are
> *already* boiler plating with static singleton code.
>
>
> No, they aren't a clean solution for the reasons I listed.  They 

Re: [swift-evolution] [Pitch] Setup Block

[Jay Abbott via swift-evolution]

Hi Andrew,

There is a similar discussion (in that it solves some aspects of the same
problem) going on at the moment with the subject "Add code to super
methods" - check it out. The parts of this problem it doesn't address is
that you would still have to override multiple init methods to ensure your
common setup was called regardless of which initialiser is used. However,
your idea of a post-init call might solve some of of the other issues being
discussed there and affect that discussion quite a bit. In other words, I
think these two ideas might benefit from being considered together rather
than as separate issues.

On Sun, 20 Nov 2016 at 09:58 Tino Heth via swift-evolution <
swift-evolution@swift.org> wrote:

> Initialization is already quite complex in Swift, so I'm very wary of
> adding new features and prefer Derricks idea over a new language feature.
> I hope Swift is still flexible enough for deep changes in this area — I
> guess enforcing that there is always a single designated initializer would
> not only improve on you usecase.
> ___
> 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 code to super methods.

[Jay Abbott via swift-evolution]

Hi Mustafa,

This is an interesting idea. The wording needs to be clear that it is not
adding/injecting any code into the super-class. I would call it something
like a cascading or chained method - there may be a better name and
probably already is, because deinit already behaves in a similar way - the
compiler enforces that you don’t call it directly and it cascades the calls
up the super-class chain skipping ones where deinit is not implemented.

I think this should be something declared in the super-class though, not
something that a sub-class would use for the convenience of omitting the
super call. That is, the super-class demands of the compiler that its
implementation is always called when this method is called on any sub-class
(and this enforcement is inherited so all implementations in each sub-class
are guaranteed to be called).

A class could declare a method to be chained (or whatever) and the compiler
would ensure that overrides definitely call the super method, or
automatically inject it if they don’t. This would give sub-classes the
flexibility to call it anywhere they like (before or after or in the middle
of their implementation) and they could also modify the parameters passed
to it. There could also be head/tail variations that enforce super is
called at the beginning or end of sub-class implementations, rather than
anywhere.

This is also similar to how the compiler enforces the init calls are made
up the class hierarchy, but with init each sub-class might have different
parameters for their initialisers. However with a method, if you introduce
different/additional parameters it is now a new method, and no longer an
override. Would it be desirable to enforce a chain in this case - when a
sub-class wants to change the signature part way down the chain such that
all its sub-classes cannot override the original method but must use a
different one instead? This seems related but probably needs a lot more
thought and a diverse set of examples to guide the design.
​

On Wed, 16 Nov 2016 at 22:30 Mustafa Sabur via swift-evolution <
swift-evolution@swift.org> wrote:

> Hallo,
>
> I have a very simple suggestion. And I’m not very sure then it haven’t
> been discussed already, so I’m sorry if that is the case.
> I would like to see the ability to just add code to base methods instead
> of overriding it and calling supers method. So basically an extension for
> methods.
>
> Example:
>
> Now:
> override func viewDidLoad() {
> super.viewDidLoad()
> * // Your code*
> }
>
> Suggestion:
> addinto func viewDidLoad() {
> * // Your code*
> }
>
> My reasons:
> 1. Its very verbose about your intentions, which fits into Swift style.
> The thing you actually want is not overriding but appending.
> 2. You cannot make the mistake of forgetting to call the supers method.
> 3. It open ways to introducing ‘semi-final’ methods, which cannot be
> override but you still can append to it.
> This to make sure your API implementation will always be executed .
> I’m thinking about a keyword like extendable to specify that you can only
> add to it.
> 4. Less code.
>
> I can’t think of any cons... Thought I can imagine that the benefits are
> quite small and maybe not worth the effort.
> I would like to read some thoughts about this. Thank you!
>
> Kind regards,
> Mustafa Sabur
>
>
>
> ___
> 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] Type Narrowing

[Jay Abbott via swift-evolution]

Consider this code:

struct Pet {
let name: String
weak var owner: Person?

init(name: String, owner: Person?) {
self.name = name
self.owner = owner
owner?.pet = self
}

mutating func transferOwnership(to newOwner: Person) {
let previousOwner = owner
owner = newOwner
newOwner.pet = self
if(previousOwner != nil) {
previousOwner!.pet = nil
}
}

func feed() {
}
}
class Person {
let name: String
var pet: Pet?

init(name: String) {
self.name = name
}

func givePetAway(to someone: Person) {
if pet != nil {
pet!.transferOwnership(to: someone)
//pet!.feed()
}
}
}
let bert = Person(name: "Bert")let ernie = Person(name: "Ernie")var
elmo = Pet(name: "Elmo", owner: nil)

elmo.transferOwnership(to: bert)print("Bert's pet is \(bert.pet) -
Ernie's pet is \(ernie.pet)")

bert.givePetAway(to: ernie)print("Bert's pet is \(bert.pet) - Ernie's
pet is \(ernie.pet)")

This works as expected, but if you uncomment pet!.feed() in givePetAway(to:)
it will crash, because the mutating function modifies the two-way
relationship between pet and owner.

In the code I use if pet != nil to demonstrate, in your proposal for unwrap,
if I used it to unwrap pet (a value-type, but accessed through self so it
can be modified after unwrapping because it’s not nil at the moment) the
compiler would assume I could use it and pet.feed() would crash, just as
pet!.feed() does now. In your proposal for type narrowing, it would be the
same problem. This is like your foo.value example from the proposal.

I don’t think you can get around the fact that the compiler can’t guarantee
a type-narrowed or even unwrapped mutable value, which is why if let works
as it does with an immutable snapshot.

However, type narrowing for immutable values would still be good.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Jay Abbott via swift-evolution]

Haravikk,

I think you missed ilya’s point with the owner/pet example:

// This is inside the Owner class...func freeMyPetIfIHaveOne {
  if pet != nil {
pet.setFree() // this sets pet = nil
// self.pet is now nil - not due to concurrency, it was set to nil
on this thread in the function above.
// However, the compiler considers it a non-optional at this point
pet.doStuff() // Compiler allows, bad things happen!
  }
}

As Dennis mentioned, narrowing only works for immutable values, and since
optionals are always mutable it defeats the whole justification for it. I
like the concept, but maybe it should be for immutables only?
​

On Thu, 10 Nov 2016 at 11:27 Haravikk via swift-evolution <
swift-evolution@swift.org> wrote:

> On 10 Nov 2016, at 10:32, Dennis Lysenko 
> wrote:
>
> So a lot of concerns here especially ilya's are ones that wouldn't be
> brought up if people looked at existing successful implementations like
> Kotlin where they are clearly solved. (fyi, answer is only narrowing with
> immutable values.)
>
> Personally I think type narrowing with explicit opt-in has no value. All
> or nothing, the whole meat of the proposal is in it being implicit.
>
> Right you are, I think an explicit keyword is only required for optionals;
> stripping them out into their own proposal simplifies things considerably.
> I've tweaked the type-narrowing specific proposal to return implicit
> narrowing (or explicit via the is keyword and assignment, depending upon
> how you want to look at it).
>
> I do think there is still value in handling reference types as well, but
> I'm proposing that this is done with a new force is! keyword which forces
> the narrowing (but causes a runtime concurrent modification error if the
> type no longer matches what the type-checker expects), as well as a new
> @concurrency(safe) attribute that can be used to indicate variables that
> posses a safe reference to an instance, e.g- for types that use a storage
> class for copy-on-write functionality, or where the value is local to a
> method etc. (though this isn't enforced).
>
> if it makes compilation times even slower I'm probably against it - xcode
> in general has been driving me up a wall lately with a matter of minutes
> for compiling and signing our (not huge) project, so any compiler speed
> improvements take on increased precedence for me.
>
> While I agree that the current performance can leave a lot to be desired,
> I don't think that this should actually slow it down by any meaningful
> amount; most variables won't narrow so will just be a single type as
> normal, and with optionals removed from the narrowing process the
> type-checker should only ever need to compare against the narrowest type on
> the stack, i.e- the only time wider types are considered is when you assign
> a wider type to a narrowed variable, and that's just popping types off the
> stack to get the new current type.
>
> But yeah, if it were have a big impact on performance I'd recommend
> delaying it until major optimisation work has been done, but I don't see
> that it should make much of a difference, and it really shouldn't be any
> more of a burden than shadowing is today.
>
> On Wed, Nov 9, 2016, 13:52 Haravikk via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> So I'm trying to re-write the proposal with the use of a keyword for
> unwrapping in mind, to keep it simpler for myself I've done this as two
> separate proposals for the time being, one for simpler unwrapping of
> optionals, and one for type-narrowing of polymorphic types:
>
>
> https://github.com/Haravikk/swift-evolution/blob/master/proposals/-optional-unwrapping.md
>
> https://github.com/Haravikk/swift-evolution/blob/master/proposals/-type-narrowing.md
>
> In addition to feedback on each proposal, I'm interested to know whether
> people think it is better to keep these separate? They're still very
> similar features, but the differences make it pretty awkward to keep them
> in one big proposal.
>
> I've also given up on integrating enums generically into it; as I don't
> think it's possible to do it in a similar enough way, and some extension to
> pattern matching would probably be better anyway.
> ___
> 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] Some concerns on custom operators

[Jay Abbott via swift-evolution]

Would it make sense to allow some kind of operator aliasing on import, so
that developers can at least work-around library conflicts?

On Wed, 9 Nov 2016 at 21:59 Dave Abrahams via swift-evolution <
swift-evolution@swift.org> wrote:

>
> on Wed Nov 09 2016, John McCall  wrote:
>
> >> On Nov 9, 2016, at 1:24 PM, Dave Abrahams via swift-evolution <
> swift-evolution@swift.org> wrote:
> >> on Wed Nov 09 2016, John McCall >
> > wrote:
> >>
>  On Nov 9, 2016, at 9:25 AM, Anton Zhilin via swift-evolution <
> swift-evolution@swift.org> wrote:
>  • Upon implementation of SE-0077 in Swift 3, some libraries started
> to drop operators entirely:
> >
> >>> link #1, link #2.
>  • Declarations of the same custom operator with different precedence
> groups create a conflict.
>  • The conflict can be resolved manually, but the resolution has to be
> made in every file that uses
> >>> the operator, which defeats the reason for using operators in the
> first place.
>  • This is a part of a larger problem of conflict resolution, for
> which we don’t currently have a
> >>> systematic approach.
> >>>
> >>> It makes sense to me to provide a more module-wide conflict resolution
> >>> mechanism.  Maybe we can have some sort of "internal export" mechanism
> >>> where a file can introduce imports into other files within a project.
> >>>
> • Many libraries dealing with custom operators choose
>  to import Runes, which is basically a stockpile of operator
>  declarations. But it conflicts with Result, Swiftx and Operadics.
> >>>
> >>> Won't this just shake itself out pretty soon, assuming these projects
> >>> have any interest in interoperating?
> >>
> >> This is a well-known library interoperability dynamic, and IMO we can't
> >> expect the solution for conflicting libraries to be that you have to get
> >> the library authors to communicate with one another.  That effectively
> >> fixes nothing for the poor app developer who integrates these libraries.
> >
> > I agree that we need to solve that problem, which is why I suggested an
> approach
> > for solving that problem in the previous paragraph.
>
> Sorry if I didn't read carefully enough.
>
> > But it's still reasonable for us as "wardens of the ecosystem" to ask
> > library authors to consider how their libraries interoperate with
> > their peers.
>
> Sure; that's part of the job of writing a library.
>
> > We can also make a stronger effort to ignore spurious conflicts in the
> > language, of course, e.g. by only complaining if conflicting
> > precedencegroup declarations would yield different parsing results;
> > but that logic would get unworkably complex pretty quick.
> >
> > John.
>
> --
> -Dave
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] stored properties in extensions (was: associated objects)

[Jay Abbott via swift-evolution]

Perhaps some types don’t lend themselves to being extended?

Intuitively I would think any extensions should not affect the core
behaviour at all. So if I extended a type by adding a property x, two
instances with everything else the same and different values of x should
still be considered equal by a type-specific equality check. For example
you would agree that 1 + 1 = 2 but what if the numbers were coloured red,
blue, and yellow respectively, like fridge-magnets, should 1(red) + 1(blue)
= 2(yellow)? I think yes. The colour is an extension, it doesn’t change the
fundamental concept or behaviour of an integer number.

I see extensions as a way to add functionality (and potentially data), but
without affecting the core behaviour. If you wanted to change behaviour
then you should use inheritance or composition to create something new. You
can’t then use your own type for instances created by a library, unless it
gives you a way to do that, the library would expect its own types to
behave in a predictable way, similarly they should behave the same way when
extended.
​

On Thu, 3 Nov 2016 at 15:14 Thorsten Seitz via swift-evolution <
swift-evolution@swift.org> wrote:

> Has anybody thought about the semantic issues of out-of-module extensions
> with stored properties apart from the implementation issues?
>
> Such properties could potentially wreak havoc with the semantics of the
> type being extended. How would these properties play nice with an existing
> definition of equality, for example? How can it be guaranteed that their
> value is consistent with the remaining state? And kept that way in case of
> mutability?
>
> -Thorsten
>
> > Am 15.10.2016 um 03:01 schrieb Paul Cantrell via swift-evolution <
> swift-evolution@swift.org>:
> >
> >
> >> On Oct 9, 2016, at 3:43 PM, Charles Srstka via swift-evolution <
> swift-evolution@swift.org> wrote:
> >>
> >> Let extensions introduce stored properties, but only in the same module
> as the type’s definition. Then, the compiler can just take any extensions
> into consideration when it’s determining the size of the type, just as if
> the properties had been declared in the type. Declaring stored properties
> on an extension outside of the type’s module results in a compiler error,
> exactly as today. This would, without any performance drawbacks, solve one
> of the big problems that people are hoping to solve via stored properties
> in extensions—the ability to organize members by protocol conformance.
> >
> > Yes please! A big strong +1 to this from me. I can think of several
> specific chunks of problem code that this would clean up immensely.
> >
> > Contra Karl in another message, it’s _in-module_ stored property
> extensions that I want most frequently. By far.
> >
> > It seems to me that Charles’s idea could be introduced as its own
> proposal. If out-of-module stored property extensions do eventually become
> feasible, then Charles’s proposal is a good stepping stone. If they never
> do, then his proposal has done no harm.
> >
> > I realize this probably falls into the post-ABI stability bucket, but
> I’d love to help write/support the proposal when its time comes.
> >
> > Cheers,
> >
> > Paul
> >
> > ___
> > 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] Official Swift Slack team?

[Jay Abbott via swift-evolution]

+1 for Discourse

On Mon, 31 Oct 2016 at 17:01 Karl Wagner via swift-evolution <
swift-evolution@swift.org> wrote:

> When it comes to infrastructure/dev-ops, Apple probably have people
> responsible for it (like Shah Mischal does the CI server); I think Chris
> mentioned in the last discussion on this topic that they do.
>
> It would be worth getting in touch with those people and finding out which
> issues are blocking a switch to a platform such as Discourse.
>
> For one thing, there's a huge collection of great, in-depth information on
> these lists; the kind of behind-the-scenes technical details that devs love
> to read up on (the kind of stuff you'd find on Mike Ash's blog). It's a bit
> difficult to find and discover these things, though.
>
> Sticky posts would also be great: maybe could have a friendly reminder on
> swift-evo that we're only taking ABI-breaking proposals right now, or split
> the "pitch" threads in to a separate sub forum, or keep commonly-rejected
> proposal threads around so people can read *why* they were rejected.
>
> There are loads of opportunities to improve the community experience, IMO.
> So I definitely support a move to something richer than a mailing-list, but
> from previous discussions it sounds like Discourse (rather than Slack) will
> give us lots of these benefits with least upheaval.
>
> - Karl
>
>
>
>
> On Oct 30, 2016 at 8:26 pm,  > wrote:
>
> Hello dear Swift community,
>
> I’d like to pitch the idea of introducing an official Slack team?
>
> Never heard of Slack before: https://slack.com
>
> I know we might have a forum in the future + we already have swift-users,
> but there are might be other talks you have on your mind around Swift. For
> example you could share some ideas, searching for help for your project, or
> just chat with your favorites language community.
>
> That will keep the evolution process nice and clean. :)
>
> What do you think?
>
> --
> Adrian Zubarev
> Sent with Airmail
> ___ swift-evolution mailing
> list swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Jay Abbott via swift-evolution]

@unwrappable(type: Int)
> public enum Count {
> case none // not unwrappable
> case many // not unwrappable
> case some(Int)
> case owed(Int)
> case something(String) // not unwrappable
> case multiple(Int, Int) // not unwrappable
> }
>
> Instead of requiring the @unwrappable attribute, why not have unwrap work
normally when the type can be inferred, or require hints when it can’t:

// For an optional (or any other enum with only one wrapped type)
guard unwrap x else { return }// For an enum of type Count as defined above
guard unwrap myCount else { return } // compiler error - type can't be
determined
guard unwrap(myCount: Int) else { return } // Success for 'some' or
'owed' (implicit shadowing)
guard unwrap(let someOrOwed: Int) myCount else { return } // Success
for 'some' or 'owed' (no shadowing)
guard unwrap(let x: Int, let y: Int) myCount else { return } //
Success for 'multiple' (no shadowing)

Notes:

   - unwrap x is equivalent to unwrap(x: T) where there is a single
   unambiguous type.
   - The let keyword probably could be implicit for the non-shadowing
   forms, like it is for the shadowing form, but makes it clear what’s going
   on.
   - unwrap fails for none or many from the Count type, just as it does for
   none from Optional
   - I *think* that this assumes Swift is not allowed to try to infer the
   most restrictive type for reference types. Haven’t really thought about
   this much.

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

Re: [swift-evolution] [pitch] rename 'guard' to 'ensure'

[Jay Abbott via swift-evolution]

You’re really in pun mode today, David! :)

Even though I originally pitched this, I go along with the source-churn
arguments people have made[1], and the one about ensure potentially being
used for something else in the future. But I do really like Marco’s
suggestion of guard: because it changes the interpretation…

guard: x > 0 else { return }

This now reads as: *This is a guard: x must be greater than zero, otherwise
return*. The only issue is it has the same syntax as a break-label so
becomes potentially ambiguous/confusing. Is there another way that could be
achieved?

[1] For larger changes, but I think some of the arguments against breaking
changes are weak for smaller changes/refinements.
​

On Thu, 27 Oct 2016 at 13:31 David Sweeris via swift-evolution <
swift-evolution@swift.org> wrote:

>
> On Oct 26, 2016, at 11:41, Chris Lattner via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> On Oct 26, 2016, at 1:11 AM, alessandro aresta 
> wrote:
>
> Ensure is more comprehensible, guard is for sure "always" been there in
> older languages... could it be kind of aliased somehow?
>
>
> No, we don’t introduce needless aliases for keywords like this.
>
>
> What about allowing internal non-type aliases?
> alias ensure = guard //can't be public
> I know it's kinda encroaching on "macro" territory, but can't we already
> do simple text substitutions by importing a #define from C? Would allowing
> non-type aliases really be any different?
>
> It'd address the concerns raised by I think nearly all of the
> "term-of-art" vs "term-of-English" proposals. Prohibiting aliases from
> being declared as `public` would *guard* the language's namespace, and
> *ensure* that it doesn't get polluted with every library author's
> favorite alternate spelling(s).
>
> - 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] [Pitch] Replace the ternary operator with an in-language function

[Jay Abbott via swift-evolution]

David,

You make some good points in favour of explicit support for user-defined
ternary operators. You're right that it's a bit clunky without. Probably a
discussion for another thread though, and additive so not for phase 1. But
perhaps worth a proposal for phase 2?

On Thu, 27 Oct 2016 at 09:23 David Sweeris  wrote:

>
> On Oct 26, 2016, at 21:29, Jay Abbott  wrote:
>
> David, you can use two binary operators (or overload the same one twice if
> you want) to create syntax that behaves like a ternary operator.
>
> Oh I know, it's just kinda clunky and inefficient sometimes, if you need
> to wrap a value in a struct or something simply to avoid ambiguity or
> enforce the correct syntax. It's not quite the same thing a ternary
> operator, but at one point I'd added `|` as both pre and postfix operators
> to allow code like "let y = |x|". The left `|` had to return a
> `_PartialAbsValueOp` and the right one had to take the same to invalidate
> the "let y = |x" or "let y = x|" syntax, one of which would've otherwise
> worked (depending on which op actually called "abs()").
>
> I should've been clearer that I was talking about support for "free form"
> operators in general, including ternary ops, so that we don't have to fake
> them by declaring some # of traditional pre/in/postfix operators which all
> then have to work together (possibly exclusively, depending on the desired
> syntax), and might have to pass wrapper types around solely to help explain
> your syntax to the compiler.
>
> Thanks for pointing it out, though. That's an easy trick to forget about.
>
> - Dave Sweeris
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Pitch] Replace the ternary operator with an in-language function

[Jay Abbott via swift-evolution]

David, you can use two binary operators (or overload the same one twice if
you want) to create syntax that behaves like a ternary operator.

Here’s an example of using a pair of operators to interpolate between two
CGPoint values:

let interpolatedPoint = p1 <~~ 0.3 ~~> p2

See here

for the code that defines them.

I went for two different operators in the end, but when experimenting I
also tried using the same one, and it works fine because of overloading,
for example:

infix operator ~~> : InterpolationPrecedence
public func ~~> (from: T, alpha: Double) -> (T, Double) {
return (from, alpha)
}
public func ~~> (lhs: (T, Double), rhs: T) -> T {
return lerp(from: lhs.0, to: rhs, alpha: lhs.1)
}let interpolatedPoint = p1 ~~> 0.3 ~~> p2

And as Anton demonstrated earlier, ?: can be emulated the same way. The
errors you would get if you omitted the second operator and third part are
not as useful as they can be with ?:. The compiler can probably do a much
better job of optimising with ?: as a special case, and it’s a common
pattern regardless of syntax, so people would just write their own if it
wasn’t there. So I think it makes sense to have it in the language. And if
it wasn’t already there, I do think that it would be something we should
add (same for ??).
​

On Thu, 27 Oct 2016 at 01:44 David Sweeris via swift-evolution <
swift-evolution@swift.org> wrote:

>
> On Oct 25, 2016, at 23:51, Charlotte Angela Tortorella via swift-evolution
>  wrote:
>
> Disadvantages of The Ternary Operator
> 
>
> [...]
>
>
> 6. This operator is only applicable to a single type, `Bool`.
>
> [...]
>
>
> Proposed Approach
> 
>
> We should drop the ternary operator in favor of a new extension to `Bool`.
>
>
> I'm not sure proposals should do exactly what they claim is a downside of
> the current approach. Especially when the downside in question is
> inherent to the problem being solved.
>
> FWIW, the only thing I find confusing about the ternary operator is that I
> can't overload it. Being able to define my own ternary operators would be
> great, but I don't have an answer to obvious potential ambiguities.
>
> - 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] [pitch] rename 'guard' to 'ensure'

[Jay Abbott via swift-evolution]

Hey Joe,

I tend to agree, it seems like a tiny niggle for experienced C-family
developers who have used if(negative condition) as a guard for years, and
those with knowledge in other languages where it is already known. But for
new developers, learning the language of the future as a first-language
(such as my other half, who is learning Swift as her first programming
language with the "Swift Playgrounds" app), doesn't it make sense for such
a concept to fit right in with their existing linguistic model of the
world? This makes a language intuitive rather than something you need to
'learn'.

This is where "strong motivation" and "overwhelming evidence" lose their
meanings (to me). This group does seem to be strongly motivated to help new
developers, and ensure Swift is easy and intuitive for them, as well as
powerful for experienced developers. Is it practical to gather evidence on
how new developers learn and internalise "guard" or any other part of the
language? Probably not, so how can we ever have "overwhelming evidence" for
anything related to intuitiveness for new developers? Also is there a grey
area for source-breaking changes? I mean obviously a change is either
breaking or it's not, but if we were to take Marco's idea and use "guard:"
instead of "ensure" - existing articles and QA online would still be
searchable/relevant, the compiler could emit a fixme error to add the colon
when it came across old syntax (or Xcode's converter or a simple
project-wide search/replace would rectify old syntax), etc. so there are
breaking changes, and then there are trivial-to-rectify breaking changes.
Another point is: If there is a single breaking change, for strong reasons,
doesn't that invalidate all arguments against other (automatically
convertible) breaking changes which have not-so-strong reasons? If code
needs to be converted, then what difference does it make how many trivial
automated changes there are? And isn't that the entire point of a major
version bump anyway?

I think as a group we should be cautious of:
* hard/fast/unbreakable rules
* subjective terms like "strong motivation" and even "overwhelming
evidence", especially where our evidence is our own arguments and examples,
as made and interpreted by some of the experienced to genius level
developers on this list.
* denying or failing to recognise grey areas.

I'm not having a go at you Joe, or anyone else who has made these points. I
actually agree that this particular issue seems too trivial to warrant a
change, but I'm trying to question if that's the right conclusion (which is
what motivated me to post this thread in the first place). The 'cost' seems
small, and while the 'benefit' seems tiny to us, it might actually be quite
huge for new developers.


On Tue, 25 Oct 2016 at 18:20 Joe Groff <jgr...@apple.com> wrote:

> At this point in Swift's evolution, source-breaking changes to the
> language require strong motivation. We can't really entertain superficial
> keyword changes like this without overwhelming evidence that the existing
> syntax is problematic in practice. `guard` has precedent in functional
> languages, for instance in Haskell where the `guard` function is
> idiomatically used as part of monadic `do`-notation computations, and has
> the same positive condition semantics in those languages.
>
> -Joe
>
> > On Oct 25, 2016, at 9:38 AM, Jay Abbott via swift-evolution <
> swift-evolution@swift.org> wrote:
> >
> > I mentioned this in passing on a different thread. Although it caused
> some slight confusion when I first learned the 'guard' keyword, it was easy
> to overcome and I didn't think the issue was strong enough to warrant a
> change. However, after reading the other discussion on that thread (around
> the possibility of a 'matches' keyword and how code is "read out" or
> "internally verbalised"), and seeing how passionate everyone here is about
> Swift, I'm thinking that maybe it should be changed.
> >
> > The issue is that in English, 'guard' has an inverted logical
> connotation to how it is used in Swift. For example, take this sentence:
> >
> > "In some functions it's a good idea is to put some checks in place, in
> order to guard against invalid input values."
> >
> > Swift's 'guard' keyword is to guard against invalid values.
> > Or to put it another way, to ensure that we have valid values.
> >
> > However, the way it reads in Swift, we guard that we have valid values.
> >
> > I fully understand and agree that it's better to state the true
> condition for valid values here, using else to perform a contingency. And I
> understand why the word 'guard' was picked (given the above example
> sentence). I just think that 'ensure' would be

Re: [swift-evolution] [pitch] rename 'guard' to 'ensure'

[Jay Abbott via swift-evolution]

>
> I don’t read “*Guard that x is higher than 0 else … *”, but instead I
> read it like “*Guard! x must be higher than 0 else …*”.
>
>
I see, yes I hadn't considered this interpretation...


>
> Probably adding a colon could make it more clear to the reader:
>
> guard: x > 0 else {
> return
> }
>
> But then we risk to add complexity to the syntax.
>

I actually like this better than ensure - it makes a lot of sense. It would
also force the second interpretation as you mentioned above. If 'guard' was
simply renamed to 'guard:' (or depending on how you look at it, required to
have a colon after it), how would it complicate the syntax?
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

[swift-evolution] [pitch] rename 'guard' to 'ensure'

[Jay Abbott via swift-evolution]

I mentioned this in passing on a different thread
.
Although it caused some slight confusion when I first learned the 'guard'
keyword, it was easy to overcome and I didn't think the issue was strong
enough to warrant a change. However, after reading the other discussion on
that thread (around the possibility of a 'matches' keyword and how code is
"read out" or "internally verbalised"), and seeing how passionate everyone
here is about Swift, I'm thinking that maybe it should be changed.

The issue is that in English, 'guard' has an inverted logical connotation
to how it is used in Swift. For example, take this sentence:

"In some functions it's a good idea is to put some checks in place, in
order to guard against invalid input values."

Swift's 'guard' keyword is to *guard* against *invalid* values.
Or to put it another way, to *ensure* that we have *valid* values.

However, the way it reads in Swift, we *guard* that we have *valid* values.

I fully understand and agree that it's better to state the *true* condition
for *valid* values here, using *else* to perform a contingency. And I
understand why the word 'guard' was picked (given the above example
sentence). I just think that 'ensure' would be better.

ensure x > 0 else {
return
}

ensure camp.isSafe else {
runForTheHills()
}

ensure let thingy = object as? Thingy else {
return ExamineThingyResult.NotAThingy
}

As I said, I thought it was too small a niggle to worry about, but seeing
how people on here care so much about making Swift better, and the
willingness to change things, I thought I'd suggest it. Although it would
be a breaking change, the code changes are easy.

So what do people think? In particular it would be interesting to hear from
non-native English speakers on this, did 'guard' confuse you or did 'guard'
cause your understanding of the English word to be confused?
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Pitch] Reimagining guard case/if case

[Jay Abbott via swift-evolution]

Oh... and yeah I like the idea of dropping the 'case' word in this context,
it makes sense.

On Mon, 24 Oct 2016 at 17:44 Jay Abbott  wrote:

> Hey Erica,
>
> It's not clear in the examples, but are you proposing to drop the 'else'
> from guard too?
>
> I hope not, because 'guard' as a keyword is slightly confusing as it is,
> the 'else' is the only part of it that makes it clear.
>
> In English you generally want to guard "against" something, so guard reads
> a bit like:
> guard [against] x == 0 else {do this}
> Which doesn't make sense, what it really means is:
> guard [that] x == 0, else {do this}
>
> I think that "ensure" would have been a better word:
> ensure [that] x == 0 else {do this}
>
> Anyway - hopefully this is just an oversight.
>
>
> On Mon, 24 Oct 2016 at 17:25 Erica Sadun via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> Pitch: I'd like to simplify `if case`/`guard case` to drop `case` and
> replace the equal sign with the pattern matching (`~=`) operator. I think
> it's simpler, reads better, and emphasizes "this is pattern matching" in a
> way the current grammar does not.
>
> gist: https://gist.github.com/erica/1a5ce8a5157158c6400efb550778cead
>
> Simplifying guard case/if case syntax
>
>- Proposal: TBD
>- Author: Erica Sadun 
>- Status: TBD
>- Review manager: TBD
>
>
> 
> Introduction
>
> This proposal simplifies guard case and if case grammar. It drops the case 
> keyword
> and replaces the assignment sign with the pattern matching (~=) operator.
> The results are simpler, they reads better, and it transfers the
> responsibility of saying "this is pattern matching" from case to ~=.
>
> Swift-evolution thread: [Pitch] Reimagining guard case/if case
> 
> 
> Motivation
>
> Swift's guard case and if case statements stand out for their unintuitive
> approach. They look like assignment statements but they are not assignment
> statements. They present difficulties for new language adopters because
> they combine several concepts in a confusing form. They are arguably
> underutilized by language experts.
>
> Both guard case and `if case statements perform simultaneous pattern
> matching and conditional binding. Here are examples demonstrating their use
> in current Swift:
>
> enum Result { case success(T), error(Error) }
>
> // valid Swift
> guard case let .success(value) = result
> else { ... }
>
> // valid Swift
> guard case .success(let value) = result
> else { ... }
>
> The status quo is iteratively built up in this fashion:
>
>- = performs assignment
>- let x = performs binding
>- if let x = performs conditional binding
>- if case .foo(let x) = performs conditional binding *and* pattern
>matching
>
> When using if case/guard case in the absense of conditional binding, it
> duplicates basic pattern matching but uses less obvious semantics. These
> two statements are functionally identical:
>
> if range ~= myValue { ... } // simpler
> if case range = myValue { ... } // confusing
>
> The problems with guard case and if case include:
>
>- The = operator looks like assignment and not like pattern matching (
>~=).
>- The case layout is both too close to a switch's case but doesn't
>follow its syntax. In switch, a case is followed by a colon, not an
>equal sign.
>- Using the case syntax is unneccessarily wordy. It incorporates case,
>=, and optionally let/var assignments.
>
>
> Detailed
> Design
>
> This proposal replaces the current syntax with a simpler grammar that
> prioritizes pattern matching but mirrors basic conditional binding. The new
> syntax drops the case keyword and replaces = with ~=. The results look
> like this:
>
> guard let .success(value) ~= result { ... }
> guard .success(let value) ~= result { ... }
> if let .success(value) ~= result { ... }
> if .success(let value) ~= result { ... }
> guard let x? ~= anOptional { ... }
> if let x? ~= anOptional { ... }
>
> In this update:
>
>- The case keyword is subsumed into the (existing) pattern matching
>operator
>- The statements adopt the existing if-let and guard-let syntax,
>including Optional syntactic sugar.
>
> if let x = anOptional { ... } // current
> if case let x? = anOptional { ... } // current, would be removed
>
> if let x? ~= anOptional { ... } // proposed replacement for `if case`
>
> On adopting this syntax, the two identical range tests naturally unify to
> this single version:
>
> if range ~= myValue { ... } // before
> if case range = myValue { ... } // before
>
> if range ~= myValue { ... } // after
>
> Using pattern matching without conditional binding naturally 

Re: [swift-evolution] [Pitch] Reimagining guard case/if case

[Jay Abbott via swift-evolution]

Hey Erica,

It's not clear in the examples, but are you proposing to drop the 'else'
from guard too?

I hope not, because 'guard' as a keyword is slightly confusing as it is,
the 'else' is the only part of it that makes it clear.

In English you generally want to guard "against" something, so guard reads
a bit like:
guard [against] x == 0 else {do this}
Which doesn't make sense, what it really means is:
guard [that] x == 0, else {do this}

I think that "ensure" would have been a better word:
ensure [that] x == 0 else {do this}

Anyway - hopefully this is just an oversight.


On Mon, 24 Oct 2016 at 17:25 Erica Sadun via swift-evolution <
swift-evolution@swift.org> wrote:

> Pitch: I'd like to simplify `if case`/`guard case` to drop `case` and
> replace the equal sign with the pattern matching (`~=`) operator. I think
> it's simpler, reads better, and emphasizes "this is pattern matching" in a
> way the current grammar does not.
>
> gist: https://gist.github.com/erica/1a5ce8a5157158c6400efb550778cead
>
> Simplifying guard case/if case syntax
>
>- Proposal: TBD
>- Author: Erica Sadun 
>- Status: TBD
>- Review manager: TBD
>
>
> 
> Introduction
>
> This proposal simplifies guard case and if case grammar. It drops the case 
> keyword
> and replaces the assignment sign with the pattern matching (~=) operator.
> The results are simpler, they reads better, and it transfers the
> responsibility of saying "this is pattern matching" from case to ~=.
>
> Swift-evolution thread: [Pitch] Reimagining guard case/if case
> 
> 
> Motivation
>
> Swift's guard case and if case statements stand out for their unintuitive
> approach. They look like assignment statements but they are not assignment
> statements. They present difficulties for new language adopters because
> they combine several concepts in a confusing form. They are arguably
> underutilized by language experts.
>
> Both guard case and `if case statements perform simultaneous pattern
> matching and conditional binding. Here are examples demonstrating their use
> in current Swift:
>
> enum Result { case success(T), error(Error) }
>
> // valid Swift
> guard case let .success(value) = result
> else { ... }
>
> // valid Swift
> guard case .success(let value) = result
> else { ... }
>
> The status quo is iteratively built up in this fashion:
>
>- = performs assignment
>- let x = performs binding
>- if let x = performs conditional binding
>- if case .foo(let x) = performs conditional binding *and* pattern
>matching
>
> When using if case/guard case in the absense of conditional binding, it
> duplicates basic pattern matching but uses less obvious semantics. These
> two statements are functionally identical:
>
> if range ~= myValue { ... } // simpler
> if case range = myValue { ... } // confusing
>
> The problems with guard case and if case include:
>
>- The = operator looks like assignment and not like pattern matching (
>~=).
>- The case layout is both too close to a switch's case but doesn't
>follow its syntax. In switch, a case is followed by a colon, not an
>equal sign.
>- Using the case syntax is unneccessarily wordy. It incorporates case,
>=, and optionally let/var assignments.
>
>
> Detailed
> Design
>
> This proposal replaces the current syntax with a simpler grammar that
> prioritizes pattern matching but mirrors basic conditional binding. The new
> syntax drops the case keyword and replaces = with ~=. The results look
> like this:
>
> guard let .success(value) ~= result { ... }
> guard .success(let value) ~= result { ... }
> if let .success(value) ~= result { ... }
> if .success(let value) ~= result { ... }
> guard let x? ~= anOptional { ... }
> if let x? ~= anOptional { ... }
>
> In this update:
>
>- The case keyword is subsumed into the (existing) pattern matching
>operator
>- The statements adopt the existing if-let and guard-let syntax,
>including Optional syntactic sugar.
>
> if let x = anOptional { ... } // current
> if case let x? = anOptional { ... } // current, would be removed
>
> if let x? ~= anOptional { ... } // proposed replacement for `if case`
>
> On adopting this syntax, the two identical range tests naturally unify to
> this single version:
>
> if range ~= myValue { ... } // before
> if case range = myValue { ... } // before
>
> if range ~= myValue { ... } // after
>
> Using pattern matching without conditional binding naturally simplifies to
> a standalone Boolean condition clause.
>
> Impact
> on Existing Code
>
> This proposal is 

Re: [swift-evolution] [pitch] make @nonobjc the default

[Jay Abbott via swift-evolution]

Ok, good to know that's just a bug. But I still think that implicit @objc
should be removed. For bridged classes with obj-c-specific interfaces (for
example a method that takes a selector), it would be better if the
Swift-side interface was forced to make a Swifty interface that hides it.
This way, the people maintaining an interface have to either a) write a
wrapper with a Swifty interface; or b) explicitly cop out and use @objc and
inform their users that they may also have to do the same in some
situations; or c) persuade their employers to let them port the whole thing
to pure Swift, which sounds like a lot of fun and is probably what they
really want to do :D.

I'm not really sure how this works though, at what level this is applied?
Maybe it's more to do with the default build settings in Xcode than Swift
itself? I just would rather see Swift stand alone by default.



On Wed, 19 Oct 2016 at 03:51 Douglas Gregor <dgre...@apple.com> wrote:

>
>
> Sent from my iPhone
>
> > On Oct 18, 2016, at 4:00 PM, Jay Abbott via swift-evolution <
> swift-evolution@swift.org> wrote:
> >
> > Currently, if you extend a class that comes from obj-c, Swift assumes
> you want to make those methods available to call from obj-c code. If you
> add operators, you must declare them as @nonobjc otherwise the bridging
> header which is generated declares obj-c methods with the operator
> character as the method name, which isn't valid in obj-c and causes compile
> errors.
>
> The operators bit is an outright bug, which I believe has already been
> fixed in master.
>
> > I'm just wondering how others feel about this - my feeling is that a
> Swift developer should not have to know anything about obj-c when doing
> Swifty things to a bridged class from a framework (such as extending it).
> As far as they are concerned the framework class should compile the same as
> if it were fully implemented in Swift.
>
> Modulo bugs like the above, I think we already have this property? Swift
> declarations are exposed to Objective-C if they can be. One doesn't
> generally have to think about it unless you're trying to use those
> declarations from Objective-C.
>
> > Thoughts?
>
> I actually thought you were going further with this, eliminating the
> inferred @objc except in cases where it's needed to work with an existing
> framework. That's something I'd love to see someone working on.
>
>   - Doug
>
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

[swift-evolution] [pitch] make @nonobjc the default

[Jay Abbott via swift-evolution]

Currently, if you extend a class that comes from obj-c, Swift assumes you
want to make those methods available to call from obj-c code. If you add
operators, you must declare them as @nonobjc otherwise the bridging header
which is generated declares obj-c methods with the operator character as
the method name, which isn't valid in obj-c and causes compile errors.

I'm just wondering how others feel about this - my feeling is that a Swift
developer should not have to know anything about obj-c when doing Swifty
things to a bridged class from a framework (such as extending it). As far
as they are concerned the framework class should compile the same as if it
were fully implemented in Swift.

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

Re: [swift-evolution] [Review] SE-0144: Allow Single Dollar Sign as a Valid Identifier

[Jay Abbott via swift-evolution]

>
> Now for the elephant in the room: '$' is a currency symbol. As such it
> should be handled like any other currency symbol. Thinking otherwise would
> be very culturally offensive.
>

The fact that it's a currency symbol is totally irrelevant.
It's s symbol. Here are some others:
! & * ( . -

You wouldn't want to allow an identifier to start with any of those
symbols, for obvious reasons.

Programming languages need to reserve some characters and words for special
meanings. In this case: Yes $0, $1, etc. was probably influenced from other
languages; yes $ was probably used in those languages because it was a
convenient available character in the ASCII set, and therefore easy to type
on standard US and other English keyboards (where those languages were
developed and primarily used). This is simple history/legacy, and nothing
to do with the fact it is a currency symbol or any other reason that might
cause offense to anyone.

Unfortunately I think you have misunderstood this proposal. It is to allow
$ as a single-character identifier, even though it is reserved and not
allowed as an identifier-head.

If you think $ should be allowed as the first character of any identifier
(including the single $), then that would be a different proposal which
should cover all the other effects properly.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [pitch] "import" declaration, support for comma-separated modules

[Jay Abbott via swift-evolution]

-1 - I don't like this.

I never understood the desire for *extreme* vertical conciseness, it tends
to make code less readable in general and definitely makes diffs a lot
harder harder to read.


On Sun, 16 Oct 2016 at 11:26 Anton Zhilin via swift-evolution <
swift-evolution@swift.org> wrote:

> Purely additive feature, not for Swift 4 Phase 1.
> And a -1 from me for reasons already mentioned.
> ___
> 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] Replace Fileprivate with Hidden + Import Hidden

[Jay Abbott via swift-evolution]

Oops, correction:

@unshelter(self); or
@unshelter(aWotsit)
// Inside a Wotsit or a Wotsit subclass this would work, y becomes
available.

Should be:

@unshelter(aThing)
// Inside a Wotsit or a Wotsit subclass this would work, y becomes
available.


On Mon, 17 Oct 2016 at 13:38 Jay Abbott  wrote:

> I'm not sure of my own opinions on this one as I can see good points on
> both sides. There also seem to be a variety of different discussions with
> similar concerns. So at the risk of confusing things I'm suggesting another
> idea, with the hope/intention of promoting some deeper thought and helping
> us figure out what is needed/wanted.
>
> I will use the word 'sheltered' here, apologies if that is confusing, it
> just means protected/hidden/whatever but without any existing notions of
> what those might mean. It might not be the best word either, I just picked
> it from a list of synonyms for 'protected'.
>
> Class authors can (now) if they want provide their own way to explicitly
> access some private members through a public interface:
>
> public class Thing {
> private var x: Int
> public var shelteredX: Int {
> get { return x }
> set { x = newValue }
> }
> }
>
> But this isn't ideal as it just causes excess boilerplate code and doesn't
> hide it from anyone or suggest they shouldn't normally use it (other than
> the explicit naming). However, perhaps the compiler could help with this
> type of pattern as follows:
>
> public class Thing {
> sheltered var x: Int {
> get { return x } // not sure how this would work - x is also the
> backing ivar so you don't have to declare it twice as _x and x.
> set { x = newValue }
> }
>// accessors provided - internal access to x is direct, sheltered
> access is via accessors
>
> sheltered var y: Int
> // No accessors provided, sheltered access to y is direct
> }
>
> For members with 'sheltered' access:
> * Don't by default allow access to the sheltered members or accessors -
> they are equivalent to private (or maybe fileprivate)
> * Provide a way to expose them in a given scope
> * I think it can be applied to methods too
>
> For example:
> var aThing = Thing()
> aThing.x = 7 // NOT ALLOWED: x is sheltered.
> @unshelter(aThing) // aThing is unsheltered in the remainder of its scope.
> aThing.x = 7 // NOW ALLOWED
>
> One good thing is that this is very explicit where you use it.
>
> Sheltered groups might also be a thing:
>
> Definition:
> sheltered var x: Int
> sheltered var y: Int
> Usage:
> @unshelter(aThing)
> // x is available, y isn't
> @unshelter(aThing)
> // x and y are available
>
> "Subclasses" and "Wotsits" are author-defined identifiers, not keywords.
> This is a bit like friends and protected, but using an honesty system,
> where friends can easily declare themselves as friends by unsheltering all
> the Wotsits group, and subclasses (not enforced) would unshelter the
> Subclasses group. That is, the author's intentions are clear, but other
> classes can abuse it to get access. If the author doesn't want to allow
> abuse, they can do this:
>
> Definition:
> sheltered var x: Int
> sheltered var y: Int
>
> Usage:
> @unshelter(self); or
> @unshelter(anOtherThing)
> // Works inside a Thing subclass, x becomes available. The scope in which
> @unshelter is used must match the type of the shelter group.
>
> @unshelter(self); or
> @unshelter(aWotsit)
> // Inside a Wotsit or a Wotsit subclass this would work, y becomes
> available.
>
> I'm just spitballing here, this isn't fully thought through. Perhaps a
> where clause would be better instead of a type annotation for the shelter
> groups, so you could list multiple types that are allowed to unshelter that
> group. You might be able to abuse it still by putting something in an
> extension of an allowed class, so that may need some further thought.
>
> This is of course more complex that other proposed solutions, I'm just
> trying to combine all the desires people seem to have and see what people
> think - do we want more control and are happy with a bit more complexity?
> or should it be simple and less control? Personally I actually don't have
> much of an opinion on it because I haven't used Swift enough yet to come a
> cropper of such things.
>
>
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Replace Fileprivate with Hidden + Import Hidden

[Jay Abbott via swift-evolution]

I'm not sure of my own opinions on this one as I can see good points on
both sides. There also seem to be a variety of different discussions with
similar concerns. So at the risk of confusing things I'm suggesting another
idea, with the hope/intention of promoting some deeper thought and helping
us figure out what is needed/wanted.

I will use the word 'sheltered' here, apologies if that is confusing, it
just means protected/hidden/whatever but without any existing notions of
what those might mean. It might not be the best word either, I just picked
it from a list of synonyms for 'protected'.

Class authors can (now) if they want provide their own way to explicitly
access some private members through a public interface:

public class Thing {
private var x: Int
public var shelteredX: Int {
get { return x }
set { x = newValue }
}
}

But this isn't ideal as it just causes excess boilerplate code and doesn't
hide it from anyone or suggest they shouldn't normally use it (other than
the explicit naming). However, perhaps the compiler could help with this
type of pattern as follows:

public class Thing {
sheltered var x: Int {
get { return x } // not sure how this would work - x is also the
backing ivar so you don't have to declare it twice as _x and x.
set { x = newValue }
}
   // accessors provided - internal access to x is direct, sheltered access
is via accessors

sheltered var y: Int
// No accessors provided, sheltered access to y is direct
}

For members with 'sheltered' access:
* Don't by default allow access to the sheltered members or accessors -
they are equivalent to private (or maybe fileprivate)
* Provide a way to expose them in a given scope
* I think it can be applied to methods too

For example:
var aThing = Thing()
aThing.x = 7 // NOT ALLOWED: x is sheltered.
@unshelter(aThing) // aThing is unsheltered in the remainder of its scope.
aThing.x = 7 // NOW ALLOWED

One good thing is that this is very explicit where you use it.

Sheltered groups might also be a thing:

Definition:
sheltered var x: Int
sheltered var y: Int
Usage:
@unshelter(aThing)
// x is available, y isn't
@unshelter(aThing)
// x and y are available

"Subclasses" and "Wotsits" are author-defined identifiers, not keywords.
This is a bit like friends and protected, but using an honesty system,
where friends can easily declare themselves as friends by unsheltering all
the Wotsits group, and subclasses (not enforced) would unshelter the
Subclasses group. That is, the author's intentions are clear, but other
classes can abuse it to get access. If the author doesn't want to allow
abuse, they can do this:

Definition:
sheltered var x: Int
sheltered var y: Int

Usage:
@unshelter(self); or
@unshelter(anOtherThing)
// Works inside a Thing subclass, x becomes available. The scope in which
@unshelter is used must match the type of the shelter group.

@unshelter(self); or
@unshelter(aWotsit)
// Inside a Wotsit or a Wotsit subclass this would work, y becomes
available.

I'm just spitballing here, this isn't fully thought through. Perhaps a
where clause would be better instead of a type annotation for the shelter
groups, so you could list multiple types that are allowed to unshelter that
group. You might be able to abuse it still by putting something in an
extension of an allowed class, so that may need some further thought.

This is of course more complex that other proposed solutions, I'm just
trying to combine all the desires people seem to have and see what people
think - do we want more control and are happy with a bit more complexity?
or should it be simple and less control? Personally I actually don't have
much of an opinion on it because I haven't used Swift enough yet to come a
cropper of such things.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] stored properties in extensions (was: associated objects)

[Jay Abbott via swift-evolution]

T.J.: This would not replace the need for stored properties in extensions.
For example: Imagine adding a property to UIView in an extension, then
recursively traversing a view hierarchy and accessing the property. This
thought experiment should quickly show you why wrapping and adding
properties (or even subclassing and adding properties) simply won't work,
even if an easy forwarding mechanism were in place. You do not have control
of the creation of all those objects, so you can't make them your type, and
even if you could, you would have to provide a wrapper class for every
UIView subclass, and then what if another module also wants to do the same?

However, note that it would be possible to only add the extra storage to
instances where some additional properties are actually accessed/in-use.
The pointer for the stored property data in the side-table would simply be
nil if it has never been used.

On Sun, 16 Oct 2016 at 23:31 T.J. Usiyan <griotsp...@gmail.com> wrote:

> How much would convenient method forwarding when wrapping change how
> desirable this feature is? I am hesitant to add storage to already
> allocated instances if we can avoid it.
>
> On Sun, Oct 16, 2016 at 5:02 PM, Jay Abbott via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> Greg:
>
> I've CCed you in case you want to respond to my comments below about
> potentially optimising "extensionIvar" access without using a dictionary.
> See my response to Haravikk below.
>
> Benjamin:
>
> Implementation wise, weak does *not* currently have the effect of storing
> associated values. It does however mean that any object with weak
> references stays allocated after being deinited, until all the weak
> references are evaluated and zeroed (they are not zeroed when the object
> deinits, zeroing is done lazily. See
> https://www.mikeash.com/pyblog/friday-qa-2015-12-11-swift-weak-references.html
> for a detailed discussion).
>
> However, this seems likely to change at some point when Greg's changes are
> merged. Weakly referenced objects would cause a side-table to be allocated,
> with the benefits that the object could be deallocated immediately after
> deinit, and only the side-table would hang around (to service attempts to
> access weak references, which would still be lazily zeroed). The small
> disadvantage of this (which only applies to instances that actually have
> had weak references) is that an extra pointer dereference is needed for
> retain, release, and weak reference access (and some other things). But a
> big advantage is that the side-allocation could be used for other things
> too, like stored properties.
>
> Haravikk:
>
> It can be done efficiently using Greg's proposed changes. The current
> implementation on his branch (
> https://github.com/gparker42/swift/tree/new-refcount-representation) does
> not have any extra space for stored properties, but he has discussed
> "extensionIvars" before on swift-dev, and proposed that the side-table
> structure contains a pointer to a dictionary for these. However, I think
> with some dynamic loader magic this could be implemented as a dynamic
> structure instead of a dictionary. Each time a module is loaded, the side
> allocation for stored properties could be extended and the offsets to the
> newly extended properties could be fixed-up based on the current size.
> Existing instances could be handled by using the structure size as a
> version number (stored at the beginning of this area), it would check if
> the instance is at the current version and migrate/update the structure as
> needed (realloc it and init the extended area to zero, updating the
> size/version field). These checks would be less overhead than a
> getter/setter function call, so using dot notation to access the properties
> would not be deceiving programmers about the cost.
>
> Anton:
>
> Why should it matter where data is stored? Can you expand on any reasons
> for wanting object data to be contiguous, or thinking that it shouldn't be
> allowed for Swift classes?
>
>
> ___
> 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] stored properties in extensions (was: associated objects)

[Jay Abbott via swift-evolution]

Greg:

I've CCed you in case you want to respond to my comments below about
potentially optimising "extensionIvar" access without using a dictionary.
See my response to Haravikk below.

Benjamin:

Implementation wise, weak does *not* currently have the effect of storing
associated values. It does however mean that any object with weak
references stays allocated after being deinited, until all the weak
references are evaluated and zeroed (they are not zeroed when the object
deinits, zeroing is done lazily. See
https://www.mikeash.com/pyblog/friday-qa-2015-12-11-swift-weak-references.html
for a detailed discussion).

However, this seems likely to change at some point when Greg's changes are
merged. Weakly referenced objects would cause a side-table to be allocated,
with the benefits that the object could be deallocated immediately after
deinit, and only the side-table would hang around (to service attempts to
access weak references, which would still be lazily zeroed). The small
disadvantage of this (which only applies to instances that actually have
had weak references) is that an extra pointer dereference is needed for
retain, release, and weak reference access (and some other things). But a
big advantage is that the side-allocation could be used for other things
too, like stored properties.

Haravikk:

It can be done efficiently using Greg's proposed changes. The current
implementation on his branch (
https://github.com/gparker42/swift/tree/new-refcount-representation) does
not have any extra space for stored properties, but he has discussed
"extensionIvars" before on swift-dev, and proposed that the side-table
structure contains a pointer to a dictionary for these. However, I think
with some dynamic loader magic this could be implemented as a dynamic
structure instead of a dictionary. Each time a module is loaded, the side
allocation for stored properties could be extended and the offsets to the
newly extended properties could be fixed-up based on the current size.
Existing instances could be handled by using the structure size as a
version number (stored at the beginning of this area), it would check if
the instance is at the current version and migrate/update the structure as
needed (realloc it and init the extended area to zero, updating the
size/version field). These checks would be less overhead than a
getter/setter function call, so using dot notation to access the properties
would not be deceiving programmers about the cost.

Anton:

Why should it matter where data is stored? Can you expand on any reasons
for wanting object data to be contiguous, or thinking that it shouldn't be
allowed for Swift classes?
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Review] SE-0144: Allow Single Dollar Sign as a Valid Identifier

[Jay Abbott via swift-evolution]

> * What is your evaluation of the proposal?

I am against it.

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

No - if this change were made it would be a regression. The rationale for
removing it in the first place was and remains valid.

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

No, it goes in the opposite direction. $ is not valid as the first
character of a user-defined identifier and therefore should not be a valid
identifier by itself.

Side-note: Personally I think $ as the first character of an identifier
should be reserved for shorthand ways to do other things, in line with how
it is currently used in Swift.
If used consistently, programmers will know they are seeing a language
shortcut. Allowing $ as an identifier would break some of the natural
intuition a programmer is able to use when learning and reading Swift code.

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

The proposal seems purely for the benefit of the Dollar library, which
could work just as well with any other identifier. Code using the dollar
library is reminiscent of some other languages and programming styles. This
isn't really a comment about the proposal itself, more the motivation
behind it.

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

I read the proposal and was perplexed by it, so I looked into the Dollar
library to try and understand the motivation behind the proposal. It is a
clever library with some nice features and tricks, but in many ways it
seems to be designed to enable programmers to write non-Swifty code in
Swift. I can understand the frustration of the author and users of the
library, but its functionality could be provided in a Swifty way using
extensions and generics, and I think if those users embraced this they
would ultimately appreciate the change. If not then they might as well
stick to another language.


On Sun, 16 Oct 2016 at 17:31 Jacob Bandes-Storch via swift-evolution <
swift-evolution@swift.org> wrote:

> Proposal link:
>
>
> https://github.com/apple/swift-evolution/blob/master/proposals/0144-allow-single-dollar-sign-as-valid-identifier.md
>
>
> * What is your evaluation of the proposal?
>
>
> -1.
>
> The proposal does not actually provide motivation for keeping $ beyond
> "the Dollar library already uses it".
>
> A more Swifty way for a library to introduce these operations would be
> with extensions. Here are some suggestions, based off the first several
> operations described in the library's readme:
>
> $.at → convenience subscript(Index...) for Collection
> $.chunk → convenience function for Sequence
> $.compact → flatMap{$0}
> $.contains → already exists as Sequence.contains
> $.cycle → convenience function for Collection
> $.difference → convenience function on Collection, or just use Set
> operations, or filter
> $.each → exists as Sequence.forEach
> $.every → extension on Sequence
> $.factorial → convenience method or postfix operator for Integer
> $.fetch → convenience function on Collection
> and so on.
>
> It looks like the author's Cent  library
> is already taking this approach.
>
>
>
> * Is the problem being addressed significant enough to warrant a
> change to Swift?
>
>
> Yes, but the change has already been made: removing $ as a valid
> identifier ;-)
>
>
>
> * Does this proposal fit well with the feel and direction of Swift?
>
>
> Not really. If anything, IMO, the dollar sign feels more like an operator
> character. (However, it's probably here to stay in identifiers because of
> closure parameters and LLDB variables.)
>
>
>
> * If you have used other languages or libraries with a similar
> feature, how do you feel that this proposal compares to those?
>
>
> The Dollar library resembles the style of JavaScript libraries such as
> jQuery or Underscore, but that isn't a positive thing in my mind — as
> mentioned above, the Swift way of doing things is different.
>
>
>
> * How much effort did you put into your review? A glance, a quick
> reading, or an in-depth study?
>
>
> Thorough reading of the proposal; brief glance at the library's readme on
> GitHub.  Lots of time thinking about operator & identifier characters for a
> forthcoming proposal.
>
> ___
> 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] stored properties in extensions (was: associated objects)

[Jay Abbott via swift-evolution]

Karl, interesting point... perhaps a similar scheme could work for value
types (using the COW refcount)?

On Thu, 13 Oct 2016 at 16:02 Karl Wagner <razie...@gmail.com> wrote:

> That's great! I suppose the idea of allocating a bit of extra storage for
> similar data in value types is some sort of heresy?
>
> Would there be a conceptual reason for that; which explains why it's okay
> for reference-types but not for values? Personally I feel like it's a kind
> of C legacy, due to performance and layout expectations that C sets about
> value-types ¯\_(ツ)_/¯
>
> Karl
>
>
> Sent from my iPad
>
> On 12 Oct 2016, at 07:54, Greg Parker <gpar...@apple.com> wrote:
>
>
> On Oct 11, 2016, at 3:02 PM, Jay Abbott via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> Implementation idea No. 4:
>
>
> The basic concept is that the dynamic linker would fixup the offsets as
> well as relocating the addersses, allowing the size of objects (and maybe
> structs?) to change at link-time. The process might be something like this:
>
> * References to members defined in extensions would compile to have an
> offset symbol instead of a value - so they can be fixed up later
> * The linker would scan all the shared objects that are referenced (and
> thus might get linked)
> * Build up a list of Stored Properties In ExtensionS (SPIES, muhahaha) for
> each class.
> * Append the extra fields (increase the size the class), decide where each
> member goes in the extended layout and fixup the offsets
> * Carry on with normal relocation
>
> There are quite a few assumptions in the above, and probably quite a few
> misunderstandings about how things work on my part too (I'm not an expert
> at this), however I think it should work in principle. Some questions about
> my assumptions: Can linker know in advance all the potential modules that
> could be linked, or is this done more lazily and it only knows about what
> it's linking right now? Is it ok for the size to change - I don't know if
> it's a static sizeof() or if it could be (or already is) stored in the isa?
>
>
> This sort of scheme isn't dynamic enough. The worst-case is a extension in
> a library that gets dlopen()ed at runtime on a class that is already
> loaded. The build-time linker can't know anything about it. The loader and
> the runtime will see it, but at that point the class may already be in use
> and may already have instances allocated. If you want to handle the
> dlopen() case then you need some way to add storage to arbitrary objects
> that have already been allocated.
>
>
> Ole Begemann wrote:
>
>
> For what it's worth, Greg Parker (Cc'ed) started a discussion back in
> March that I think is relevant here:
> https://lists.swift.org/pipermail/swift-dev/Week-
> of-Mon-20160314/001424.html
>
> Here's the relevant part:
>
> "I am considering a new representation for Swift refcounts and other
> per-object data. This is an outline of the scheme. Comments and suggestions
> welcome.
>
> Today, each object stores 64-bits of refcounts and flags after the isa
> field.
>
> In this new system, each object would store a pointer-size field after the
> isa field. This field would have two cases: it could store refcounts and
> flags, or it could store a pointer to a side allocation that would store
> refcounts and flags and additional per-object data.
>
> Advantages:
> …
> * Allows inexpensive per-object storage for future features like
> associated references or class extensions with instance variables.
> …"
>
> I don't know the current status of this idea (implemented? planned?
> abandoned?). Also, it's worth noting that this would only apply to classes,
> not value types.
>
>
> I'm working on this right now:
> https://github.com/gparker42/swift/tree/new-refcount-representation
>
> If it goes well it will provide the runtime implementation space needed
> for associated objects or stored properties in extensions. Such storage
> would be less efficient than "real" stored properties. Any object with that
> storage attached would also suffer additional performance penalties to
> refcounting and deallocation. On the plus side there is no memory penalty
> to objects that don't have additional storage, and there is no contention
> over a big global association table like there is in Objective-C's
> associated object implementation.
>
> Note that the runtime implementation is not the only problem. The
> optimizer folks hate the fact that stored properties in extensions defeat
> the compiler's visibility into the deinit behavior of all types, even if
> most types are unaffected at runtime.
>
>
> --
> Greg Parker gpar...@apple.com Runtime Wrangler
>
>
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] stored properties in extensions

[Jay Abbott via swift-evolution]

Interestingly, if all the stored properties defined in extensions could be
determined at link-time, the size/layout of the side-table could include
them directly, removing the need for further indirection. The offsets would
still need to be fixed up, which would add some complexity to the
implementation.

On Wed, 12 Oct 2016 at 00:54 Jay Abbott  wrote:

> Wow, that's a very interesting post. Sounds a lot simpler to implement
> than my idea about fixing up offsets in the linker and preserves binary
> compatability just the same.
>
> I got some complaints when I first started talking about this that the
> runtime would have to track extra pointers and performance would be
> affected because of additional levels of indirection, which I didn't fully
> understand because it seems fairly trivial to me. Perhaps this twin-purpose
> refcount/side-table pointer also suffers the same concerns?
>
> On Wed, 12 Oct 2016 at 00:21 Ole Begemann via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>  > I think the language devs must have some idea how this will work, but
>
>  > don't seem to want to share/discuss it at the moment. I was hoping for
>
>  > some feedback about my implementation ideas - whether they are along the
>
>  > right lines, or way off, or not necessary (because the implementation
>
>  > strategy is already known). Perhaps this the wrong list for that kind of
>
>  > discussion?
>
>
>
> For what it's worth, Greg Parker (Cc'ed) started a discussion back in
>
> March that I think is relevant here:
>
>
> https://lists.swift.org/pipermail/swift-dev/Week-of-Mon-20160314/001424.html
>
>
>
> Here's the relevant part:
>
>
>
> "I am considering a new representation for Swift refcounts and other
>
> per-object data. This is an outline of the scheme. Comments and
>
> suggestions welcome.
>
>
>
> Today, each object stores 64-bits of refcounts and flags after the isa
>
> field.
>
>
>
> In this new system, each object would store a pointer-size field after
>
> the isa field. This field would have two cases: it could store refcounts
>
> and flags, or it could store a pointer to a side allocation that would
>
> store refcounts and flags and additional per-object data.
>
>
>
> Advantages:
>
> …
>
> * Allows inexpensive per-object storage for future features like
>
> associated references or class extensions with instance variables.
>
> …"
>
>
>
> I don't know the current status of this idea (implemented? planned?
>
> abandoned?). Also, it's worth noting that this would only apply to
>
> classes, not value types.
>
>
>
> Ole
>
> ___
>
> 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] stored properties in extensions

[Jay Abbott via swift-evolution]

Wow, that's a very interesting post. Sounds a lot simpler to implement than
my idea about fixing up offsets in the linker and preserves binary
compatability just the same.

I got some complaints when I first started talking about this that the
runtime would have to track extra pointers and performance would be
affected because of additional levels of indirection, which I didn't fully
understand because it seems fairly trivial to me. Perhaps this twin-purpose
refcount/side-table pointer also suffers the same concerns?

On Wed, 12 Oct 2016 at 00:21 Ole Begemann via swift-evolution <
swift-evolution@swift.org> wrote:

 > I think the language devs must have some idea how this will work, but

 > don't seem to want to share/discuss it at the moment. I was hoping for

 > some feedback about my implementation ideas - whether they are along the

 > right lines, or way off, or not necessary (because the implementation

 > strategy is already known). Perhaps this the wrong list for that kind of

 > discussion?



For what it's worth, Greg Parker (Cc'ed) started a discussion back in

March that I think is relevant here:

https://lists.swift.org/pipermail/swift-dev/Week-of-Mon-20160314/001424.html



Here's the relevant part:



"I am considering a new representation for Swift refcounts and other

per-object data. This is an outline of the scheme. Comments and

suggestions welcome.



Today, each object stores 64-bits of refcounts and flags after the isa

field.



In this new system, each object would store a pointer-size field after

the isa field. This field would have two cases: it could store refcounts

and flags, or it could store a pointer to a side allocation that would

store refcounts and flags and additional per-object data.



Advantages:

…

* Allows inexpensive per-object storage for future features like

associated references or class extensions with instance variables.

…"



I don't know the current status of this idea (implemented? planned?

abandoned?). Also, it's worth noting that this would only apply to

classes, not value types.



Ole

___

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] Is there information about phases/versions/releases and scope?

[Jay Abbott via swift-evolution]

So does that mean there's not going to be any 3.x versions between 3.0 and
4.0?

On Tue, 11 Oct 2016 at 23:55 Xiaodi Wu <xiaodi...@gmail.com> wrote:

> It's described in the swift-evolution GitHub repository readme:
>
> https://github.com/apple/swift-evolution
>
>
>
> On Tue, Oct 11, 2016 at 17:53 Jay Abbott via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> I keep seeing it mentioned that some ideas are out of scope for Swift 4
> phase 1 - I understand from this list that phase 1 is to include any
> breaking changes then phase 2 (etc?) will be adding more features. That's
> all I know about it.
>
> It would be nice to know what phases are on the table and what their scope
> is. Is this phased approach documented anywhere? I found on this page
> https://swift.org/contributing/#participating-in-the-swift-evolution-process
> a reference to the "Swift Evolution review Schedule" which sounded
> promising, but it is a broken link. Also, is there a phase 2 of swift 3.0?
> Swift 3.1? What does that include? Do the phases match up to release
> versions at all in any way?
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

[swift-evolution] Is there information about phases/versions/releases and scope?

[Jay Abbott via swift-evolution]

I keep seeing it mentioned that some ideas are out of scope for Swift 4
phase 1 - I understand from this list that phase 1 is to include any
breaking changes then phase 2 (etc?) will be adding more features. That's
all I know about it.

It would be nice to know what phases are on the table and what their scope
is. Is this phased approach documented anywhere? I found on this page
https://swift.org/contributing/#participating-in-the-swift-evolution-process
a reference to the "Swift Evolution review Schedule" which sounded
promising, but it is a broken link. Also, is there a phase 2 of swift 3.0?
Swift 3.1? What does that include? Do the phases match up to release
versions at all in any way?
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] stored properties in extensions (was: associated objects)

[Jay Abbott via swift-evolution]

I agree Karl, especially the bit about the difficulty of implementation
being the limiting thing here.

I think the language devs must have some idea how this will work, but don't
seem to want to share/discuss it at the moment. I was hoping for some
feedback about my implementation ideas - whether they are along the right
lines, or way off, or not necessary (because the implementation strategy is
already known). Perhaps this the wrong list for that kind of discussion?

Anyway, I was thinking some more and I had another idea about
implementation. This could be very useful for maintaining binary
compatability in other areas too.

Implementation idea No. 4:

The basic concept is that the dynamic linker would fixup the offsets as
well as relocating the addersses, allowing the size of objects (and maybe
structs?) to change at link-time. The process might be something like this:

* References to members defined in extensions would compile to have an
offset symbol instead of a value - so they can be fixed up later
* The linker would scan all the shared objects that are referenced (and
thus might get linked)
* Build up a list of Stored Properties In ExtensionS (SPIES, muhahaha) for
each class.
* Append the extra fields (increase the size the class), decide where each
member goes in the extended layout and fixup the offsets
* Carry on with normal relocation

There are quite a few assumptions in the above, and probably quite a few
misunderstandings about how things work on my part too (I'm not an expert
at this), however I think it should work in principle. Some questions about
my assumptions: Can linker know in advance all the potential modules that
could be linked, or is this done more lazily and it only knows about what
it's linking right now? Is it ok for the size to change - I don't know if
it's a static sizeof() or if it could be (or already is) stored in the isa?

Would love to hear back from anyone who is familiar with the code if this
sounds viable or not. I'd love to go digging in there myself (I've tried a
few times but got lost) but I don't have time at the moment.


On Tue, 11 Oct 2016 at 08:19 Karl  wrote:

>
> > On 10 Oct 2016, at 21:15, Charles Srstka via swift-evolution <
> swift-evolution@swift.org> wrote:
> >
> > Right. The question is whether we *need* to add stored properties
> out-of-module, and what the use case for that is. To me it seems that
> adding them in-module is by far the more common use case, for the purposes
> of implementing protocols.
> >
> > At any rate, the rewrite option would be a great addition to Swift
> regardless of what our answer to the first question is.
> >
> > Charles
>
> I actually think out-of-module is the more common and important case. If
> you’re using a types from an external framework, it’s strange that you can
> retroactively add functionality but not additional data. That limitation,
> AFAICT, is purely due to implementation. Some well-constructed frameworks
> will allow you to add stored data to the types being used by subclassing.
> Not all are so well constructed, and as we have more and more value-types
> subclassing is not going to be a solution.
>
> You can add stored properties to objects in Python, which is one of the
> really great things about it. If you need to add a stored property to track
> some additional state you layer on top of a framework’s components, it’s
> staggering how easy it is - you don’t even need to define any new types.
>
> I personally think it’s important for Swift as a scripting language to
> have this ability - for value-types as well as classes, by default. We
> could optimise it away completely for types which aren’t public, and you
> should be able to explicitly declare a type non-extendable (similar to
> declaring it non-subclassable with ‘final’) to opt-out. I’m sure it will
> never happen, but there you go.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Pitch] Adding a `mutate` clause to computed properties and subscripts

[Jay Abbott via swift-evolution]

In case c) for example if your set implementation was something like this:
set { _internalDict["propName"] = newValue }
set { if newValue { _int |= SOME_BIT } else { _int &= ~SOME_BIT } }
Could they be implemented as 'mutate'?


On Tue, 11 Oct 2016 at 12:05 Jay Abbott  wrote:

> actually scratch point a) - that's bloody obvious :D
>
> On Tue, 11 Oct 2016 at 11:58 Jay Abbott  wrote:
>
> This is interesting. I'm trying to evaluate your statement that "No setter
> would be needed if a mutation clause is provided" but I can't think exactly
> what the compiler would do in the case where there is a 'get' and 'mutate',
> but no 'set'...
> a) when you call a non-mutating function;
> b) when you assign a new value.
> c) when get and set aren't implemented with a matching hidden var (i.e.
> using a bit in an int var or storing in a dictionary).
>
>
> On Tue, 11 Oct 2016 at 11:26 Tim Vermeulen via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> Just having getters and setters doesn’t allow this (unless the optimiser
> is really smart about it). All the current API allows is grabbing whatever
> the `get` clause returns, mutating it, and then passing it into the `set`
> clause, whatever that does. The `set` clause might not do anything, or what
> it does could be seemingly unrelated to the `get` clause, so it’s not a
> trivial task to optimise this.
>
> On 11 Oct 2016, at 06:35, Erica Sadun  wrote:
>
>
> On Oct 10, 2016, at 9:53 PM, Tim Vermeulen via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> There have been many instances where unexpected bad performance was caused
> by the interplay between getters, setters, mutations and the copy-on-write
> mechanism. For example:
>
> struct Foo {
> private var _array: [Int] = [1, 2, 3, 4, 5]
>
> var array: [Int] {
> get { return _array }
> set { _array = newValue }
> }
> }
>
> var foo = Foo()
> foo.array.append(6) // an O(n) operation
>
> I propose a `mutate` clause which provides a `mutate` function with a
> single inout parameter (similar to how `set` provides `newValue`), which
> can be used instead of a setter:
>
> var array: [Int] {
> get { return _array }
> mutate { mutate(&_array) }
> }
>
> The compiler could then translate each mutation of `foo.array` to a
> closure with an inout parameter, which is then passed into the `mutate`
> clause (which in turn is executed with `_array` as its argument, as per the
> snippet above). For example, for `foo.array.append(6)`, the compiler would
> internally generate the closure `{ (arr: inout [Int]) in arr.append(6) }`
> and pass it into the `mutate` clause, `_array` is then passed as its
> parameter and the array is updated in constant time.
>
> I apologise if that was too hard to follow.
>
> No setter would be needed if a mutation clause is provided, but I see no
> good reason to do away with setters altogether, so this proposal would be
> purely additive.
>
>
> If this is computationally better, why is it not the default behavior
> rather than an API change?
>
> -- 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] [Pitch] Adding a `mutate` clause to computed properties and subscripts

[Jay Abbott via swift-evolution]

actually scratch point a) - that's bloody obvious :D

On Tue, 11 Oct 2016 at 11:58 Jay Abbott  wrote:

> This is interesting. I'm trying to evaluate your statement that "No setter
> would be needed if a mutation clause is provided" but I can't think exactly
> what the compiler would do in the case where there is a 'get' and 'mutate',
> but no 'set'...
> a) when you call a non-mutating function;
> b) when you assign a new value.
> c) when get and set aren't implemented with a matching hidden var (i.e.
> using a bit in an int var or storing in a dictionary).
>
>
> On Tue, 11 Oct 2016 at 11:26 Tim Vermeulen via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> Just having getters and setters doesn’t allow this (unless the optimiser
> is really smart about it). All the current API allows is grabbing whatever
> the `get` clause returns, mutating it, and then passing it into the `set`
> clause, whatever that does. The `set` clause might not do anything, or what
> it does could be seemingly unrelated to the `get` clause, so it’s not a
> trivial task to optimise this.
>
> On 11 Oct 2016, at 06:35, Erica Sadun  wrote:
>
>
> On Oct 10, 2016, at 9:53 PM, Tim Vermeulen via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> There have been many instances where unexpected bad performance was caused
> by the interplay between getters, setters, mutations and the copy-on-write
> mechanism. For example:
>
> struct Foo {
> private var _array: [Int] = [1, 2, 3, 4, 5]
>
> var array: [Int] {
> get { return _array }
> set { _array = newValue }
> }
> }
>
> var foo = Foo()
> foo.array.append(6) // an O(n) operation
>
> I propose a `mutate` clause which provides a `mutate` function with a
> single inout parameter (similar to how `set` provides `newValue`), which
> can be used instead of a setter:
>
> var array: [Int] {
> get { return _array }
> mutate { mutate(&_array) }
> }
>
> The compiler could then translate each mutation of `foo.array` to a
> closure with an inout parameter, which is then passed into the `mutate`
> clause (which in turn is executed with `_array` as its argument, as per the
> snippet above). For example, for `foo.array.append(6)`, the compiler would
> internally generate the closure `{ (arr: inout [Int]) in arr.append(6) }`
> and pass it into the `mutate` clause, `_array` is then passed as its
> parameter and the array is updated in constant time.
>
> I apologise if that was too hard to follow.
>
> No setter would be needed if a mutation clause is provided, but I see no
> good reason to do away with setters altogether, so this proposal would be
> purely additive.
>
>
> If this is computationally better, why is it not the default behavior
> rather than an API change?
>
> -- 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] [Pitch] Adding a `mutate` clause to computed properties and subscripts

[Jay Abbott via swift-evolution]

This is interesting. I'm trying to evaluate your statement that "No setter
would be needed if a mutation clause is provided" but I can't think exactly
what the compiler would do in the case where there is a 'get' and 'mutate',
but no 'set'...
a) when you call a non-mutating function;
b) when you assign a new value.
c) when get and set aren't implemented with a matching hidden var (i.e.
using a bit in an int var or storing in a dictionary).


On Tue, 11 Oct 2016 at 11:26 Tim Vermeulen via swift-evolution <
swift-evolution@swift.org> wrote:

> Just having getters and setters doesn’t allow this (unless the optimiser
> is really smart about it). All the current API allows is grabbing whatever
> the `get` clause returns, mutating it, and then passing it into the `set`
> clause, whatever that does. The `set` clause might not do anything, or what
> it does could be seemingly unrelated to the `get` clause, so it’s not a
> trivial task to optimise this.
>
> On 11 Oct 2016, at 06:35, Erica Sadun  wrote:
>
>
> On Oct 10, 2016, at 9:53 PM, Tim Vermeulen via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> There have been many instances where unexpected bad performance was caused
> by the interplay between getters, setters, mutations and the copy-on-write
> mechanism. For example:
>
> struct Foo {
> private var _array: [Int] = [1, 2, 3, 4, 5]
>
> var array: [Int] {
> get { return _array }
> set { _array = newValue }
> }
> }
>
> var foo = Foo()
> foo.array.append(6) // an O(n) operation
>
> I propose a `mutate` clause which provides a `mutate` function with a
> single inout parameter (similar to how `set` provides `newValue`), which
> can be used instead of a setter:
>
> var array: [Int] {
> get { return _array }
> mutate { mutate(&_array) }
> }
>
> The compiler could then translate each mutation of `foo.array` to a
> closure with an inout parameter, which is then passed into the `mutate`
> clause (which in turn is executed with `_array` as its argument, as per the
> snippet above). For example, for `foo.array.append(6)`, the compiler would
> internally generate the closure `{ (arr: inout [Int]) in arr.append(6) }`
> and pass it into the `mutate` clause, `_array` is then passed as its
> parameter and the array is updated in constant time.
>
> I apologise if that was too hard to follow.
>
> No setter would be needed if a mutation clause is provided, but I see no
> good reason to do away with setters altogether, so this proposal would be
> purely additive.
>
>
> If this is computationally better, why is it not the default behavior
> rather than an API change?
>
> -- 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] [Proposal] Enums with stored properties

[Jay Abbott via swift-evolution]

Is this what you're trying to achieve, only using a nicer syntax to
represent it?
http://swiftlang.ng.bluemix.net/#/repl/57fb8ac27365890cc848f831


On Mon, 10 Oct 2016 at 13:04 Mateusz Malczak <mate...@malczak.info> wrote:

> I think, I have used quite unfortunate naming, which is a root of an
> misunderstanding here. By saying 'enums with stored properties' what I
> was really thinking about, was enumeration type with stored constant,
> immutable properties (constants). I don't want to duplicate 'struct'
> type here, but instead I would like to make it possible to store a
> const values in enumeration cases. So going back to my example once
> again:
>
> Lest define an enumeration type `Format` with 3 possible cases. Each
> case will be able to carry over some additional information - in this
> case a pair of numbers (but in fact Any? should be possible)
>
> enum Format {
> case SMALL(30, 30)
> case MEDIUM(60, 60)
> case LARGE(120, 120)
> var width: Double
> var height: Double
> init(width: Double, height: Double) {
> self.width = width
> self.height = height
> }
> }
>
> I'm not sure about 'var' clause in that example as it causes all the
> confusion.
>
> I can access additional info stored in enum case, but it cannot be
> modified. Format.SMALL doesn't change, as well as non of its
> properties.
>
> // allowed usage
> let format = Format.SMALL
> let width = format.width // this would be equal to 30 (const value
> assigned to 'width' property on enum case .SMALL)
>
> // not allowed usage
> let format = Format.SMALL
> format.width = 40 // error, stored values are immutable and can not be
> modified
>
> We get all advantages of enumeration type, and, assuming all cases are
> describing the same possible state, we can store some extra
> information in each case. This can be called a third enumeration type
> feature, right next to associated values and rawType.
>
> --
> | Mateusz Malczak
>
>
> 2016-10-10 13:40 GMT+02:00 Jay Abbott <j...@abbott.me.uk>:
> > Thanks for the explanation Mateusz, I think I understand. So the enum
> still
> > only has 3 cases, SMALL, MEDIUM, and LARGE, but an instance also has some
> > properties?
> >
> > So some code to use it might be:
> > var aFormat = Format.LARGE
> > aFormat.width = 150 // aFormat is still Format.LARGE - this doesn't
> change
> >
> > Is that right?
> >
> > On Mon, 10 Oct 2016 at 09:06 Mateusz Malczak via swift-evolution
> > <swift-evolution@swift.org> wrote:
> >>
> >> Hi,
> >> > Perhaps it is a bit ugly, but I don’t know if allowing stored
> properties
> >> > on
> >> > enums is the solution: that looks very ugly to me too.
> >>
> >> That may look ugly, but can be very useful, if only you think
> >> rawValue's are useful then you should also agree that stored
> >> properties would be useful :)
> >>
> >> --
> >> | Mateusz Malczak
> >>
> >>
> >> 2016-10-10 9:26 GMT+02:00 David Hart via swift-evolution
> >> <swift-evolution@swift.org>:
> >> > Perhaps it is a bit ugly, but I don’t know if allowing stored
> properties
> >> > on
> >> > enums is the solution: that looks very ugly to me too.
> >> >
> >> > On 10 Oct 2016, at 02:36, Erica Sadun via swift-evolution
> >> > <swift-evolution@swift.org> wrote:
> >> >
> >> > I would love to be able to have stored properties in addition to the
> >> > varying
> >> > elements.
> >> >
> >> > Now, I end up creating a secondary struct T and doing case a(T,
> >> > whatever),
> >> > b(T, whatever), c(T, whatever), etc. where the same associated
> structure
> >> > is
> >> > every case, *or* I end up putting the enum into a struct which means
> the
> >> > guiding semantics are the struct and not the enumeration. Both
> >> > approaches
> >> > are ugly.
> >> >
> >> > -- E
> >> >
> >> > On Oct 9, 2016, at 6:03 PM, Jay Abbott via swift-evolution
> >> > <swift-evolution@swift.org> wrote:
> >> >
> >> > Mateusz,
> >> >
> >> > To me, "Enumeration defines a type with well defined set of possible
> >> > values"
> >> > seems to contradict the idea of having properties that can have
> >> > different
> >> > values. What could you do with this special enum - what would the code
> >> >

Re: [swift-evolution] [Proposal] Enums with stored properties

[Jay Abbott via swift-evolution]

Thanks for the explanation Mateusz, I think I understand. So the enum still
only has 3 cases, SMALL, MEDIUM, and LARGE, but an instance also has some
properties?

So some code to use it might be:
var aFormat = Format.LARGE
aFormat.width = 150 // aFormat is still Format.LARGE - this doesn't change

Is that right?

On Mon, 10 Oct 2016 at 09:06 Mateusz Malczak via swift-evolution <
swift-evolution@swift.org> wrote:

> Hi,
> > Perhaps it is a bit ugly, but I don’t know if allowing stored properties
> on
> > enums is the solution: that looks very ugly to me too.
>
> That may look ugly, but can be very useful, if only you think
> rawValue's are useful then you should also agree that stored
> properties would be useful :)
>
> --
> | Mateusz Malczak
>
>
> 2016-10-10 9:26 GMT+02:00 David Hart via swift-evolution
> <swift-evolution@swift.org>:
> > Perhaps it is a bit ugly, but I don’t know if allowing stored properties
> on
> > enums is the solution: that looks very ugly to me too.
> >
> > On 10 Oct 2016, at 02:36, Erica Sadun via swift-evolution
> > <swift-evolution@swift.org> wrote:
> >
> > I would love to be able to have stored properties in addition to the
> varying
> > elements.
> >
> > Now, I end up creating a secondary struct T and doing case a(T,
> whatever),
> > b(T, whatever), c(T, whatever), etc. where the same associated structure
> is
> > every case, *or* I end up putting the enum into a struct which means the
> > guiding semantics are the struct and not the enumeration. Both approaches
> > are ugly.
> >
> > -- E
> >
> > On Oct 9, 2016, at 6:03 PM, Jay Abbott via swift-evolution
> > <swift-evolution@swift.org> wrote:
> >
> > Mateusz,
> >
> > To me, "Enumeration defines a type with well defined set of possible
> values"
> > seems to contradict the idea of having properties that can have different
> > values. What could you do with this special enum - what would the code
> that
> > uses it look like?
> >
> >
> >
> > On Sun, 9 Oct 2016 at 04:56 Robert Widmann via swift-evolution
> > <swift-evolution@swift.org> wrote:
> >>
> >> I’ve started doing this to try and mimic “Smart Constructors” in Haskell
> >> and I think it works quite well.
> >>
> >> struct Format {
> >>   enum FormatBacking {
> >> case SMALL(Int, Int)
> >> case MEDIUM(Int, Int)
> >> case LARGE(Int, Int)
> >>   }
> >
> >
> > ___
> > 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] stored properties in extensions (was: associated objects)

[Jay Abbott via swift-evolution]

I understand Charlie. A few points though:
a) I'm talking about pure Swift, this is absolutely nothing to do with
Objective-C;
b) If you read back on the AO thread you'll see that initially I was
thinking "I want AO because it will give me stored properties in
extensions" when really I should have been thinking "I want stored
properties in extensions". So this discussion is no longer about AO at all,
hence the new subject.
c) Protocol conformance in an extension cannot tell the compiler to add
members to classes defined in other precompiled modules, as it is not
compiling them. When you do have the code and you are compiling it
yourself, you actually don't *need* stored properties in extensions because
you can work around it (although it would be nice), so the case where you
actually need it is where you want to extend someone else's precompiled
class.

On Mon, 10 Oct 2016 at 06:04 Charlie Monroe <char...@charliemonroe.net>
wrote:

> No, I've also suggested how it would be implemented. It would, as I've
> described, require support from the compiler and runtime - the protocol
> conformance would tell the compiler to include an extra space in the
> instance layout for [AnyHashable : Any], which would get to be used by the
> runtime to store AO.
>
> Note that the implementation noted below does not use any locks at all -
> unlike ObjC AO, it's not thread-safe.
>
> With AO, the main bottleneck always was that everything was stored in one
> place - this way, each object would have its own AOs stored within itself.
> This way, instead of a single spin (!) lock (
> https://opensource.apple.com/source/objc4/objc4-680/runtime/objc-references.mm),
> you can use a lock pool - e.g. you have a dozen locks, depending on the
> hash of the object itself, you decide which lock to use - this lowers the
> contention a lot.
>
> Try to run a few threads, read, write AO using the ObjC runtime - you'll
> see how painfully slow it is - this is not something that should be in
> Swift.
>
>
> On Oct 9, 2016, at 10:15 PM, Jay Abbott <j...@abbott.me.uk> wrote:
>
> Charlie,
>
> What you suggest defines how you would use it from your code, not how it
> would be implemented in the language. If you look at my AO implementation
> it does what you say:
>
> https://github.com/j-h-a/AssociatedObjects/blob/develop/AssociatedObjects/AssociatedObjects.swift
> i.e. has a protocol called 'Associable' and you opt classes into it to get
> the behaviour. This works and is usable, but the implementation leaves a
> lot to be desired (it's not optimal and while the interface is clean the
> implementation is not). Anyway - I was trying to steer the conversation
> AWAY from AOs towards stored properties in extensions, since Robert Widmann
> helped me to understand that AO was just a *means*, whereas stored
> properties in extensions is the *end*.
>
> In fact we don't need a solution to the problem of "how to define/use
> stored properties in extensions" because the existing syntax for extensions
> is perfectly fine. Currently you get an error if you try to define a stored
> property in an extension, so no new syntax is needed, we just remove that
> error and make it work.
>
> Of course a runtime-check may be needed if there is doubt about whether a
> dynamically linked module supported this feature - so this might invalidate
> what I just said above, or it might still be possible if the runtime does
> the check automatically when an extension is linked and puts a different
> implementation in place for older modules.
>
> I'm just airing some thoughts at the moment to see what people think and
> try to get some technical feedback on viability. So it's not all fully
> thought through :D
>
>
> On Sun, 9 Oct 2016 at 20:54 Charlie Monroe <char...@charliemonroe.net>
> wrote:
>
> There is a 4th way.
>
> Introduce an internal protocol Associatable, which would tell the compiler
> to add an additional (hidden) field to the object which would include the
> "dictionary" of key -> value associated values. (It would be off-limits to
> extensions, of course).
>
> This way:
>
> - it won't be a single dictionary containing all the associated values
> - classes can opt-in to this
> - the dictionary will be per-instance
>
> This is a midway between the current implementation of ObjC associated
> objects and of what someone has suggested to have an extra space for each
> object for the AO...
>
>
> On Oct 9, 2016, at 9:47 PM, Jay Abbott via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> I have been thinking further on this and in addition to my previous two
> thoughts about implementation, I have had another idea...
>
> 3. If there is a bit spare i

Re: [swift-evolution] [Proposal] Enums with stored properties

[Jay Abbott via swift-evolution]

Mateusz,

To me, "Enumeration defines a type with well defined set of possible
values" seems to contradict the idea of having properties that can have
different values. What could you do with this special enum - what would the
code that uses it look like?



On Sun, 9 Oct 2016 at 04:56 Robert Widmann via swift-evolution <
swift-evolution@swift.org> wrote:

> I’ve started doing this to try and mimic “Smart Constructors” in Haskell
> and I think it works quite well.
>
> struct Format {
>   enum FormatBacking {
> case SMALL(Int, Int)
> case MEDIUM(Int, Int)
> case LARGE(Int, Int)
>   }
>   private let unFormat : FormatBacking
>
>   static var Small : Format {
> return Format(unFormat: .SMALL(30, 30))
>   }
>
>   static var Medium : Format {
> return Format(unFormat: .MEDIUM(60, 60))
>   }
>
>   static var Large : Format {
> return Format(unFormat: .LARGE(120, 120))
>   }
>
>   var width : Int {
> switch self.unFormat {
> case let .SMALL(w, _):
>   return w
> case let .MEDIUM(w, _):
>   return w
> case let .LARGE(w, _):
>   return w
> }
>   }
>
>   var height : Int {
> switch self.unFormat {
> case let .SMALL(_, h):
>   return h
> case let .MEDIUM(_, h):
>   return h
> case let .LARGE(_, h):
>   return h
> }
>   }
> }
>
> Yeah, you’re still subject the switching stuff you mentioned before, but I
> don’t think this is a whole lot of code.  Java’s constants are convenient
> but they are an oddly structural feature in a particularly nominal language
> which makes it not scale particularly cleanly.
>
> ~Robert Widmann
>
> On Oct 8, 2016, at 6:50 PM, Mateusz Malczak via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> I agree, you can achieve similar result using structs (as shown in my
> example 2). But it feels more natural to define it using an
> enumeration type. Enumeration defines a type with well defined set of
> possible values. Sometimes where are additional informations liked
> with enumeration cases (like in example). Using structs for this is
> more like a walk-around because you are using an open type to mimic a
> closed set of possible value. What do you think about that?
>
> 2016-10-09 0:29 GMT+02:00 Tim Vermeulen :
>
> This is precisely what a struct is for, why would you want to be able to
> do this with enums instead?
>
> Hi all,
> I would like to know you opinion on one feature I feel would be a real
> 'nice to have' extension to currently available enumeration type. Which is
> an enumeration type with stored properties. It is sometimes useful to store
> some extra informations along with enumeration cases. Idea here is to add
> possibility to define an enumeration type with stored, immutable,
> properties, defined at compile time for all cases. In opposition to
> currently available associated values, stored properties should be constant
> values stored as a part of enumeration case. Proposed feature would be
> treated as a new feature along the associated values and raw values.
>
> Please take a look at an example to illustrate this:
> ```swift
> enum Format {
> case SMALL(30, 30)
> case MEDIUM(60, 60)
> case LARGE(120, 120)
> var width: Double
> var height: Double
> init(width: Double, height: Double) {
> self.width = width
> self.height = height
> }
> }
> ```
>
> Similar feature is currently available for example in Java (
> http://docs.oracle.com/javase/tutorial/java/javaOO/enum.html).
>
> Currently there are at least tree ways to solve this limitation.
>
> 1. use enumeration type with custom struct as a rawValue cons:
> a lot of additional code to define structs and implement
> `ExpressibleByStringLiteral`
> not really possible for more complex types, where a complex string parser
> would be required
>
> example:
> ```swift
> struct FormatStruct: ExpressibleByStringLiteral, Equatable {
> var width: Int = 0
> var height: Int = 0
> public init(width: Int, height: Int) {
> self.width = width
> self.height = height
> }
> public init(stringLiteral value: String) {
> let set = CharacterSet(charactersIn: "x")
> let values = value.components(separatedBy: set)
> if let width = Int(values[0]), let height = Int(values[1]) {
> self.init(width: width, height: height)
> } else {
> self.init(width: 0, height: 0)
> }
> }
> init(extendedGraphemeClusterLiteral value: String){
> self.init(stringLiteral: value)
> }
> init(unicodeScalarLiteral value: String) {
> self.init(stringLiteral: value)
> }
> static func ==(lhs: FormatStruct, rhs: FormatStruct) ->Bool {
> return (lhs.width == rhs.width)&&(lhs.height == rhs.height)
> }
> static let A = FormatStruct(width: 30, height: 30)
> }
> enum Format: FormatStruct {
> case SMALL = "30x30"
> case MEDIUM = "60x60"
> case LARGE = "120x120"
> var width: Int {
> return rawValue.width
> }
> var height: Int {
> return rawValue.height
> }
> }
> ```
>
> 2. static struct values to mimic enumeration type
> cons:
> enum should be used to define a closed set of 

Re: [swift-evolution] stored properties in extensions (was: associated objects)

[Jay Abbott via swift-evolution]

Charles,

That would be good. It is a nicer way to write what is already possible to
achieve, but it's not a way to 'implement' stored properties in extensions.

On Sun, 9 Oct 2016 at 21:45 Charles Srstka  wrote:

> *Replace both instances of “class C: P” with just “class C” since the
> conformance comes in the extension. That’s what I get for writing this
> quickly.
>
> Charles
>
> On Oct 9, 2016, at 3:43 PM, Charles Srstka 
> wrote:
>
> protocol P {
> var foo: String { get }
> func bar()
> }
>
> protocol Q {
> var baz: Int { get }
> func qux()
> }
>
> class C: P {
> var foo: String // <- what is this doing here?
> var baz: Int // <- ditto
> }
>
> extension C: P {
> func bar() {}
> }
>
> extension C: Q {
> func qux() {}
> }
>
> we could simply:
>
> protocol P {
> var foo: String { get }
> func bar()
> }
>
> class C: P {}
>
> extension C: P {
> var foo: String
> func bar() {}
> }
>
> extension C: Q {
> var baz: Int
> func qux() {}
> }
>
>
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] stored properties in extensions (was: associated objects)

[Jay Abbott via swift-evolution]

Charlie,

What you suggest defines how you would use it from your code, not how it
would be implemented in the language. If you look at my AO implementation
it does what you say:
https://github.com/j-h-a/AssociatedObjects/blob/develop/AssociatedObjects/AssociatedObjects.swift
i.e. has a protocol called 'Associable' and you opt classes into it to get
the behaviour. This works and is usable, but the implementation leaves a
lot to be desired (it's not optimal and while the interface is clean the
implementation is not). Anyway - I was trying to steer the conversation
AWAY from AOs towards stored properties in extensions, since Robert Widmann
helped me to understand that AO was just a *means*, whereas stored
properties in extensions is the *end*.

In fact we don't need a solution to the problem of "how to define/use
stored properties in extensions" because the existing syntax for extensions
is perfectly fine. Currently you get an error if you try to define a stored
property in an extension, so no new syntax is needed, we just remove that
error and make it work.

Of course a runtime-check may be needed if there is doubt about whether a
dynamically linked module supported this feature - so this might invalidate
what I just said above, or it might still be possible if the runtime does
the check automatically when an extension is linked and puts a different
implementation in place for older modules.

I'm just airing some thoughts at the moment to see what people think and
try to get some technical feedback on viability. So it's not all fully
thought through :D


On Sun, 9 Oct 2016 at 20:54 Charlie Monroe <char...@charliemonroe.net>
wrote:

There is a 4th way.

Introduce an internal protocol Associatable, which would tell the compiler
to add an additional (hidden) field to the object which would include the
"dictionary" of key -> value associated values. (It would be off-limits to
extensions, of course).

This way:

- it won't be a single dictionary containing all the associated values
- classes can opt-in to this
- the dictionary will be per-instance

This is a midway between the current implementation of ObjC associated
objects and of what someone has suggested to have an extra space for each
object for the AO...


On Oct 9, 2016, at 9:47 PM, Jay Abbott via swift-evolution <
swift-evolution@swift.org> wrote:

I have been thinking further on this and in addition to my previous two
thoughts about implementation, I have had another idea...

3. If there is a bit spare in the object header somewhere (that is
currently always zero), this could be used to signify the presence of an
additional struct that immediately follows after the existing object data.
I *think* that this method would allow binary compatibility with older
modules. Instances that have this bit set would allow stored properties in
extensions. The struct at the end would have one member, a pointer to a
table of additional objects/values, stored properties defined in extensions
could be stored in here, using a hash derived from the
module/protocol/extension/property name (or something better if it exists).

The struct could be very simple as described above or more complex, with
additional features, for example a list of deinit hooks, dynamically added
methods, etc. The struct itself may also be dynamic in size/layout if such
complexity is warranted by size or extensibility concerns. Perhaps it
should start with some flags and its size (size would be fixed and only
increase with revisions so this would double as a 'version' number).

If viable - this would be a much better way to implement this feature than
my previous two ideas. It doesn't require global lookups or additional
levels of indirection beyond accessing the dynamic data/feature itself.


On Mon, 3 Oct 2016 at 04:13 Jay Abbott <j...@abbott.me.uk> wrote:

Are stored properties in extensions already being discussed elsewhere? Is
this one of those deferred-but-not-indexed-anywhere subjects?

I wonder how stored properties could potentially be implemented, I can only
think of two ways:

1. An extra pointer per instance (with resulting ABI compatability
implications) to hold a collection of the stored items.

2. A global lookup for any instance where stored properties have been set.

I'm not a language implementation expert, or familiar with the swift
implementation, so there may be other/better ways - I'd like to know if
there are?

If not, and option 2 was employed, a little foresight might enable the
mechanism to be overloaded in the future for other dynamic features too. A
bit flag (I'm hoping there's a spare bit in an existing flags field
somewhere?) could indicate whether any feature had caused the object to be
added to this lookup and deinit could check this bit and make sure the
object is removed, thus any stored properties are nilled. The lookup value
could be a struct with one member (extensionStoredProperties), and
additional members can be

Re: [swift-evolution] stored properties in extensions (was: associated objects)

[Jay Abbott via swift-evolution]

I have been thinking further on this and in addition to my previous two
thoughts about implementation, I have had another idea...

3. If there is a bit spare in the object header somewhere (that is
currently always zero), this could be used to signify the presence of an
additional struct that immediately follows after the existing object data.
I *think* that this method would allow binary compatibility with older
modules. Instances that have this bit set would allow stored properties in
extensions. The struct at the end would have one member, a pointer to a
table of additional objects/values, stored properties defined in extensions
could be stored in here, using a hash derived from the
module/protocol/extension/property name (or something better if it exists).

The struct could be very simple as described above or more complex, with
additional features, for example a list of deinit hooks, dynamically added
methods, etc. The struct itself may also be dynamic in size/layout if such
complexity is warranted by size or extensibility concerns. Perhaps it
should start with some flags and its size (size would be fixed and only
increase with revisions so this would double as a 'version' number).

If viable - this would be a much better way to implement this feature than
my previous two ideas. It doesn't require global lookups or additional
levels of indirection beyond accessing the dynamic data/feature itself.


On Mon, 3 Oct 2016 at 04:13 Jay Abbott  wrote:

> Are stored properties in extensions already being discussed elsewhere? Is
> this one of those deferred-but-not-indexed-anywhere subjects?
>
> I wonder how stored properties could potentially be implemented, I can
> only think of two ways:
>
> 1. An extra pointer per instance (with resulting ABI compatability
> implications) to hold a collection of the stored items.
>
> 2. A global lookup for any instance where stored properties have been set.
>
> I'm not a language implementation expert, or familiar with the swift
> implementation, so there may be other/better ways - I'd like to know if
> there are?
>
> If not, and option 2 was employed, a little foresight might enable the
> mechanism to be overloaded in the future for other dynamic features too. A
> bit flag (I'm hoping there's a spare bit in an existing flags field
> somewhere?) could indicate whether any feature had caused the object to be
> added to this lookup and deinit could check this bit and make sure the
> object is removed, thus any stored properties are nilled. The lookup value
> could be a struct with one member (extensionStoredProperties), and
> additional members can be added in future for new features.
>
> I get the impression from the associated objects discussion that perhaps
> there are much better, more optimal, more ingenious, more unknown-by-me
> ways of doing such things, so apologies if this whole idea is way-off the
> mark :D
>
> Jay
>
> P.S. Note that stored properties in extensions could enable developers to
> implement their own dynamic features in Swift.. so such desires could be
> satisfied in the short term until they could be done properly in the
> language.
>
> On Sat, 1 Oct 2016 at 00:49 Chris Lattner via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> On Sep 30, 2016, at 2:51 PM, Ted F.A. van Gaalen via swift-evolution <
> swift-evolution@swift.org> wrote:
> > Is it possible to have best of (these completely different) both worlds?
>
> Yes, of course it is.  Your email spends a lot of words trying to form a
> false dichotomy.  Swift can definitely have both awesome dynamic features
> while still having performance, predictability and safety.
>
> > Would it be possible in Swift to have facilities to generate objects
> > dynamically at runtime? and, if desirable, how can such be implemented?
>
> Here’s an extant implementation that you can use today:
> https://github.com/Zewo/Reflection
>
> I’m sure it isn’t ideal, but it proves that it can be done.  When we have
> bandwidth to reevaluate this area from first principles, I’m sure we can
> make improvements on it.
>
> I will grant you that Smalltalk is a beautiful language in its simplicity,
> but for that simplicity it makes many tradeoffs that we’re not willing to
> make.  We are willing to make the internal implementation of Swift complex
> if that means that we get a beautiful model for programmers - one that
> preserves the virtues of safety-by-default, predictability, performance,
> and joy-to-develop-in.
>
> The meme of “Swift can never (or will never) support dynamic features” is
> tired, and also wildly inaccurate.
>
> -Chris
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] private & fileprivate

[Jay Abbott via swift-evolution]

I agree that the keywords could be improved, but private(file) access
should not be what 'private' means by itself. If I put just 'private' in
front of something I really mean it should be private to this scope, the
most private. I also think the more common use-case would be private(scope)
over private(file), you might find if you refactor a bit that a lot of your
fileprivate can become private or instead - it's possible that fileprivate
is encouraging you to put things into one file when they should be in
multiple files with a better defined 'internal' API.

I like the *concept* that 'private' is the most private and then it can be
relaxed by modifiers (file) (module) (perhaps-other-stuff), but I'm not
convinced that 'private' is really an appropriate word for something that
is accessible anywhere within a module. Though I agree that 'internal'
doesn't really mean much to someone learning the language, and suffers the
exact same problem (internal to what?) whereas private(module) does express
that a bit better.

On Fri, 7 Oct 2016 at 09:26 Haravikk via swift-evolution <
swift-evolution@swift.org> wrote:

>
> On 7 Oct 2016, at 07:39, David Hart via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> Hello community,
>
> From all the proposals which has gone into Swift 3, *[SE-0025] Scoped
> Access Level* is the only one I’m having second thoughts about. Before
> launching a discussion around it, I’m curious to know if it's worth
> discussing it or if the “ship has sailed”. As the plan is to allow future
> versions of Swift to break source-compatibility in certain rare scenarios,
> perhaps we have a chance to reconsider certain proposals?
>
> Regards,
> David.
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
> What in particular don't you like about it?
>
> Personally I still don't like the use of fileprivate as the keyword, I was
> very much in favour of a bracketed system like:
>
> private(scope) Current private (I think, it doesn't appear to be
> equivalent to protected in other languages anyway so I wouldn't call it
> type).
> private(file) Current fileprivate
> private(module) Current internal/default when omitted
> public Current public
>
> I favour this because it groups all restrictive access levels under
> private (since they're all some form of private) with an optional modifier
> that's explicit about what it's for. Also, it would have scope to move
> things like final into a modifier too, so you might declare a method as
> public(final), or public(open) if that's implemented later and so-on. Just
> seems like a generally more flexible setup that also reduces the number of
> keywords required.
>
> Some may feel it's noisy, but personally I don't see it as a problem as it
> always comes before the func/var/let keyword, generics and function name,
> so it's not like it's near anything where the (minor) noise reduces
> readability.
>
> But yeah, having used the new fileprivate for a little while I just don't
> like it; it may partly come down to the fact that I use fileprivate a lot
> more than I use regular private. If we were to adopt the above scheme I
> would recommend that private(file) be the default for use of the plain
> private keyword, unless we gain the ability to specify private(type) (i.e-
> protected in most other languages), as private(scope) seems like it's the
> less common, at least in my experience.
> ___
> 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] stored properties in extensions (was: associated objects)

[Jay Abbott via swift-evolution]

Are stored properties in extensions already being discussed elsewhere? Is
this one of those deferred-but-not-indexed-anywhere subjects?

I wonder how stored properties could potentially be implemented, I can only
think of two ways:

1. An extra pointer per instance (with resulting ABI compatability
implications) to hold a collection of the stored items.

2. A global lookup for any instance where stored properties have been set.

I'm not a language implementation expert, or familiar with the swift
implementation, so there may be other/better ways - I'd like to know if
there are?

If not, and option 2 was employed, a little foresight might enable the
mechanism to be overloaded in the future for other dynamic features too. A
bit flag (I'm hoping there's a spare bit in an existing flags field
somewhere?) could indicate whether any feature had caused the object to be
added to this lookup and deinit could check this bit and make sure the
object is removed, thus any stored properties are nilled. The lookup value
could be a struct with one member (extensionStoredProperties), and
additional members can be added in future for new features.

I get the impression from the associated objects discussion that perhaps
there are much better, more optimal, more ingenious, more unknown-by-me
ways of doing such things, so apologies if this whole idea is way-off the
mark :D

Jay

P.S. Note that stored properties in extensions could enable developers to
implement their own dynamic features in Swift.. so such desires could be
satisfied in the short term until they could be done properly in the
language.

On Sat, 1 Oct 2016 at 00:49 Chris Lattner via swift-evolution <
swift-evolution@swift.org> wrote:

> On Sep 30, 2016, at 2:51 PM, Ted F.A. van Gaalen via swift-evolution <
> swift-evolution@swift.org> wrote:
> > Is it possible to have best of (these completely different) both worlds?
>
> Yes, of course it is.  Your email spends a lot of words trying to form a
> false dichotomy.  Swift can definitely have both awesome dynamic features
> while still having performance, predictability and safety.
>
> > Would it be possible in Swift to have facilities to generate objects
> > dynamically at runtime? and, if desirable, how can such be implemented?
>
> Here’s an extant implementation that you can use today:
> https://github.com/Zewo/Reflection
>
> I’m sure it isn’t ideal, but it proves that it can be done.  When we have
> bandwidth to reevaluate this area from first principles, I’m sure we can
> make improvements on it.
>
> I will grant you that Smalltalk is a beautiful language in its simplicity,
> but for that simplicity it makes many tradeoffs that we’re not willing to
> make.  We are willing to make the internal implementation of Swift complex
> if that means that we get a beautiful model for programmers - one that
> preserves the virtues of safety-by-default, predictability, performance,
> and joy-to-develop-in.
>
> The meme of “Swift can never (or will never) support dynamic features” is
> tired, and also wildly inaccurate.
>
> -Chris
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] associated objects

[Jay Abbott via swift-evolution]

On Fri, 30 Sep 2016 at 15:41 Robert Widmann 
wrote:

> "I want to do  but the language doesn't support it” is the whole reason
> for this list!  I want to know what “” is in order to wrap my head
> around your proposal better.  I’m not here to invalidate your work with a
> slew of criticisms, I’m just trying to understand your proposal by probing
> you about it.
>

I know, and appreciate this, thanks :) I'm not easily offended and I prefer
to be wrong in a room full of smarter people than right (or think that I'm
right when maybe not) in a room full of not smarter people. But I do
struggle to articulate this without patronising everyone by explaining how
I think it is (in order to be corrected) all the time. Hope that even makes
sense!


> Again, these are features and I want motivations behind them.  *Why*
> should you be able to dynamically add stored properties and methods to
> *any* Swift class?
>

If I'm using an existing framework such as UIKit, and I want to add
something it doesn't support, like drag+drop to all UIViews for example,
then my implementation might want to use stored properties to help keep
track of drag+drop-related config and state (isDraggable, isDropTarget,
sourceView, etc.). This way I can extend UIView and use the stored
properties from my extension methods, while keeping all the functionality
of all its subclasses.

There's probably a much better way to express the above in the abstract -
sorry I suck at that :)

*Why* should you be able to observe deallocation if deallocation calls are
> not guaranteed (remember, Objective-C and Swift do not guarantee
> -dealloc/deinit calls in any order at any time - please don’t assume an
> RAII-like model because it will lead to memory leaks and malformed code).
>

It's not deallocation, but deinit that would be useful. My motivation in
Swift for wanting this was to get around lazy weak reference zeroing in my
associated objects implementation. If the object is deinited, you can't ask
it for an associated object, therefore its weak reference in my
implementation would never be accessed so it would hang around forever. I
got around that with a horrible clean-up hack that accesses the weak
references just to ensure they get zeroed, so I wanted non-lazy zeroing (or
a deinit hook).

I will say: Perhaps if you’re having trouble motivating the inclusion of
> this feature, you may want to step back and reevaluate its place in the
> language and why you wanted to write this library in the first place.
> Often times, I find that really helps get the creative juices flowing.  Or,
> if I can’t come up with anything, it means I go back to step 1 and start
> over.  Proposals can be as much a learning process for us as it is for you.
>

I know exactly why I wanted associated objects - to implement a) stored
properties in extensions; and b) per-instance actions. If stored properties
were available in extensions then I would not need it at all: a) I would
already have it; b) I'd implement it using stored properties.

So from what I’ve gathered you’ve written a library to do this yourself.
> You have a vision for how you want to use this library.  You think that
> vision is compatible with a language-level change.  From my perspective,
> your job now is to articulate that vision and motivate it to this list.  I
> don’t think associated objects and the other dynamic features you mention
> are fundamentally incompatible with Swift, I just think the design that
> I’ve seen so far may not be the best way of going about it and I’m voicing
> my concerns as much.
>

I guess you're right - it's really stored properties in extensions that I
want...  but actually - what's the difference? Aren't they basically the
same thing? :)

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

Re: [swift-evolution] Pitch: Renaming CharacterSet to UnicodeScalarSet

[Jay Abbott via swift-evolution]

Yes - this is totally confusing. CharacterSet and Set are
completely different things with different semantics.

I don't know the history, but is CharacterSet simply to have a Swift
equivalent of NSCharacterSet? That seems to be what it is, but since Swift
redefined characters in a better way, this should be removed or called
something else to avoid confusion. You shouldn't have to qualify what you
mean by 'character' in a type name because it diverges from the definition
in the rest of the language.

On Thu, 29 Sep 2016 at 04:48 Xiaodi Wu via swift-evolution <
swift-evolution@swift.org> wrote:

> On Wed, Sep 28, 2016 at 10:34 PM, Xiaodi Wu  wrote:
>
>> On Wed, Sep 28, 2016 at 10:23 PM, Charles Srstka via swift-evolution <
>> swift-evolution@swift.org> wrote:
>>
>>> On Sep 28, 2016, at 9:57 PM, Erica Sadun via swift-evolution <
>>> swift-evolution@swift.org> wrote:
>>>
>>>
>>> D'erp. I missed that. And that's an unambiguous answer.
>>>
>>> So let me move on to part B of the pitch: I think CharacterSets are
>>> broken.
>>>
>>> Xiaodi Wu: "isn't the problem you're presenting really an argument that
>>> the type should be fleshed out to handle characters (grapheme clusters)
>>> containing more than one Unicode scalar?"
>>>
>>>
>>> It seems that it already does handle such characters:
>>>
>>> (done in Objective-C so we can log the length of the range as a count of
>>> UTF-16 code units)
>>>
>>> #import 
>>>
>>> int main(int argc, char *argv[]) {
>>> @autoreleasepool {
>>> NSCharacterSet *bikeSet = [NSCharacterSet
>>> characterSetWithCharactersInString:@""];
>>> NSString *str = @"foobar";
>>>
>>>
>>> NSRange range = [str rangeOfCharacterFromSet:bikeSet];
>>>
>>>
>>> NSLog(@"location: %lu length: %lu", range.location, range.length
>>> );
>>> }
>>> }
>>>
>>> - - - - - - -
>>>
>>> *2016-09-28 22:20:00.622471 test[15577:2433912] location: 3 length: 2*
>>> *Program ended with exit code: 0*
>>>
>>> - - - - - - -
>>>
>>> As we can see, the character from the set is recognized as consisting of
>>> two code units. There are a few bugs in the system, though. See the
>>> cocoa-dev thread “Where is my bicycle?” from about a year ago:
>>> http://prod.lists.apple.com/archives/cocoa-dev/2015/Apr/msg00074.html
>>>
>>
>> The bike emoji might be two code units, but it is one Unicode scalar
>> (U+1F6B2). However, the Canadian flag emoji, for instance, is two Unicode
>> scalars (U+1F1E8 U+1F1E6) but nonetheless one character.
>>
>
> To illustrate in code how CharacterSet doesn't actually handle characters
> made up of multiple Unicode scalars:
>
> ```
> import Foundation
>
> let str1 = ""
> let first = CharacterSet(charactersIn: str1) // this actually crashes
> corelibs-foundation
> let str2 = ""
> let second = CharacterSet(charactersIn: str2)
> let intersection = first.intersection(second)
> print(intersection.isEmpty)
> // actual output: false
> // obviously, if we were really dealing with characters, the intersection
> should be empty
> ```
>
>
>> 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
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] $self

[Jay Abbott via swift-evolution]

Sean, yeah that's kind of what I was suggesting for @escaping closures - it
should be the default... but it is a breaking change and as Chris pointed
out that would need extreme justification... plus it would be a behaviour
change with no syntax change, so code that was never "upgraded" would be
very difficult to tell the original intention. I like the idea but I don't
know if I can come up with "extreme justification" for it.

On Thu, 29 Sep 2016 at 01:46 Sean Heber <s...@fifthace.com> wrote:

> Now that I think about this, wouldn't that be a better default behavior?
> All captures are this "required" type which means all closures are typed as
> optional. To override that behavior, you'd have to explicitly declare a
> weak or unowned capture instead and if you did that for all reference
> captures, the closure's type would be non-optional as they are now. Seems
> like that'd be safer. I'll shut up now.
>
> l8r
> Sean
>
> Sent from my iPad
>
> On Sep 28, 2016, at 7:25 PM, Sean Heber <s...@fifthace.com> wrote:
>
> Pretty sure this is all way out of scope, but something about this made me
> think about this idea (which maybe isn't unique or is maybe even
> unworkable), but imagine something like where a new capture type is added
> such as "required" (for lack of another name right now). And the way this
> works is similar to unowned, but it makes the entire closure "weak" in such
> a way that the moment any of the required captures go nil, any references
> to that closure instance also effectively become nil.
>
> So modifying the example:
>
> func viewDidLoad() {
> self.loginForm.onSubmit = {[required self]
>  let f = self.loginForm
>  self.startLoginRequest(email:f.email.text, pwd:f.pwd.text)
> }
> }
>
> So in this case, "required self" means self is effectively "unowned" but
> any references to this closure would have to be weak optional like: weak
> var onSubmit: (()->Void)? So that when the view controller gets
> deallocated, the closure goes with it and references become nil.
>
> l8r
> Sean
>
> Sent from my iPad
>
> On Sep 28, 2016, at 6:42 PM, Jay Abbott via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> It could potentially be a breaking change if the default for @escaping
> closures were made to be weak-capturing.
>
> Since the weak-capturing pattern is only really desirable for @escaping
> closures, and (I think) it would be the usual preference, could @escaping
> also imply weak-capturing for all references (not just self)? Then there
> would be another syntax for strong-capturing-escaping closures.
> Non-escaping closures could a) strongly capture references; or b) existing
> strong references stay strong and weak ones stay weak, meaning no
> ref-counts need to change at all when passing them.
>
>
> On Thu, 29 Sep 2016 at 00:06 Paul Jack via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>> So previously there were a few threads on the "strong self/weak self
>> dance" but they didn't seem to get anywhere. For instance:
>>
>>
>> https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160201/008713.html
>>
>> https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160215/010759.html
>>
>> https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160208/009972.html
>>
>> ...and possibly others.
>>
>> I'd like to propose something even easier (and more specific) than all
>> of the above discussions. Specifically, I'd like to introduce a new
>> automagic closure variable, $self, whose presence in a closure would
>> cause that closure to weakly capture self in a safe manner.
>>
>> As a concrete example, let's imagine a UIViewController for a login
>> form. Under this proposal, the following code:
>>
>> func viewDidLoad() {
>> self.loginForm.onSubmit = {
>>  let f = $self.loginForm
>>  $self.startLoginRequest(email:f.email.text, pwd:f.pwd.text)
>> }
>> }
>>
>> ...would be treated by the compiler as equivalent to:
>>
>> func viewDidLoad() {
>> self.loginForm.onSubmit = {
>>  [weak self] in
>>  if let selfie = self {
>>  let f = selfie.loginForm
>>  selfie.startLoginRequest(email:f.email.text,
>>  pwd:f.pwd.text)
>>  }
>> }
>> }
>>
>> Note the "if let" there: If self no longer exists, the closure does not
>> execute at all, but if self does exist, then it exists for the entirety
>> of the execution of the clo

Re: [swift-evolution] $self

[Jay Abbott via swift-evolution]

I think Sean's idea for [required refName] on this is the better one in
terms of syntax and clarity of what's going on. It's fairly clear that the
required refs are weak but become strong during the closure execution, and
that since they're 'required' the closure goes away if they do.

In practice, with lazy zeroing I think it would not be viable to zero the
closure ref until calling it was attempted and the strong ref on its
required captures failed.
One for the 'deferred' pile I guess :P

On Thu, 29 Sep 2016 at 01:27 Chris Lattner <clatt...@apple.com> wrote:

> On Sep 28, 2016, at 4:42 PM, Jay Abbott via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> It could potentially be a breaking change if the default for @escaping
> closures were made to be weak-capturing.
>
>
> Ok, but source breaking changes need extreme justification.  A primary
> goal of Swift 3 was to provide source compatibility going forward.
>
> -Chris
>
>
>
> Since the weak-capturing pattern is only really desirable for @escaping
> closures, and (I think) it would be the usual preference, could @escaping
> also imply weak-capturing for all references (not just self)? Then there
> would be another syntax for strong-capturing-escaping closures.
> Non-escaping closures could a) strongly capture references; or b) existing
> strong references stay strong and weak ones stay weak, meaning no
> ref-counts need to change at all when passing them.
>
>
> On Thu, 29 Sep 2016 at 00:06 Paul Jack via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>> So previously there were a few threads on the "strong self/weak self
>> dance" but they didn't seem to get anywhere. For instance:
>>
>>
>> https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160201/008713.html
>>
>> https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160215/010759.html
>>
>> https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160208/009972.html
>>
>> ...and possibly others.
>>
>> I'd like to propose something even easier (and more specific) than all
>> of the above discussions. Specifically, I'd like to introduce a new
>> automagic closure variable, $self, whose presence in a closure would
>> cause that closure to weakly capture self in a safe manner.
>>
>> As a concrete example, let's imagine a UIViewController for a login
>> form. Under this proposal, the following code:
>>
>> func viewDidLoad() {
>> self.loginForm.onSubmit = {
>>  let f = $self.loginForm
>>  $self.startLoginRequest(email:f.email.text, pwd:f.pwd.text)
>> }
>> }
>>
>> ...would be treated by the compiler as equivalent to:
>>
>> func viewDidLoad() {
>> self.loginForm.onSubmit = {
>>  [weak self] in
>>  if let selfie = self {
>>  let f = selfie.loginForm
>>  selfie.startLoginRequest(email:f.email.text,
>>  pwd:f.pwd.text)
>>  }
>> }
>> }
>>
>> Note the "if let" there: If self no longer exists, the closure does not
>> execute at all, but if self does exist, then it exists for the entirety
>> of the execution of the closure (ie, self won't vanish as a side-effect
>> of some statement in the closure.) I think these semantics obey the
>> principle of least surprise; $self can be treated by the developer as a
>> strong reference.
>>
>> However, that does mean that $self can only be used in a closure that's
>> (a) Void or (b) Optional. In the latter case, returning nil when self
>> doesn't exist seems like reasonable/expected behavior.
>>
>> It would be a compile-time error to use both $self and normal self in
>> the same closure.
>>
>> I'd like to keep this simple, meaning $self always does the above and
>> nothing else. So, if you need an unowned self, you still need the
>> original syntax; if your closure needs a non-Optional return type, you
>> still need the original syntax; etc.
>>
>> Thoughts?
>>
>> -Paul
>> ___
>> 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] $self

[Jay Abbott via swift-evolution]

It could potentially be a breaking change if the default for @escaping
closures were made to be weak-capturing.

Since the weak-capturing pattern is only really desirable for @escaping
closures, and (I think) it would be the usual preference, could @escaping
also imply weak-capturing for all references (not just self)? Then there
would be another syntax for strong-capturing-escaping closures.
Non-escaping closures could a) strongly capture references; or b) existing
strong references stay strong and weak ones stay weak, meaning no
ref-counts need to change at all when passing them.


On Thu, 29 Sep 2016 at 00:06 Paul Jack via swift-evolution <
swift-evolution@swift.org> wrote:

> So previously there were a few threads on the "strong self/weak self
> dance" but they didn't seem to get anywhere. For instance:
>
>
> https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160201/008713.html
>
> https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160215/010759.html
>
> https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160208/009972.html
>
> ...and possibly others.
>
> I'd like to propose something even easier (and more specific) than all
> of the above discussions. Specifically, I'd like to introduce a new
> automagic closure variable, $self, whose presence in a closure would
> cause that closure to weakly capture self in a safe manner.
>
> As a concrete example, let's imagine a UIViewController for a login
> form. Under this proposal, the following code:
>
> func viewDidLoad() {
> self.loginForm.onSubmit = {
>  let f = $self.loginForm
>  $self.startLoginRequest(email:f.email.text, pwd:f.pwd.text)
> }
> }
>
> ...would be treated by the compiler as equivalent to:
>
> func viewDidLoad() {
> self.loginForm.onSubmit = {
>  [weak self] in
>  if let selfie = self {
>  let f = selfie.loginForm
>  selfie.startLoginRequest(email:f.email.text,
>  pwd:f.pwd.text)
>  }
> }
> }
>
> Note the "if let" there: If self no longer exists, the closure does not
> execute at all, but if self does exist, then it exists for the entirety
> of the execution of the closure (ie, self won't vanish as a side-effect
> of some statement in the closure.) I think these semantics obey the
> principle of least surprise; $self can be treated by the developer as a
> strong reference.
>
> However, that does mean that $self can only be used in a closure that's
> (a) Void or (b) Optional. In the latter case, returning nil when self
> doesn't exist seems like reasonable/expected behavior.
>
> It would be a compile-time error to use both $self and normal self in
> the same closure.
>
> I'd like to keep this simple, meaning $self always does the above and
> nothing else. So, if you need an unowned self, you still need the
> original syntax; if your closure needs a non-Optional return type, you
> still need the original syntax; etc.
>
> Thoughts?
>
> -Paul
> ___
> 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] associated objects

[Jay Abbott via swift-evolution]

Hey Robert,

Well the example I gave was stored properties in extensions - that is they
can be easily implemented as calculated properties that actually use
associated objects/values to store their value. The other one is
per-instance actions, programmers can dynamically add an action (closure)
to any instance (for example decide where it needs to be sent and add a
closure with the key "send"), then that action can be performed later by
retrieving whatever is in "send" and calling it - basically whenever
functionality rather than data needs to be moved around.

I agree it's not an efficient or type-safe system, but of course any
developer using it is doing so at run-time so they know there's no
type-checking going on and should take measures to ensure only the correct
types are put into any situation (or check it themselves). It *can* be
implemented without affecting the ABI - as my example code shows, I'm just
not sure if this is a good way to do it.

I'm not sure what you mean about obj-c associated objects having a slow
deallocation path, is there a learning-point from the obj-c implementation
that helps here? If so I don't know it :) I don't think you would try to
make it type-safe as it's a dynamic feature and you'd expect the users to
do that themselves - sure there could be ways to use reflection to help
out, but is this necessary?

As noted in the README - deinit hooks would enable an implementation that
doesn't need to do the internal clean-up. So it works as-is, but could be
improved with some language features.


On Wed, 28 Sep 2016 at 19:46 Goffredo Marocchi <pana...@gmail.com> wrote:

>
>
> Sent from my iPhone
>
> On 28 Sep 2016, at 17:27, Robert Widmann via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> Have you got a significant use-case for this that absolutely can't be
> solved by extensions or subclassing?
>
> This does have ABI impact but more concerning for me is the performance
> impact and that the existing API is not type safe.
>
> Using associated objects in ObjC gets you read through the slowest
> possible deallocation paths and means the runtime is effectively tracking
> an extra table of pointer tables per object-with-associations.  To make
> this kind of pattern type safe you would, for example, need to keep track
> metatype pointers too and use the dynamic cast machinery to check the type
> on retrieval.
>
>
> If observers, whose lifetime is longer than the the observed objects' one,
> were notified when the observed object is deallocated then I would agree
> with you about safety concerns trumping usability... but as it is right now
> a nice mechanism like KVO is made trickier to use than it should be without
> associated objects (KVO leakage is quite a scary concept :)).
>
>
> ~Robert Widmann
>
> 2016/09/28 11:26、Jay Abbott via swift-evolution <swift-evolution@swift.org>
> のメッセージ:
>
> I have implemented Associated Objects (and values) in pure swift here:
> https://github.com/j-h-a/AssociatedObjects
>
> The README is very short and straight-forward so I won't re-describe it
> here.
>
> The implementation isn't great, but it's a small and simple proof of
> concept. I have further extended this (not in GH, but very simple and happy
> to share if anyone cares) to add dynamic methods using closures onto
> individual object instances. Useful for user interactions, or adding
> 'actions' to objects.
>
> I'd like to propose that this or something similar be added to the
> standard library. It could potentially even be added to AnyObject so that
> developers can use it without having to declare an extension for whichever
> classes they want to use it on.
>
> As mentioned, this can easily be extended (either in the standard library
> or by developers) to add closures dynamically to any object, or to any
> class, which could serve as a useful way for those not concerned with type
> safety and the like to get some dynamic behaviour in there in the shorter
> term. With a little language support it could even be used to implement
> stored properties in extensions very easily.
>
> A better implementation would need some language changes - specifically
> deinit hooks (has that ever been discussed?) because of the way weak
> references are lazily zeroed. Another implementation improvement might
> lazily add the dictionary to each object instead of storing it globally -
> not sure if this would have ABI implications.
>
> Interested in feedback and thoughts :)
>
> ___
> 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 draft] Introducing `indexed()` collections

[Jay Abbott via swift-evolution]

One (potentially dumb) question...

If the actual indices are needed inside the loop, presumably this means
they will be used in the loop, perhaps to mutate it, and if the collection
is mutated won't that either invalidate (or change the relative
correspondence of) the others indices, because the collection accessed in
the loop will be the mutated one whereas the indices refer to the copy that
was taken at the start when the 'for' statement was evaluated?



On Wed, 28 Sep 2016 at 19:34 Sean Heber via swift-evolution <
swift-evolution@swift.org> wrote:

> This might just be me being silly, but is there any way to be able to do
> something like this instead:
>
> for (index, value) in sequence {
> }
>
> Maybe by adding another variant of makeIterator() that only differs by the
> return type or something like that?
>
> I sort of dislike that enumerated() and indexed() would co-exist and
> potentially lead to really subtle bugs when getting them confused.
> Obviously removing enumerated() would be a breaking change, though, and
> maybe it has valuable uses that I’m not really thinking about (although it
> seems to me that the index/value pair is what you want like, 99% of the
> time and plenty of people - myself included - have been using the index of
> enumerated() as an array index even though that’s technically maybe not
> quite ‘correct').
>
> l8r
> Sean
>
>
> > On Sep 28, 2016, at 12:55 PM, Erica Sadun via swift-evolution <
> swift-evolution@swift.org> wrote:
> >
> > Gist here:
> https://gist.github.com/erica/2b2d92e6db787d001c689d3e37a7c3f2
> >
> > Introducing indexed() collections
> >
> >   • Proposal: TBD
> >   • Author: Erica Sadun, Nate Cook, Jacob Bandes-Storch, Kevin
> Ballard
> >   • Status: TBD
> >   • Review manager: TBD
> > Introduction
> >
> > This proposal introduces indexed() to the standard library, a method on
> collections that returns an (index, element) tuple sequence.
> >
> > Swift-evolution thread: TBD
> >
> > Motivation
> >
> > The standard library's enumerated() method returns a sequence of pairs
> enumerating a sequence. The pair's first member is a monotonically
> incrementing integer starting at zero, and the second member is the
> corresponding element of the sequence. When working with arrays, the
> integer is coincidentally the same type and value as an Array index but the
> enumerated value is not generated with index-specific semantics. This may
> lead to confusion when developers attempt to subscript a non-array
> collection with enumerated integers. It can introduce serious bugs when
> developers use enumerated()-based integer subscripting with non-zero-based
> array slices.
> >
> > Indices have a specific, fixed meaning in Swift, which are used to
> create valid collection subscripts. This proposal introduces indexed() to
> produce a more semantically relevant sequence by pairing a collection's
> indices with its members. While it is trivial to create a solution in
> Swift, the most common developer approach shown here calculates indexes
> twice:
> >
> > extension Collection {
> > /// Returns a sequence of pairs (*idx*, *x*), where *idx* represents
> a
> > /// consecutive collection index, and *x* represents an element of
> > /// the sequence.
> > func indexed() -> Zip2Sequence {
> > return zip(indices, self)
> > }
> > }
> >
> > Incrementing an index in some collections can be unnecessarily costly.
> In a lazy filtered collection, an index increment is potentially O(N). We
> feel this is better addressed introducing a new function into the Standard
> Library to provide a more efficient design that avoids the attractive
> nuisance of the "obvious" solution.
> >
> > Detailed Design
> >
> > Our vision of indexed() bypasses duplicated index generation with their
> potentially high computation costs. We'd create an iterator that calculates
> each index once and then applies that index to subscript the collection.
> Implementation would take place through IndexedSequence, similar to
> EnumeratedSequence.
> >
> > Impact on Existing Code
> >
> > This proposal is purely additive and has no impact on existing code.
> >
> > Alternatives Considered
> >
> > Not yet
> > ___
> > 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 proposals should be easier to find

[Jay Abbott via swift-evolution]

Maybe my wording and use of the word 'proposal' is all wrong. I still think
there's an issue that could be addressed though. Don't get me wrong - I
think the level of documentation available on swift.org about the community
process, different streams (evolution/dev/etc.) is all fantastic, still it
can be improved. This is one of those issues that it's very difficult to
see as an issue at all from the inside. I think just knowing that a
particular subject is being discussed - even if it's not a concrete or even
a draft proposal - would help people, a) to not waste their own time and
that of the list with duplicate ideas; and b) to feel more comfortable
about getting involved. Maybe an ideas board that people can +1 or -1 would
help instead - or at least keep poorly researched discussion at bay?

On Wed, 28 Sep 2016 at 16:54 Xiaodi Wu <xiaodi...@gmail.com> wrote:

> I think the idea is that proposals submitted to GitHub are supposed to
> have already gone through a robust round of discussion, but the community
> can't be adequately engaged in that discussion if the topic is out of
> scope. In that case, there shouldn't be anything to capture as a proposal;
> anything written down won't have gone through the right process to bring it
> up to that point.
>
> On Wed, Sep 28, 2016 at 10:34 Jay Abbott via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>> I don't really understand this concept of only accepting proposals for a
>> specific round. I saw some ideas that were suitable for future rounds of
>> proposals but not right now... Why aren't they captured in a better format
>> than the mailing list archive? If you don't want to be distracted by future
>> things then capture them as proposals but file them out of the way a bit so
>> that people can see they exist - I would have thought this would decrease
>> distractions from people bringing them up again.
>>
>> On Wed, 28 Sep 2016 at 16:14 Robert Widmann <devteam.cod...@gmail.com>
>> wrote:
>>
>>> There's a difference between "was once discussed here" and "had a
>>> proposal submitted to Github for consideration".  If many people are
>>> producing the same ideas for proposals that exist on GitHub that poses a
>>> more pressing risk.  But it is easier to search GitHub for such proposals
>>> than the list.  For draft proposals that haven't made it yet, as long as
>>> they fall within the guidelines for proposals of a specific round, there's
>>> no reason you shouldn't be able to dig the discussion back up again and
>>> just talk about it.  Who knows, maybe you'll get a proposal submitted to
>>> GitHub that way with your name on it too - at the very least you'll learn
>>> something.  In a strange way, I guess, I'm saying we might not need this.
>>> If somebody replies "by the by, we discussed this " it's not meant to
>>> dismiss you as unoriginal.  You can use that old thread as a further
>>> jumping off point if you wish to continue discussion.
>>>
>>> tl;dr Keeping track of every idea pitched here would quickly grow...
>>> unmaintainable.
>>>
>>> ~Robert Widmann
>>>
>>> 2016/09/28 11:03、Jay Abbott via swift-evolution <
>>> swift-evolution@swift.org> のメッセージ:
>>>
>>> Hello,
>>>
>>> I had an idea and eventually discovered trawling through the archives of
>>> this list that quite a few other people have had the same idea and it has
>>> been discussed. Multiple times. This was not easy to discover, and judging
>>> from some of the messages I came across other people hadn't found and read
>>> them.
>>>
>>> I imagine this is frustrating and potentially time-consuming for the
>>> list, with people proposing or reopening ideas that have already been
>>> discussed, and it's likely frustrating for those people trying to get
>>> involved too, possibly discouraging them from participating further.
>>>
>>> I have some ideas about how to solve/mitigate this, not sure if they are
>>> any good, but I'd be interested to hear your thoughts.
>>>
>>> 1. Add a draft-proposals directory to the swift-evolution repo. People
>>> would still discuss it here first, then add a draft and send a PR.
>>>
>>> Pros:
>>> Easy to find and search; Easy to link to; Things that are suitable for
>>> future discussion/review would have a place to live until their time;
>>> Commonly proposed already have a place, but uncommon ones could live here;
>>> Could be categorised (perhaps in sub-directories or by renaming files to
>>> 

Re: [swift-evolution] draft proposals should be easier to find

[Jay Abbott via swift-evolution]

I don't really understand this concept of only accepting proposals for a
specific round. I saw some ideas that were suitable for future rounds of
proposals but not right now... Why aren't they captured in a better format
than the mailing list archive? If you don't want to be distracted by future
things then capture them as proposals but file them out of the way a bit so
that people can see they exist - I would have thought this would decrease
distractions from people bringing them up again.

On Wed, 28 Sep 2016 at 16:14 Robert Widmann <devteam.cod...@gmail.com>
wrote:

> There's a difference between "was once discussed here" and "had a proposal
> submitted to Github for consideration".  If many people are producing the
> same ideas for proposals that exist on GitHub that poses a more pressing
> risk.  But it is easier to search GitHub for such proposals than the list.
> For draft proposals that haven't made it yet, as long as they fall within
> the guidelines for proposals of a specific round, there's no reason you
> shouldn't be able to dig the discussion back up again and just talk about
> it.  Who knows, maybe you'll get a proposal submitted to GitHub that way
> with your name on it too - at the very least you'll learn something.  In a
> strange way, I guess, I'm saying we might not need this.  If somebody
> replies "by the by, we discussed this " it's not meant to dismiss you
> as unoriginal.  You can use that old thread as a further jumping off point
> if you wish to continue discussion.
>
> tl;dr Keeping track of every idea pitched here would quickly grow...
> unmaintainable.
>
> ~Robert Widmann
>
> 2016/09/28 11:03、Jay Abbott via swift-evolution <swift-evolution@swift.org>
> のメッセージ:
>
> Hello,
>
> I had an idea and eventually discovered trawling through the archives of
> this list that quite a few other people have had the same idea and it has
> been discussed. Multiple times. This was not easy to discover, and judging
> from some of the messages I came across other people hadn't found and read
> them.
>
> I imagine this is frustrating and potentially time-consuming for the list,
> with people proposing or reopening ideas that have already been discussed,
> and it's likely frustrating for those people trying to get involved too,
> possibly discouraging them from participating further.
>
> I have some ideas about how to solve/mitigate this, not sure if they are
> any good, but I'd be interested to hear your thoughts.
>
> 1. Add a draft-proposals directory to the swift-evolution repo. People
> would still discuss it here first, then add a draft and send a PR.
>
> Pros:
> Easy to find and search; Easy to link to; Things that are suitable for
> future discussion/review would have a place to live until their time;
> Commonly proposed already have a place, but uncommon ones could live here;
> Could be categorised (perhaps in sub-directories or by renaming files to
> have a different prefix) for "not viable" "yes, write it up and move to
> proposals" "consider later" "no, never" etc.
>
> Cons:
> Would get big and might need some cleaning from time to time; More PRs to
> deal with - although a quick scan is all that would be needed;
>
> 2. Add a currently_proposed.md file. This would have a similar purpose,
> but would be 3 lines only - Title (link to mailing list archive of
> discussion), Description (one-line), Status/comment.
>
> Pros and Cons are basically the same as 1.
>
> 3. Add a separate category to the bug tracker for proposals.
>
> Pros: ?
> Cons: ?
>
> Not sure how that's currently used, or if mixing up dev and evolution
> related items is acceptable or not, so I'm not sure if this is
> viable/practical.
>
> ___
> 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] associated objects

[Jay Abbott via swift-evolution]

I have implemented Associated Objects (and values) in pure swift here:
https://github.com/j-h-a/AssociatedObjects

The README is very short and straight-forward so I won't re-describe it
here.

The implementation isn't great, but it's a small and simple proof of
concept. I have further extended this (not in GH, but very simple and happy
to share if anyone cares) to add dynamic methods using closures onto
individual object instances. Useful for user interactions, or adding
'actions' to objects.

I'd like to propose that this or something similar be added to the standard
library. It could potentially even be added to AnyObject so that developers
can use it without having to declare an extension for whichever classes
they want to use it on.

As mentioned, this can easily be extended (either in the standard library
or by developers) to add closures dynamically to any object, or to any
class, which could serve as a useful way for those not concerned with type
safety and the like to get some dynamic behaviour in there in the shorter
term. With a little language support it could even be used to implement
stored properties in extensions very easily.

A better implementation would need some language changes - specifically
deinit hooks (has that ever been discussed?) because of the way weak
references are lazily zeroed. Another implementation improvement might
lazily add the dictionary to each object instead of storing it globally -
not sure if this would have ABI implications.

Interested in feedback and thoughts :)
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

[swift-evolution] draft proposals should be easier to find

[Jay Abbott via swift-evolution]

Hello,

I had an idea and eventually discovered trawling through the archives of
this list that quite a few other people have had the same idea and it has
been discussed. Multiple times. This was not easy to discover, and judging
from some of the messages I came across other people hadn't found and read
them.

I imagine this is frustrating and potentially time-consuming for the list,
with people proposing or reopening ideas that have already been discussed,
and it's likely frustrating for those people trying to get involved too,
possibly discouraging them from participating further.

I have some ideas about how to solve/mitigate this, not sure if they are
any good, but I'd be interested to hear your thoughts.

1. Add a draft-proposals directory to the swift-evolution repo. People
would still discuss it here first, then add a draft and send a PR.

Pros:
Easy to find and search; Easy to link to; Things that are suitable for
future discussion/review would have a place to live until their time;
Commonly proposed already have a place, but uncommon ones could live here;
Could be categorised (perhaps in sub-directories or by renaming files to
have a different prefix) for "not viable" "yes, write it up and move to
proposals" "consider later" "no, never" etc.

Cons:
Would get big and might need some cleaning from time to time; More PRs to
deal with - although a quick scan is all that would be needed;

2. Add a currently_proposed.md file. This would have a similar purpose, but
would be 3 lines only - Title (link to mailing list archive of discussion),
Description (one-line), Status/comment.

Pros and Cons are basically the same as 1.

3. Add a separate category to the bug tracker for proposals.

Pros: ?
Cons: ?

Not sure how that's currently used, or if mixing up dev and evolution
related items is acceptable or not, so I'm not sure if this is
viable/practical.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] class/struct inner member access scope classifier

[Jay Abbott via swift-evolution]

If a submodule doesn't provide self contained functionality then it
shouldn't be a submodule, and if it does then it might as well be a
separate module. I think submodules would discourage small granular module
development and composition at a larger scale, it would discourage making a
clean public interface for the module which might make them more reusable
and testable. Also of course it would mean more keywords/syntax/classifiers
to manage it which makes things more complicated (unnecessarily in my view).

But I haven't really thought much about potential advantages... what are
they?


On Tue, 27 Sep 2016 at 19:55 Sean Heber via swift-evolution <
swift-evolution@swift.org> wrote:

> This was all already argued about *extensively*. As in.. for weeks and
> weeks.
>
> For the record, I still think things are mis-named, but that ship has
> sailed. IMO the existing “fileprivate” should have been “internal” and
> existing “internal” should have been “external”. But oh well.
>
> l8r
> Sean
>
>
> > On Sep 27, 2016, at 1:40 PM, Nevin Brackett-Rozinsky via swift-evolution
>  wrote:
> >
> > In another thread (no link because we’re not on a forum ;-) the idea was
> raised that in the future, if and when Swift starts using submodules, the
> “fileprivate” scope could be turned into “submodule” scope.
> >
> > By default every file would constitute its own submodule, and developers
> could choose to put several files together into a submodule if they wish.
> >
> > Perhaps there may be a shorter word that nicely implies “submodule
> scope”.
> >
> > Nevin
> >
> >
> >
> > On Tue, Sep 27, 2016 at 12:20 PM, Jeremy Pereira via swift-evolution <
> swift-evolution@swift.org> wrote:
> >
> > > On 27 Sep 2016, at 14:20, Zach Waldowski via swift-evolution <
> swift-evolution@swift.org> wrote:
> > >
> > >
> > >
> > >
> > > On Tue, Sep 27, 2016, at 01:34 AM, Jeremy Pereira via swift-evolution
> > > wrote:
> > >> As for dropping file private, why? You don’t have to use it if you
> don’t
> > >> want to, so it’s not hurting you. On the other hand, I can use it
> when I
> > >> deem it to be the right thing to do.
> > >
> > > I'll politely disagree and point out you *must* use fileprivate in
> order
> > > to get what it provides. It's unavoidable in that sense.
> >
> > That’s not the point I was making. It was mooted that fileprivate should
> be dropped altogether leading to not having any means of specifying file
> scope at all. I was simply pointing out that people who don’t like file
> scope already have the option of not using fileprivate.
> >
> >
> > ___
> > 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