Re: [swift-evolution] Swift source mentorship program

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

[swift-evolution] Swift source mentorship program

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

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

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),

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

t 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

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

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

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

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

[swift-evolution] out of scope proposals

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

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

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

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

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

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

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

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

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

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

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:

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

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

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

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

Re: [swift-evolution] Cancelable named defer statements

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

Re: [swift-evolution] [Thoughts?][Phase2] default arguments and trailing closure syntax

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

Re: [swift-evolution] Partial class declaration

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

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

@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

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

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

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

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

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

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 &

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

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

[swift-evolution] [pitch] Implementation composition

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()

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

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

Re: [swift-evolution] [Review] SE-0145: Package Manager Version Pinning (Revised)

> 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

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

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

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

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

Re: [swift-evolution] Add code to super methods.

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

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

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 =

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

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

Re: [swift-evolution] Some concerns on custom operators

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,

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

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

Re: [swift-evolution] Official Swift Slack team?

+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

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

@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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

> > 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: ! & * ( . -

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

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

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

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

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

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

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

un, 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 dictio

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

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

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

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

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

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

Re: [swift-evolution] stored properties in extensions

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

Re: [swift-evolution] stored properties in extensions

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

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

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 (et

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

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

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

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

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

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

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

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

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

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

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

t; > >> > 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 > >> >

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

e > 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-evolut

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

t 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

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

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

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

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

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

er-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 think

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

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

Re: [swift-evolution] private & fileprivate

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

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

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

Re: [swift-evolution] associated objects

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

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

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,

Re: [swift-evolution] $self

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

Re: [swift-evolution] $self

t 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 prim

Re: [swift-evolution] $self

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

Re: [swift-evolution] associated objects

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

Re: [swift-evolution] [Proposal draft] Introducing `indexed()` collections

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

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

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

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

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

[swift-evolution] associated objects

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

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

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

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

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