Re: [swift-evolution] [Pitch] Replace 'inout' with '&'

> On Dec 19, 2015, at 4:10 PM, Erica Sadun wrote: > > What would the ramifications of the following be? Each addresses the > "confusable with labeling" issue but preserve the inout keyword. > > func foo(x: inout Int) > ... I think I like this one better than all the

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

Thanks for the clarification. Why is the compiler saying that the catch is not exhaustive when it is covering all the possible values of the enum? Is it to be able to catch future values added to the enum type? > On Dec 18, 2015, at 8:05 PM, David Owens II wrote: > > >>

Re: [swift-evolution] Lambda function syntax

I think "in" is slightly easier to type in than "=>". The => may be interpreted as equal or greater than. On Dec 22, 2015, at 9:52 PM, Andrey Tarantsov via swift-evolution wrote: >> And yes, I certainly would prefer `=>` rather than `in`. > > It seems like the

Re: [swift-evolution] [Draft] Automatically deriving Equatable and Hashable for certain value types

that get used unless you > implement ones yourself. > > >> On 27 May 2016, at 12:57 PM, Ricardo Parada via swift-evolution >> <swift-evolution@swift.org> wrote: >> >> >> >> I wonder if synthesizes would be a better choice than deriving. >>

Re: [swift-evolution] [Draft] Automatically deriving Equatable and Hashable for certain value types

What if we get the error when trying to use it? For example, if a struct uses a value that is not Equatable / Hashable then it would not be Equatable / Hashable and you would not find out until you tried to use it. Would that be bad? > On May 26, 2016, at 11:35 AM, Matthew Johnson via

Re: [swift-evolution] [Pitch] Property reflection

> On May 26, 2016, at 9:25 PM, Austin Zheng via swift-evolution > wrote: > > ``` > myPerson.typedReadWriteProperty("age")?.set(30) > > try myPerson.allNamedProperties["age"]?.set(30) > ``` > Can you elaborate on what this API would be used for? KVC? For instance,

Re: [swift-evolution] [Pitch] Property reflection

Would it let me get a property if it does not correspond to a property, or computed property? For example, would I be able to get the value returned by a fullName() instance method that concatenates the firstName and lastName properties together and returns the result? Or would it only work

Re: [swift-evolution] [Draft] Automatically deriving Equatable and Hashable for certain value types

Inline > On May 27, 2016, at 2:52 PM, Matthew Johnson wrote: > > >> On May 27, 2016, at 12:48 PM, Ricardo Parada wrote: >> >> >> What if we get the error when trying to use it? For example, if a struct >> uses a value that is not Equatable /

Re: [swift-evolution] [Draft] Automatically deriving Equatable and Hashable for certain value types

gt; I don’t understand why you couldn’t conform to Equatable, and if it fulfils >>> the requirements (all members are also Equatable), then its implementation >>> is automatically created for you. That way you don’t need a new keyword. >>> It’s like Objective-C’s property

Re: [swift-evolution] Ad hoc enums / options

<swift-evolution@swift.org> wrote: >>> >>> >> >>> On Jun 1, 2016, at 7:48 PM, Ricardo Parada via swift-evolution >>> <swift-evolution@swift.org> wrote: >>> >>> >>> On May 31, 2016, at 3:04 PM, Erica Sadun via swift-evolution >>

Re: [swift-evolution] [Draft] Automatically deriving Equatable and Hashable for certain value types

As Steve Jobs once said when demoing Interface Builder during the NeXT days: "The line of code you don't have to write is the line of code you don't have to debug." P.S. I hope I got the quote right, but that was the idea. :-) Sent from my iPhone > On May 25, 2016, at 10:02 PM, Patrick

Re: [swift-evolution] [Draft] Automatically deriving Equatable and Hashable for certain value types

I like this. I don't see why not make this the default. If someone thinks it is not needed for their application then they simply don't use it. Having it there would not cause any harm. Unless someone had a requirement to have strict control on the size of the application and had to cut

Re: [swift-evolution] [Draft] Automatically deriving Equatable and Hashable for certain value types

I wonder if synthesizes would be a better choice than deriving. > On May 26, 2016, at 5:58 AM, Michael Peternell via swift-evolution > wrote: > > Can we just copy the solution from Haskell instead of creating our own? > It's just better in every aspect.

Re: [swift-evolution] Ad hoc enums / options

> On Jun 1, 2016, at 5:38 PM, Tony Allevato via swift-evolution > wrote: > > we could consider allowing this: > > func foo(bar: (.fit | .fill)) { > baz(bar: bar) > } > func baz(bar: (.fit | .fill | .florp) { ... } > > In other words, an ad hoc

Re: [swift-evolution] Ad hoc enums / options

> On May 31, 2016, at 3:04 PM, Erica Sadun via swift-evolution > wrote: > > let _ = scaleAndCropImage(image: myImage, toSize: size, operation: .fill) > > You would not be able to assign `.fill` to a variable and use that for the > operation value. This is my

Re: [swift-evolution] SetAlgebra naming update

Hi all, I could get used to the formNoun naming convention for the mutable versions of the methods. I would suggest the following changes: Remove the parameter label from symmetricDifference() and formSymmetricDifference() to be consistent with the other methods. Consider renaming:

Re: [swift-evolution] RFC: didset and willset

I think camelCase is richer and easier to read. > On May 20, 2016, at 10:26 AM, Matthew Johnson via swift-evolution > wrote: > > > > Sent from my iPad > > On May 20, 2016, at 1:34 AM, Brent Royal-Gordon via swift-evolution > wrote: >

Re: [swift-evolution] RFC: didset and willset

If accessors are defined by the developer who designs a property behavior then I do not see them as keywords. Or am I wrong? That is why I would prefer them lowerCamelCase. On May 20, 2016, at 1:50 PM, Chris Lattner via swift-evolution wrote: >> Thus, `willSet`

Re: [swift-evolution] RFC: didset and willset

I like them camelCase. > On May 18, 2016, at 4:58 PM, Erica Sadun via swift-evolution > wrote: > > >> On May 18, 2016, at 2:56 PM, Krystof Vasa wrote: >> >> Not to mention @NSApplicationMain, @NSManaged, ... >> >> I'd personally keep it

Re: [swift-evolution] RFC: didset and willset

Correction. I meant lowerCamelCase not CamelCase. Sent from my iPhone > On May 20, 2016, at 7:18 PM, Ricardo Parada via swift-evolution > <swift-evolution@swift.org> wrote: > > If I remember correctly the property behaviors proposal it seemed that > accessors su

Re: [swift-evolution] RFC: didset and willset

If I remember correctly the property behaviors proposal it seemed that accessors such as willSet, didSet, willRead, etc. were being called. I look at them at the same level as instance methods, properties, etc. and should follow camelCase. Not to mention that I think they look so much better

Re: [swift-evolution] [Review] SE-0088: Modernize libdispatch for Swift 3 naming conventions

Jacob Bandes-Storch suggested: synchronously(execute work: …) So maybe that will conform to the API naming guideline? Or would the verb have to be in the base name of the func? Or perhaps: synchronously(dispatch work: …) asynchronously(dispatch work: …) > On May 11, 2016, at 9:32 AM,

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0084: Allow trailing commas in parameter lists and tuples

> On May 10, 2016, at 2:53 PM, Chris Lattner wrote: > > Hello Swift community, > > The review of "SE-0084: Allow trailing commas in parameter lists and tuples" > begins now and runs through May 16. The proposal is available here: > > >

Re: [swift-evolution] multi-line string literals.

I did not suggest the single quote because it is commonly found in the English language and we would have to escape it. That is why I suggested a rare combination using the @" and "@ as the delimiters. Unless your text is Obj-C code it would be rare to find it. > On May 11, 2016, at 10:50

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0081: Move where clause to end of declaration

> On May 10, 2016, at 2:51 PM, Chris Lattner wrote: > > Hello Swift community, > > The review of "SE-0081: Move where clause to end of declaration" begins now > and runs through May 16. The proposal is available here: > > >

Re: [swift-evolution] [Review] SE-0085: Package Manager Command Names

+1 for "swift package ..." I would use aliases if I want to type less. > On May 9, 2016, at 6:05 PM, Daniel Dunbar via swift-evolution > wrote: > > Hello Swift community, > > The review of "SE-0085: Package Manager Command Names" begins now and runs > through May

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0084: Allow trailing commas in parameter lists and tuples

Dropping the commas looks good and doesn't look like someone made a mistake. I don't know what other implications / complications dropping the commas would have but I like it. > On May 11, 2016, at 12:20 PM, Vladimir.S via swift-evolution > wrote: > >

Re: [swift-evolution] multi-line string literals.

> On May 11, 2016, at 12:55 PM, Vladimir.S wrote: > > > On 11.05.2016 19:38, Ricardo Parada wrote: >> I did not suggest the single quote because it is commonly found in the >> English language and we would have to escape it. > > Wel.. in your document you have a number of

Re: [swift-evolution] multi-line string literals.

\(author) >> +" XML Developer's Guide >> +" Computer >> +" 44.95 >> +" 2000-10-01 >> +" An in-depth look at creating applications with >> XML. >> +&quo

Re: [swift-evolution] [Draft] Introducing StaticSelf, an Invariant Self

I would prefer BaseSelf. > On May 13, 2016, at 2:28 AM, Vladimir.S via swift-evolution > wrote: > > via ___ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Draft] Introducing StaticSelf, an Invariant Self

That makes sense to me. > On May 13, 2016, at 2:45 AM, Patrick Smith via swift-evolution > wrote: > > If a conformance absolutely needs to have a method returning ‘only me but not > my subclasses’, then it sets that conforming method to be final.

Re: [swift-evolution] [Review] SE-0084: Allow trailing commas in parameter lists and tuples

I agree. > On May 12, 2016, at 3:36 AM, Vladimir.S via swift-evolution > wrote: > > Fully support your opinion. > > > PS: can they actually be removed EVERYWHERE instead?! > > Yes, I believe it will be much better to propose feature to allow line break > instead

Re: [swift-evolution] multi-line string literals.

I like the continuation quote. It makes the code stay pretty. It doesn't break the indentation of your code. If you take out the continuation quote then things look out of place, as if someone pasted text in the middle of your code by mistake. I don't like the heredoc notation either for the

Re: [swift-evolution] multi-line string literals.

I like the continuation quote. It makes the code stay pretty. It doesn't break the indentation of your code. If you take out the continuation quote then things look out of place, as if someone pasted text in the middle of your code by mistake. I don't like the heredoc notation either for the

Re: [swift-evolution] multi-line string literals.

I think that is another one of the advantages of using the continuation quotes. Sent from my iPhone > On May 5, 2016, at 4:51 PM, Brent Royal-Gordon via swift-evolution > wrote: > > I think it's nice that I can look at any line—out of context, random >

Re: [swift-evolution] multi-line string literals.

If we use triple quotes (i.e. """) at the beginning of the multi line string literal and again at the end, it seems very unlikely that the heredoc notation would be needed. I would simplify and remove the heredoc alternative from the proposal. Also, for those of us who like the continuation

Re: [swift-evolution] [Idea] Passing an Array to Variadic Functions

What would that look like? > On Apr 18, 2016, at 3:06 PM, Erica Sadun via swift-evolution > wrote: > > >> On Apr 18, 2016, at 1:01 PM, Tony Allevato via swift-evolution >> wrote: >> >> I would also be supportive of removing varargs

Re: [swift-evolution] [Idea] Passing an Array to Variadic Functions

Would that require some compiler magic, i.e. foo(#splat(arr)) > On Apr 19, 2016, at 12:51 PM, Vladimir.S via swift-evolution > wrote: > > I suggest to look at the subject of this thread and initial proposal: > "Swift should allow passing an *array to variadic

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

WebObjects is one of the frameworks I was referring to without actually naming it. After Apple stopped supporting WebObjects we have been able to fix, extend and enhance it all these years and has served us really well. It is an awesome framework. I really wish that Swift had a framework like

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

> On Jul 5, 2016, at 7:11 PM, Chris Lattner wrote: > > Hello Swift community, > > The review of "SE-0117: Default classes to be non-subclassable publicly" > begins now and runs through July 11. The proposal is available here: > > >

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

I have been following the discussion and reading the arguments in favor and against. I think I understand both sides better now. If this proposal is accepted I hope some more thought is given to the naming. I would like to echo what others have said regarding the names. In particular I am

Re: [swift-evolution] Three questions about a more "dynamic" Swift for InfoQ

> On Sep 26, 2016, at 5:32 PM, Robert Widmann via swift-evolution > wrote: > > No, and I think moving towards a more dynamic Swift now without > as-of-yet-seen significant justification would be a mistake. Swift should be > as static as possible. We should be

Re: [swift-evolution] Smart KeyPaths

> On Mar 22, 2017, at 9:30 AM, Vladimir.S wrote: > > let path = @Bag.things[0].name > > bag@path > bag@.things[0].name > bag@Bag.things[0].name > bag.things[0]@.name > bag.things[0]@Thing.name It sounds like the @ character is serving two different purposes which confused

Re: [swift-evolution] Smart KeyPaths

I see three possibilities: 1) # + «space» +«path» like this: let path = # Bag.things[0].name bag[path] bag[# Bag.things[0].name] bag[# .things[0].name] // Root is inferred as Bag bag.things[0][# Thing.name] bag.things[0][# .name] // Root is inferred as Thing 2) # + «path» like this:: let

Re: [swift-evolution] Smart KeyPaths

Agree. Another question. If `Bag` does have a static thing called `myStaticThingy` would you refer to it as: Bag.Type#myStaticThingy ? > On Mar 22, 2017, at 12:37 PM, Matthew Johnson wrote: > >> >> On Mar 22, 2017, at 11:16 AM, Ricardo Parada >

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

After reading the discussions it seems to me that renaming private -> scoped and fileprivate -> private might keep both sides happy. > On Mar 24, 2017, at 9:06 AM, Vladimir.S via swift-evolution > wrote: > >> On 24.03.2017 11:47, Jonathan Hull via swift-evolution

Re: [swift-evolution] Smart KeyPaths

> On Mar 29, 2017, at 10:21 PM, James Berry via swift-evolution > wrote: > > Or migrate swift 3 #keyPath to #objcKeyPath to preserve that legacy intent > while retaining #keyPath for our bright and unsullied future? ;) I like this suggestion.

Re: [swift-evolution] Smart KeyPaths

> On Mar 30, 2017, at 9:54 AM, Haravikk via swift-evolution > wrote: > > Personally I'd prefer the use of a leading dollar sign for this, for example: > > $Person.friend.lastName That looks clean. I don't think it could get confused with referencing named

Re: [swift-evolution] Smart KeyPaths

Yes, I was about to ask the same. It seems like all the sigil characters are taken. This is one of the reasons why I did not object to the non-sigil notation originally proposed despite the ambiguity with static properties and instance properties with the same name. But using a sigil seems

Re: [swift-evolution] Smart KeyPaths

22, 2017, at 4:51 PM, Ricardo Parada via swift-evolution > <swift-evolution@swift.org> wrote: > > Yes, I was about to ask the same. > > It seems like all the sigil characters are taken. This is one of the reasons > why I did not object to the non-sigil notation

Re: [swift-evolution] Smart KeyPaths

It looks awesome. I don’t understand the details yet but I always felt it would be super cool if swift allowed you to express key paths elegantly which seems what this is. I would love to be able to create what used to be called EOQualifier in WebObjects/Enterprise Objects Framework (i.e.

Re: [swift-evolution] Smart KeyPaths

I agree that they can get mixed up with static properties. However, I think I would not mind because it would only cause an ambiguity when having a static property with the same name as the property which would be an odd practice I think. I was defining static properties with the same name

Re: [swift-evolution] Smart KeyPaths

Sent from my iPhone > On Mar 19, 2017, at 4:53 PM, Matthew Johnson via swift-evolution > wrote: > > > > Sent from my iPhone > >> On Mar 19, 2017, at 3:45 PM, Brent Royal-Gordon via swift-evolution >> wrote: >> On Mar 19, 2017,

Re: [swift-evolution] Smart KeyPaths

. I'm excited about this proposal and want it to be the successful. One of the most exciting things happening in swift right now IMHO. > On Mar 19, 2017, at 3:51 PM, Jean-Daniel <mail...@xenonium.com> wrote: > > >> Le 19 mars 2017 à 16:41, Ricardo Parada via swift-evolution

Re: [swift-evolution] Smart KeyPaths

That is very interesting: "formatting templates that are well typed." Would that be like a template and keypaths that were archived to a file, similar to a .nib file? > On Mar 20, 2017, at 7:28 PM, Joe Groff via swift-evolution > wrote: > > >> On Mar 20, 2017, at

Re: [swift-evolution] Fwd: Re: Smart KeyPaths

If a character had to be used to denote key paths then I would prefer this one: 1. Type:path.to.value and instance:path.to.value I feel like the # screams at me. :-) > On Mar 20, 2017, at 1:52 PM, Matthew Johnson via swift-evolution > wrote: > > >> On Mar 20,

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

I'm in favor of this pattern. > On Mar 20, 2017, at 4:40 PM, Jonathan Hull via swift-evolution > wrote: > > Huge +1 > > >> On Mar 17, 2017, at 9:26 AM, Riley Testut via swift-evolution >> wrote: >> >> Hi again everyone! >> >> Now

Re: [swift-evolution] Smart KeyPaths

Thanks to both of you for pointing how to disambiguate and how generic types can be inferred. I now think that this is the way to go. It looks to me like it is the simplest and the most elegant solution. > On Mar 17, 2017, at 6:05 PM, Joe Groff via swift-evolution >

Re: [swift-evolution] Smart KeyPaths

I like it the way they have it in the proposal because it is consistent with referencing methods and initializers. And as mentioned previously it can be disambiguated on the edge cases. > On Mar 20, 2017, at 9:11 AM, Matthew Johnson via swift-evolution > wrote:

Re: [swift-evolution] Smart KeyPaths

Sometimes I feel like we need a winning sigil for this, one that would look good, it is not already taken and easy to type in all keyboards. Maybe we'll have to start looking at emojis :-) > On Mar 21, 2017, at 9:13 PM, Matthew Johnson via swift-evolution >

Re: [swift-evolution] [Draft] Dictionary & Set Enhancements

Some thoughts after reviewing it a second time: I am not sure I like having global functions first(_:_:) and last(_:_:). Would it be possible to default the closure to do what last(_:_:) would do? I'm assuming the most popular thing to do is to have the values from the second dictionary

Re: [swift-evolution] [Draft] Dictionary & Set Enhancements

It looks very useful. I did not quite get the role of the DictionaryLiteral but everything looks very nice. > On Apr 1, 2017, at 3:58 PM, Nate Cook via swift-evolution > wrote: > > Yep, here it is -- didn't realize the length would cause such problems! > >

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

Yep, I like those too. I think it would be very clear if they were named that. > On Apr 3, 2017, at 3:57 PM, Adam Bridge <abri...@mac.com> wrote: > > Perhaps > > allMembersMatch() > > or > > everyMemberMatches() > > This reads well in use. > >

Re: [swift-evolution] Enhancing access levels without breaking changes

I have not voted in favor or against the proposal. I have been reading a lot of responses but I agree with Tony. When I started reading the proposal everything was more or less fine half way through the proposal because it was reverting private to fileprivate between the type and its

Re: [swift-evolution] [Review] SE-0168: Multi-Line String Literals

Hi Adrian, I think having the closing """ on a line by itself activates the indentation stripping feature. So if it was to change as you suggest then how would you turn off indentation stripping? > On Apr 11, 2017, at 11:08 AM, Adrian Zubarev via swift-evolution >

Re: [swift-evolution] [Review] SE-0161: Smart KeyPaths: Better Key-Value Coding for Swift

By the way, does anybody know why the proposed syntax require a leading period for the key path? #keyPath(Family, .pets.first) In other words, why not just this: #keyPath(Family, pets.first) Or Brent's proposed: #keyPath(pets.first) > On Apr 3, 2017, at 2:08 AM, Brent Royal-Gordon via

Re: [swift-evolution] multi-line string literals.

I think we should focus on taking care of 99% of the cases. If you have a very long string then you use the good old fashioned string literal concatenation: Let veryLongString2 = "word word word" + "word word word" + "word word word" By the way, the multi-line string should

Re: [swift-evolution] multi-line string literals.

How is that better than this? template = "This is the first line.\n" + "This is the second line.\n" + "This is the third line." > On Apr 3, 2017, at 10:42 AM, Ricardo Parada via swift-evolution > <swift-evolution@swift.org> w

Re: [swift-evolution] multi-line string literals.

What is the purpose of that backslash? It does not feel like an improvement. I think we should focus on: 1. Looking pretty 2. Allow unescaped quote, double quote as well single/double apostrophe characters 3. Allow interpolation 4. No need to add the \n character for each line 5. It should

Re: [swift-evolution] multi-line string literals.

It look prettier without the \n It's not laziness. I want my code to look pretty. > On Apr 3, 2017, at 10:40 AM, Adrian Zubarev > wrote: > > What I was trying to say is that by automatically adding a new line character > does not provide any benefit except

Re: [swift-evolution] multi-line string literals.

Hi Adrian, I'm not sure if I am understanding what you are saying. To me a multi-line string literal is not about continuing a "very long string" into the next line. To me a multi-line string literal is about having a string literal that represents multiple lines of text, where each line is

Re: [swift-evolution] multi-line string literals.

Actually, it would be like this: let veryLongString2 = "word word word" + "word word word" + "word word word" > On Apr 3, 2017, at 10:29 AM, Ricardo Parada via swift-evolution > <swift-evolution@swift.org> wrote: > > I think we

Re: [swift-evolution] multi-line string literals.

com>) schrieb: > >> How is that better than this? >> >> template = "This is the first line.\n" + >> "This is the second line.\n" + >> "This is the third line." >> >>> On Apr 3, 2017, at 10:42

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

I agree. > On Mar 31, 2017, at 5:32 PM, Robert Bennett via swift-evolution > wrote: > > I'm don't think we need all(equal:). > 1) For a host of reasons, having a single signature for a function name is > better than having multiple signatures when the single

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

I associate exception with error. Sent from my iPhone > On Apr 2, 2017, at 9:32 AM, BJ Homer via swift-evolution > wrote: > > 'forAll' is definitely confusing; it sounds like iteration; I would not > expect that the closure would be required to return a Bool. The

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

I think the problem would be that if you want to use it with a trailing closure then it becomes misleading: nums.contains { $0 % 2 == 0 } Sent from my iPhone > On Apr 2, 2017, at 9:01 PM, Jonathan Hull via swift-evolution > wrote: > > What about contains(only:)?

Re: [swift-evolution] [Review] SE-0168: Multi-Line String Literals

If Xcode or code editors displayed a vertical line at the indentation boundary then it would be like having the continuation character without actually being there. The best of both worlds. That would be really nice. > On Apr 11, 2017, at 8:48 PM, Ricardo Parada via swift-evolut

Re: [swift-evolution] [Review] SE-0168: Multi-Line String Literals

> On Apr 11, 2017, at 8:32 PM, Brent Royal-Gordon via swift-evolution > wrote: > ... > But I'd love to see a faint reddish background behind tripled string literal > content or a vertical line at the indentation boundary. That would be very nice. :-)

Re: [swift-evolution] [Review] SE-0168: Multi-Line String Literals

Sure. Let me quote the proposal: "We propose that, when the opening delimiter ends its line and the closing delimiter starts its line, tripled string literals should automatically remove whatever indentation is present before the closing delimiter from each line above it, as well as removing

Re: [swift-evolution] [Review] SE-0168: Multi-Line String Literals

I don't think I would use that. I don't find the aesthetics pleasant. I would rather comment above the string literal. Would the escape character cause the newline for the line to be ignored thereby continuing the string on the next line? > On Apr 12, 2017, at 6:59 AM, Adrian Zubarev via

Re: [swift-evolution] Enhancing access levels without breaking changes

> On Apr 12, 2017, at 1:42 AM, Chris Lattner via swift-evolution > wrote: > > On Apr 11, 2017, at 10:30 PM, David Hart wrote: >>> To me, the reason for limiting it to a file is about predictability, the >>> ability to locally reason about a type,

Re: [swift-evolution] [Review] SE-0168: Multi-Line String Literals

I agree. That would be very useful. > On Apr 12, 2017, at 6:16 AM, Thorsten Seitz via swift-evolution > wrote: > >> Am 12.04.2017 um 10:11 schrieb Adrian Zubarev via swift-evolution >> : >> >> Great explanation thank you Brent. I’m

Re: [swift-evolution] [Review] SE-0168: Multi-Line String Literals

Hi all, I agree as well, I think we should make optimize for the most common case of multi-line strings. A rule that says strip the first leading newline as well as the trailing newline. So it's almost back to where Brent started with the addition of removing the trailing newline.

Re: [swift-evolution] [Review] SE-0168: Multi-Line String Literals

; // v1: > > """ > > foo > bar\ > """ > > // v2: > """ > \n\ > foo > bar\ > """ > > // v3: > """ > \nfoo > bar\ > """ > > > > -- > Adri

Re: [swift-evolution] [Review #2] SE-0161: Smart KeyPaths: Better Key-Value Coding for Swift

> > // optional properties work too > let bestFriendsNameKeyPath = \Person.bestFriend?.name) > ^ this > ``` > > If it’s intentional, I’m very much against it. > > Cheers, > Ed > >> On 6 Apr 2017, a

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

If we were looking for conciseness then my picks would be: every() - every elements meets condition any() - anyone element meets condition none() - none of the elements meets condition Examples: nums.every { isEven } nums.any { isEven } nums.none { isEven } nums.every(matches: { isEven })

Re: [swift-evolution] Pitch: Compound name `foo(:)` for nullary functions

Agree. > On Apr 6, 2017, at 8:02 AM, Xiaodi Wu via swift-evolution > wrote: > > Given that \foo(bar:baz:) will work, and that \foo() will be unambiguously > distinguished from foo(), I think that would be the only logical result. > > > On Thu, Apr 6, 2017 at

Re: [swift-evolution] [Review #2] SE-0161: Smart KeyPaths: Better Key-Value Coding for Swift

The escape character is already being used in String interpolation, i.e. \(foo). Also, escaping special characters in string literals, i.e. \t is tab, \n is a newline character, etc. The single quote does not appear to be in use. I believe it's not being used for string literals nor character

Re: [swift-evolution] [Review #2] SE-0161: Smart KeyPaths: Better Key-Value Coding for Swift

I did not mention single quotes because I was assuming those were reserved for string literals. But if they are available for something like this, it would make it obvious where the key path begins and where it ends. I went through my hypothetical code samples, and I don't mind the \ escape

Re: [swift-evolution] [Review #2] SE-0161: Smart KeyPaths: Better Key-Value Coding for Swift

the closing character normally when wanting to invoke a method on the key path object. Any thoughts? > On Apr 6, 2017, at 11:13 AM, Ricardo Parada via swift-evolution > <swift-evolution@swift.org> wrote: > > I agree, there's an analogy between strings and key paths, and

Re: [swift-evolution] [Review #2] SE-0161: Smart KeyPaths: Better Key-Value Coding for Swift

I agree, there's an analogy between strings and key paths, and in that regards the single quote would make sense. I would not complain. > On Apr 6, 2017, at 11:08 AM, Sean Heber via swift-evolution > wrote: > >>> That's an interesting point. While `\` alone

Re: [swift-evolution] [Review #2] SE-0161: Smart KeyPaths: Better Key-Value Coding for Swift

le.com> wrote: > >> >> On Apr 6, 2017, at 9:31 AM, Sean Heber <s...@fifthace.com> wrote: >> >> >>> On Apr 6, 2017, at 11:19 AM, Douglas Gregor <dgre...@apple.com> wrote: >>> >>>> >>>> On Apr 6, 2017, at 8:13 AM

Re: [swift-evolution] [Review #2] SE-0161: Smart KeyPaths: Better Key-Value Coding for Swift

Ben Rimmington <m...@benrimmington.com> wrote: > > >> On 6 Apr 2017, at 16:29, Ricardo Parada via swift-evolution >> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >> >> Another thought on the use of single quotes (an possibl

Re: [swift-evolution] [Review] SE-0168: Multi-Line String Literals

> On Apr 6, 2017, at 3:35 PM, Joe Groff via swift-evolution > wrote: > > Hello Swift community, > > The review of SE-0168 "Multi-Line String Literals" begins now and runs > through April 12, 2017. The proposal is available here: > >

Re: [swift-evolution] [swift-evolution-announce] [Returned for revision] SE-0161: Smart KeyPaths: Better Key-Value Coding for Swift

+1 This is much better than #keyPath(Root, .path). I think I can get used to using the escape \ character. I'll think of it as escaping execution of the key path. > On Apr 5, 2017, at 7:01 PM, Douglas Gregor wrote: > > Proposal Link: >

Re: [swift-evolution] [Review #2] SE-0161: Smart KeyPaths: Better Key-Value Coding for Swift

> On Apr 5, 2017, at 9:41 PM, Brent Royal-Gordon via swift-evolution > wrote: > > It's worth noting that, if you write `\Person.name.valueType`, this syntax is > ambiguous—it could mean "make a key path for the `valueType` property on > `name` property of

Re: [swift-evolution] SE-165: Dictionary & Set Enhancements

+1 The only comment I have is the mergingValues argument label for the closure passed in to the merge methods. My preference would be resolvingCollisionsWith:, i.e. merge(_:resolvingCollisionsWith:) and merged(with:resolvingCollisionsWith:). > On Apr 5, 2017, at 8:45 PM, Ben Cohen via

Re: [swift-evolution] [Review #2] SE-0161: Smart KeyPaths: Better Key-Value Coding for Swift

pr 5, 2017 at 9:21 PM, Ricardo Parada via swift-evolution > <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: > >> On Apr 5, 2017, at 9:41 PM, Brent Royal-Gordon via swift-evolution >> <swift-evolution@swift.org <mailto:swift-evolution@swift

Re: [swift-evolution] [Review] SE-0168: Multi-Line String Literals

On Apr 9, 2017, at 12:29 PM, John Holdsworth via swift-evolution > wrote: > Hi, John here, the submitter of the proposal. > > First up, I must apologise for putting Brent on the spot when I resubmitted > this altered proposal from

Re: [swift-evolution] [Pitch] Remove type-inference for stored property

Type inference is one of my favorite features of Seift. I don't think anything would make me change my mind. I read the proposal and couldn't quite figure out why such a request. I still have to read the links that explain why though. Regards > On Apr 9, 2017, at 10:05 PM, Daniel Duan via

  1   2   >