Re: [swift-evolution] [Proposal] Foundation Swift Archival & Serialization

> On Mar 17, 2017, at 2:38 PM, Matthew Johnson wrote: > >> At a broad level, that's a good idea. But why not provide something more >> precise than a bag of `Any`s here? You're in pure Swift; you have that >> flexibility. >> >> protocol Codable { >> associatedtype CodingConte

Re: [swift-evolution] Smart KeyPaths

> On Mar 17, 2017, at 3:17 PM, Michael LeHew via swift-evolution > wrote: > > One thing that gets interesting with the scope-restricted visibility of > KeyPaths, is what happens if an fileprivate KeyPath gets leaked out of the > file? That's a scary/maybe useful thing? I think that, as long

Re: [swift-evolution] [Proposal] Foundation Swift Archival & Serialization

> On Mar 17, 2017, at 3:35 PM, Matthew Johnson wrote: > >> In all seriousness, I see the design as very slightly weak, in that it makes >> it easy to forget to pass a context through, but quite acceptable. > > Easy for who? I was not requiring Codable types to thread it through at all. > Th

Re: [swift-evolution] [Proposal] Foundation Swift Archival & Serialization

> On Mar 19, 2017, at 12:21 PM, Tony Parker wrote: >> >> On Mar 19, 2017, at 12:14 PM, Matthew Johnson > > wrote: >> >> On Mar 19, 2017, at 10:47 AM, Tony Parker > > wrote: >> >>> Hi Matthew, Brent, >>> >>> I see why you are askin

Re: [swift-evolution] Smart KeyPaths

> On Mar 19, 2017, at 12:57 PM, Charles Srstka via swift-evolution > wrote: > >> I disagree. How the reader is supposed to now there is a static property or >> not ? Having readable code is more important than having easy to write code. > > I’ve got to agree with this. With the proposed syntax

Re: [swift-evolution] Smart KeyPaths

> On Mar 19, 2017, at 4:47 PM, Charles Srstka wrote: > >> This is true of many things. It is why IDEs make type information readily >> available. > > Is clarity not a thing to be desired? Clarity is in the eye of the beholder. Here's one notion of clarity: sum :: (Num a, Foldable t)

Re: [swift-evolution] [Proposal] Foundation Swift Archival & Serialization

> On Mar 19, 2017, at 5:51 PM, Matthew Johnson wrote: > > I generally agree with you about casting. However, my dislike isn’t the cast > itself, but instead it is the lack of a static guarantee. I’m not sure we’ll > find a solution that provides a static guarantee that a required context > e

Re: [swift-evolution] [Proposal] Foundation Swift Archival & Serialization

> On Mar 19, 2017, at 8:19 PM, Matthew Johnson wrote: > > First, your solution does not allow a user to see a context if they can't > name the type (you can't get it as Any and use reflection, etc). What I meant is that, if you retrieve the context, you know it is of the type you expect. You d

Re: [swift-evolution] [Proposal] Foundation Swift Archival & Serialization

> On Mar 20, 2017, at 12:31 PM, Itai Ferber wrote: > > I don’t think there’s much of a difference between adding an "optional" > primitive (which has a default implementation in terms of a different > primitive) and simply having that type adopt Codable itself and not be a > primitive. You can

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

> On Mar 20, 2017, at 8:26 PM, Charles Srstka via swift-evolution > wrote: > > the concern with extensions could be easily solved simply by giving > extensions access to private members of the extended type as long as those > extensions are in the same module/submodule (or file, if you prefer,

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

> On Mar 20, 2017, at 4:54 PM, Douglas Gregor via swift-evolution > wrote: > > Proposal link: > >> https://github.com/apple/swift-evolution/blob/master/proposals/0159-fix-private-access-levels.md > > • What is your evaluation of the proposal? I'm torn. During the SE-0025 review, I argue

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

> On Mar 20, 2017, at 9:12 PM, Ricardo Parada via swift-evolution > wrote: > > 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. :-) If I write `foo[instance:path.to.val

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

> On Mar 21, 2017, at 11:29 PM, Matt Whiteside via swift-evolution > wrote: > > One point which was raised by a couple of different people on this thread > (Brent Royal-Gordon, Jonathan Hull), which gave me some hesitation in voting > in favor of this proposal, is that it might make more sense

Re: [swift-evolution] Smart KeyPaths

> On Mar 22, 2017, at 9:00 AM, Vladimir.S via swift-evolution > wrote: > > bag[#path] What do these do? bag[#file] bag[#line] bag[#function] // etc. -- Brent Royal-Gordon Architechies ___ swift-evolution mailing lis

Re: [swift-evolution] Smart KeyPaths

> On Mar 22, 2017, at 11:27 AM, Matthew Johnson via swift-evolution > wrote: > > One option would be to include `get` and `set` methods on the key path types. > That would allow us to write the subscripts in the standard library (if it > is allowed to extend Any) and keep all of the magic in

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

> On Mar 22, 2017, at 3:30 AM, Rien wrote: > > I am less sanguine about the burden of proof. > > Imo there is no absolute and irrevocable proof needed to accept or reject a > change proposal. I'm sorry, I used an idiomatic phrase which may not be obvious to non-native speakers. When you say

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

> On Mar 21, 2017, at 11:03 PM, Chris Lattner via swift-evolution > wrote: > > * What is your evaluation of the proposal? I'm going to have to come down on the "no" side on this one. I'm actually not worried about methods so much as properties. KVC is completely untyped on the Objective-C sid

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

To what extent could your need for safety be satisfied by (a) giving the property a long, unique name like `unsafeUnsynchronizedT`, and (b) writing a very small unit test/shell script/Perl script which makes sure references to that very unique name only appear between the two "MARK:" comments?

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

> On Mar 25, 2017, at 12:32 AM, Jonathan Hull via swift-evolution > wrote: > > • Remove ‘private’ keyword > • Rename ‘fileprivate’ to ‘local’ with the understanding it now means > local to the containing submodule > • If no submodule is declared, the file is its own anonymous

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

> On Mar 24, 2017, at 10:09 AM, Douglas Gregor wrote: > >> I'm actually not worried about methods so much as properties. KVC is >> completely untyped on the Objective-C side, and there are several different >> mechanisms there which use KVC with poorly validated external strings, like >> bindi

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

> On Mar 25, 2017, at 6:46 AM, Jonathan Hull wrote: > >> On Mar 25, 2017, at 6:39 AM, Brent Royal-Gordon > > wrote: >> >>> On Mar 25, 2017, at 12:32 AM, Jonathan Hull via swift-evolution >>> mailto:swift-evolution@swift.org>> wrote: >>> >>> • Remove ‘private

Re: [swift-evolution] Swift null safety questions

> On Mar 23, 2017, at 9:01 AM, Joe Groff via swift-evolution > wrote: > > setjmp and longjmp do *not* work well with Swift since they need compiler > support to implement their semantics, and since Swift does not provide this > support, setjmp-ing from Swift is undefined behavior. Empirical ev

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

> On Mar 24, 2017, at 4:12 AM, Vinnie Hesener via swift-evolution > wrote: > > Why can't we just start naming access modifiers literally: a location in the > code that they apply to. Examples such as "scope" or "insidethecurlybraces" > or "file" or "module" or "submodule" or "codebase". Any of

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

> On Mar 26, 2017, at 10:43 AM, Matthew Johnson via swift-evolution > wrote: > > On Mar 26, 2017, at 10:43 AM, Xiaodi Wu > wrote: > >> This reaches the crux of the issue, doesn't it? The Swift 2 design for >> access modifiers does exactly what you reject: that desi

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

> On Mar 24, 2017, at 1:26 PM, Ankit Aggarwal via swift-evolution > wrote: > > sources: This property defines the source files to be included in the target, > relative to the target path. The default value of this property will be an > empty array, which means all valid source files found in t

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

> On Mar 26, 2017, at 9:37 PM, Charles Srstka via swift-evolution > wrote: > > For your tiny helper type, you want it to be only visible to the type it > helps. If it’s in a separate file, it has to be visible to the entire module. Would it help to put the type in a separate file, but in an ex

Re: [swift-evolution] Disallowing unreachable code

> On Mar 28, 2017, at 9:55 PM, Peter Dillinger via swift-evolution > wrote: > >>> Missing 'try' is a fatal issue? >> >> That could be argued I suppose, I was referring to unreachable code, unused >> variables, >> variables that are never mutated, etc. > > And what about non-exhaustive switch?

Re: [swift-evolution] Disallowing unreachable code

> On Mar 29, 2017, at 8:11 AM, John McCall via swift-evolution > wrote: > > I was suggesting that it would be a useful addition to the language, not that > it > necessarily needed new compiler support. Personally, what I'd like to see is for the existing <#whatever#> placeholder syntax to be

Re: [swift-evolution] Disallowing unreachable code

> On Mar 29, 2017, at 4:14 PM, Brent Royal-Gordon > wrote: > >> On Mar 29, 2017, at 8:11 AM, John McCall via swift-evolution >> mailto:swift-evolution@swift.org>> wrote: >> >> I was suggesting that it would be a useful addition to the language, not >> that it >> necessarily needed new compile

Re: [swift-evolution] Smart KeyPaths

> On Mar 29, 2017, at 4:13 PM, Michael J LeHew Jr via swift-evolution > wrote: > > Thanks for the feedback everyone! We have pushed a changed a bit ago to the > proposal reflecting these desires. > > https://github.com/apple/swift-evolution/pull/644/files >

Re: [swift-evolution] Smart KeyPaths

> On Mar 29, 2017, at 6:21 PM, Jonathan Hull via swift-evolution > wrote: > >> I would love it if we found a way to retain something as concise as that >> shorthand. I'm working on a library where users will specify a collection >> of key paths pairs. This shorthand would be a very nice piec

Re: [swift-evolution] Smart KeyPaths

> On Mar 29, 2017, at 7:05 PM, Joe Groff wrote: > > KeyPath objects themselves have properties, so key1 could be a member of > KeyPath. This doesn't seem workable. Yeah, someone pointed that out to me privately. One solution would be to make it so that an uninterrupted chain of property and

Re: [swift-evolution] [Pitch] String revision proposal #1

> On Mar 29, 2017, at 5:32 PM, Ben Cohen via swift-evolution > wrote: > > Hi Swift Evolution, > > Below is a pitch for the first part of the String revision. This covers a > number of changes that would allow the basic internals to be overhauled. > > Online version here: > https://github.com

Re: [swift-evolution] [Pitch] String revision proposal #1

> On Mar 30, 2017, at 8:38 AM, Ben Cohen via swift-evolution > wrote: > > It should definitely be Substring. My rule of thumb: if you might hyphenate > it, you can capitalize it. I was going to make the same argument, but you beat me to it. "String" and "Substring" are both terms of art. (Th

Re: [swift-evolution] [Pitch] Collection Type Element Property Observers

> On Mar 30, 2017, at 1:20 PM, Joshua Alvarado via swift-evolution > wrote: > > I think think the gain of functionality isn't there for the addition of this > functionality to be added. There are other ways to implement what you are > desiring to do without adding it to Swift language. For in

Re: [swift-evolution] [Pitch] String revision proposal #1

> On Mar 30, 2017, at 2:36 PM, Ben Cohen wrote: > > The big win for Unicode is it is short. We want to encourage people to write > their extensions on this protocol. We want people who previously extended > String to feel very comfortable extending Unicode. It also helps emphasis how > importa

Re: [swift-evolution] [Discussion] Arbitrary precision integer and float literal protocols

> On Mar 30, 2017, at 2:56 PM, David Hart via swift-evolution > wrote: > > The current protocols ExpressibleByIntegerLiteral and > ExpressibleByFloatLiteral are simple and work well but don't support > arbitrary precision literal values. Replacing those protocols is a non-goal > as they provi

Re: [swift-evolution] [Pitch] String revision proposal #1

> On Mar 30, 2017, at 2:42 PM, Ben Cohen via swift-evolution > wrote: > > (or rather, given substrings will be 2-3 words, the not-even-that-small > string optimization) Wait, if you're using the `startIndex` and `endIndex` words for the small substring optimization, how are you keeping the in

Re: [swift-evolution] Smart KeyPaths

> On Mar 31, 2017, at 3:07 AM, Haravikk via swift-evolution > wrote: > > Is it actually in-use or just reserved? Not sure I've ever needed it in the > debugger. Pop into the REPL for a minute: $ swift Welcome to Apple Swift version 3.1 (swiftlang-802.0.41 clang-802.0.36). Typ

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

> On Apr 1, 2017, at 5:56 PM, Karl Wagner via swift-evolution > wrote: > >> let isPuppyQualifier = Pet.type.equals(.dog).and(Pet.age.lessThan(12)) >> let familyQualifier = Family.pets.hasAtLeastOne(satisfying: isPuppyQualifier) >> let familiesWithPuppies = Family.fetch(editingContext, familyQua

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

> Proposal link: > https://github.com/apple/swift-evolution/blob/master/proposals/0161-key-paths.md > • What is your evaluation of the proposal? I continue to believe that the chosen syntax is unnecessarily cumbersome, that the design is overly conservative in terms of making sure people

Re: [swift-evolution] [Review] SE-0155: Normalize Enum Case Representation

> On Apr 2, 2017, at 11:17 PM, Daniel Duan via swift-evolution > wrote: > >> On Apr 2, 2017, at 11:10 PM, Xiaodi Wu > > wrote: >> >> This rule cannot hold. You cannot have the shorthand syntax you propose, >> disallow mixing of shorthand syntax and the longer form,

Re: [swift-evolution] [Discussion] Arbitrary precision integer and float literal protocols

> On Apr 2, 2017, at 11:19 PM, David Hart wrote: > > Any reason we need to burden ourselves with the two's complement > representation? The `words` collection and its two's-complement representation come straight out of the `BinaryInteger` protocol; all integer types already "speak" in variab

Re: [swift-evolution] [Discussion] Arbitrary precision integer and float literal protocols

> On Mar 31, 2017, at 10:08 AM, Xiaodi Wu wrote: > > (This would leave non-binary floats in the lurch, but we're pretty much doing > that already—try initializing `Decimal` through its > `ExpressibleByFloatLiteral` conformance sometime and you'll see what I mean. > I would support changing its

Re: [swift-evolution] Type-based ‘private’ access within a file

> On Apr 3, 2017, at 2:19 PM, John McCall via swift-evolution > wrote: > >> Won’t making big modifications later be even more problematic than now, in >> the name of source stability? > > Yes. Big changes along these lines will not be considered later. At best, > it would be possible to "re

Re: [swift-evolution] Type-based ‘private’ access within a file

> On Apr 3, 2017, at 2:54 PM, Vladimir.S via swift-evolution > wrote: > > Moreover, I think that we need *additional* access level(to current > 'private'), which will mean 'can be accessed from extensions and subtypes in > the same *module*' to be able to split type's conformances to number of

Re: [swift-evolution] Type-based ‘private’ access within a file

> On Apr 3, 2017, at 3:07 PM, David Hart wrote: > >> On 3 Apr 2017, at 23:55, Brent Royal-Gordon > > wrote: >> >> If that's the case, I don't think we should change the definition of >> `private` to something so unproven, and which violates our access control >>

Re: [swift-evolution] Type-based ‘private’ access within a file

> On Apr 3, 2017, at 3:51 PM, Vladimir.S wrote: > >>> Moreover, I think that we need *additional* access level(to current >>> 'private'), which will mean 'can be accessed from extensions and subtypes >>> in the same *module*' to be able to split type's conformances to number >>> of files and don'

Re: [swift-evolution] [Proposal] Foundation Swift Encoders

> On Apr 3, 2017, at 1:31 PM, Itai Ferber via swift-evolution > wrote: > Hi everyone, > > With feedback from swift-evolution and additional internal review, we've > pushed updates to this proposal, and to the Swift Archival & Serialization > proposal. > Changes to here mostly mirror the ones m

Re: [swift-evolution] [Proposal] Foundation Swift Encoders

> On Apr 4, 2017, at 2:43 PM, Itai Ferber wrote: > I like the separation between keyed and unkeyed containers (and I think > "unkeyed" is a good name, though not perfect), but I'm not quite happy with > the unkeyed container API. Encoding a value into an unkeyed container appends > it to the co

Re: [swift-evolution] Type-based ‘private’ access within a file

> On Apr 4, 2017, at 12:30 PM, David Hart via swift-evolution > wrote: > >> And it throws out a major use-case of scope-based access, which is to ensure >> that invariants are only touched in specific places. > > Is still retains most use-cases that private procured. The only capability > tha

Re: [swift-evolution] Type-based ‘private’ access within a file

> On Apr 4, 2017, at 6:45 PM, Brent Royal-Gordon wrote: > > Access control is a tar pit; let's not drown in it. Amending this: The precise boundaries of lower-than-`fileprivate` levels of access control—what we're discussing here—are a tar pit. There are gains to be made by removing an access

Re: [swift-evolution] [Proposal] Foundation Swift Encoders

> On Apr 4, 2017, at 7:37 PM, Ben Rimmington via swift-evolution > wrote: > >> On 4 Apr 2017, at 22:43, Itai Ferber wrote: >> >>> On 4 Apr 2017, at 1:57, Brent Royal-Gordon wrote: >>> >>> I like the separation between keyed and unkeyed containers (and I think >>> "unkeyed" is a good name, tho

Re: [swift-evolution] [Proposal] Foundation Swift Encoders

> On Apr 5, 2017, at 1:44 PM, David Hart via swift-evolution > wrote: > >>> For the same reasons, I continue to believe that decode functions should >>> overload on the return type. If we follow the arguments in favor of >>> providing a type argument, then why don't we also have type arguments

Re: [swift-evolution] Type-based ‘private’ access within a file

> On Apr 5, 2017, at 2:27 PM, Tony Arnold via swift-evolution > wrote: > > I know Swift has different purposes for different people here, but ultimately > it’s supposed to support great application development for Apple’s platforms, > right? To my eyes, `fileprivate` should never have been int

Re: [swift-evolution] [Pitch] String revision proposal #1

> On Apr 5, 2017, at 12:16 PM, Ben Cohen wrote: > > The idea is, if you don’t want to make repairs, you use the transcoding > primitives instead. The belief is that the old non-repairing versions (return > nil if repairs needed) weren’t useful. Yes—I was asking about the transcoding primitives

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

> Proposal link: > > https://github.com/apple/swift-evolution/blob/master/proposals/0161-key-paths.md > > > Reply text > Other replies > >

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

> On Apr 5, 2017, at 6:41 PM, Brent Royal-Gordon wrote: > > I don't adore the `\` syntax because I don't quite see the underlying logic > of that symbol, but it's a *massive* improvement over the old `#keyPath(Type, > .path)` mess, and in all other respects I remain extremely positive on this

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

> On Apr 5, 2017, at 5:45 PM, Ben Cohen via swift-evolution > wrote: > > • What is your evaluation of the proposal? (As a meta issue, I'm not sure I like the grab-bag review style; I'm finding this proposal a little bit difficult to navigate.) Sequence-based initializer and merging init

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

> On Apr 6, 2017, at 2:39 PM, Joe Groff via swift-evolution > wrote: > > for key in [\Vector.x, \.y, \.z, \.w] { > a[key] += b[key] > } Sorry to derail slightly, but I'd love to see a key path type shorthand—perhaps something like: for key: \Vector: Int in [\.x, \.y, \.z, \.w] {

Re: [swift-evolution] Type-based ‘private’ access within a file

> On Apr 6, 2017, at 11:17 AM, Jordan Rose via swift-evolution > wrote: > > Neither, unfortunately. We accepted SE-0025, though I wish we hadn't; we > named the two levels "private" and "fileprivate", though I wish we hadn't; > and now there is lots of existing code relying on that, and it wou

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0169: Improve Interaction Between private Declarations and Extensions

Proposal link: > https://github.com/apple/swift-evolution/blob/master/proposals/0169-improve-interaction-between-private-declarations-and-extensions.md > On Apr 6, 2017, at 4:10 PM, Douglas Gregor wrote: > > What is your evaluation of the proposal? This proposal is actively harmful. It will pu

Re: [swift-evolution] [Review] SE-0169: Improve Interaction Between private Declarations and Extensions

> On Apr 6, 2017, at 5:38 PM, Charles Srstka via swift-evolution > wrote: > >> On Apr 6, 2017, at 7:34 PM, Xiaodi Wu via swift-evolution >> mailto:swift-evolution@swift.org>> wrote: >> >> `private` works for extensions exactly how the authors of SE-0025 intended >> it to do. Your comments do

Re: [swift-evolution] [Proposal] Foundation Swift Encoders

(If you'd like any further discussion to move over to the review thread, please let me know.) > On Apr 5, 2017, at 9:08 PM, Itai Ferber wrote: >>> In terms of an equivalent to encode(contentsOf:), keep in mind that this >>> would only work if the collection you're decoding is homogeneous, in wh

Re: [swift-evolution] [Review] SE-0169: Improve Interaction Between private Declarations and Extensions

> On Apr 7, 2017, at 12:56 AM, Jean-Daniel wrote: > >> Even though I think we were better off without scoped `private`, I *have* >> used it fruitfully on several occasions. These were typically in places >> where I wanted to restrict access to a small number of members which I could >> ensure

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

> On Apr 7, 2017, at 2:15 PM, Félix Cloutier via swift-evolution > wrote: > > I don't necessarily think that the concept is a bad idea, but I think that > the interaction of Swift features facilitates poor coding decisions. For > example, the proposal interpolates an `author` variable straight

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

https://github.com/apple/swift-evolution/blob/master/proposals/0168-multi-line-string-literals.md First of all, to be clear: although my name is on this proposal, it's there because I worked on i

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

> On Apr 6, 2017, at 11:01 AM, Brad Hilton via swift-evolution > wrote: > > How about Person.name.get / Person.name.set for getter/setter references. We don't really want getter/setter references; we want one instance which represents the whole property and (if writable) can be used to modify

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

> On Apr 7, 2017, at 12:21 AM, Daniel Duan via swift-evolution > wrote: > > The cons for doing this are obvious too: the inference makes the language > feels more friendly and is, undoubtedly, a beloved feature for many. This > would be a source breaking change. Beyond just being more friend

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

> On Apr 6, 2017, at 9:51 AM, Nate Cook wrote: > > Thanks for all your feedback, Brent! One note on this item in particular—if > you specify a default argument for a throws/rethrows closure, you have to use > "try" at the call site even if the default closure argument doesn't throw. > Modules

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

> On Feb 22, 2017, at 12:24 PM, Jacob Bandes-Storch via swift-evolution > wrote: > > There were some opinions on Slack that we should simply change `foo` so that > it can *only* refer to the nullary version. I think this is the right solution. Eventually we want to get to the point where para

Re: [swift-evolution] [pitch] Adding in-place removeAll to the std lib

> On Apr 8, 2017, at 12:44 PM, Xiaodi Wu via swift-evolution > wrote: > > +1. Perfect. Let's not bikeshed this and get it done! Sorry, I'm going to have to insist on bikeshedding. `equalTo:` is kind of ugly and has no precedent in the standard library. Similar APIs seem to either leave the p

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

> On Apr 8, 2017, at 9:12 PM, Tony Allevato via swift-evolution > wrote: > > `\(Foo.bar)` looks like it would try to evaluate `Foo.bar` first and then > compute the "keypath" of that, which doesn't make sense, whereas `(\Foo.bar)` > makes it clear that the keypath expression is being separated

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

> On Apr 9, 2017, at 9:29 AM, John Holdsworth via swift-evolution > wrote: > > Perhaps we can find common ground on 1) and 2) and even 3) with a view to > resubmitting if there is time. Seems mostly like we just need to discuss the > delimiter further and decide whether the indent trimming is

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

> On Apr 9, 2017, at 8:46 PM, Félix Cloutier wrote: > > For XML, I know that you have this XMLString idea, but I think that it would > be very complex to implement in practice. XML has several different contexts > in which escaping has to be different. For instance, you shouldn't escape the >

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

Sorry, I realized I had a little more to say about this. > On Apr 9, 2017, at 8:46 PM, Félix Cloutier wrote: > > C# was able to eliminate the whole class of SQL injections by introducing a > convenient and powerful syntax for queries that is not string-based. I think > that Swift should be mov

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0166: Swift Archival & Serialization

> On Apr 6, 2017, at 11:10 AM, Douglas Gregor wrote: > > Proposal link: > > https://github.com/apple/swift-evolution/blob/master/proposals/0166-swift-archival-serialization.md > > > What is y

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

> On Apr 11, 2017, at 7:33 AM, Vladimir.S via swift-evolution > wrote: > > 2. Seems like a mistake: > "Multi-line string with indentation stripping prevented by whitespace before > leading newline" > > """↵ > Hello↵ > world!""" > > Creates a string with: > > ↵ > Hello↵ >

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

> On Apr 11, 2017, at 7:33 AM, Vladimir.S via swift-evolution > wrote: > > 1. "Tripled string literals support backslash escapes and interpolation as > normal, except that you can also place a backslash immediately before a > newline. This indicates that the newline is merely for code formatti

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

> On Apr 11, 2017, at 8:08 AM, Adrian Zubarev via swift-evolution > wrote: > > That’s also the example that kept me thinking for a while. > > Overall the proposal is a great compromise to some issues I had with the > first version. However I have a few more questions: > > Why can’t we make i

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

> On Apr 11, 2017, at 4:52 PM, Ricardo Parada via swift-evolution > wrote: > > I think the enabling of the indentation stripping could be relaxed a little > bit and not require the opening delimiter to end its line. So for example, > it would be possible to do this: > > > let xml = """ >

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

Hey folks, We've revised the proposal again. The main difference: You no longer need an initial newline to enable indentation stripping, and stripping no longer removes that newline even if it is present. (Adrian Zubarev and I believe some others argued for this.) We disagreed with this at fir

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

> On Apr 12, 2017, at 5:59 AM, Tony Allevato via swift-evolution > wrote: > > I also would oppose comments inside multi-line strings because one place I > imagine using it is in Swift code generation and I also want to generate > comments, and it seems pointless to have to escape those. I ac

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

Wow, maybe I shouldn't have slept. Okay, let's deal with trailing newline first. I'm *very* confident that trailing newlines should be kept by default. This opinion comes from lots of practical experience with multiline string features in other languages. In practice, if you're generating files

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

> On Apr 12, 2017, at 11:58 AM, Jarod Long via swift-evolution > wrote: > > On a separate note, I'd like to bring up the de-indentation behavior I > described earlier again. I still feel that having the position of the closing > delimiter determine how much whitespace is de-indented is not ver

Re: [swift-evolution] [Review] SE-0166: Swift Archival & Serialization

> On Apr 12, 2017, at 11:44 AM, Russ Bishop via swift-evolution > wrote: > > * String and Int keys being optional, giving a CodingKey the opportunity to > return nil for both at runtime. This was true in the first public draft, but I believe in this version `stringValue` is no longer Optional

Re: [swift-evolution] [Review] SE-0166: Swift Archival & Serialization

> On Apr 12, 2017, at 2:12 PM, Zach Waldowski via swift-evolution > wrote: > > I want to disagree with this is strongly as possible lest it influence > the proposal in any way whatsoever. Just because you can solve something > through reflection doesn't mean you should. Cosigned. Reflection is

Re: [swift-evolution] [Review] SE-0166: Swift Archival & Serialization

> On Apr 12, 2017, at 6:18 PM, Russ Bishop wrote: > >> >> On Apr 12, 2017, at 5:44 PM, Brent Royal-Gordon > > wrote: >> >>> On Apr 12, 2017, at 11:44 AM, Russ Bishop via swift-evolution >>> mailto:swift-evolution@swift.org>> wrote: >>> >>> * String and Int keys

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0169: Improve Interaction Between private Declarations and Extensions

> On Apr 11, 2017, at 10:39 PM, Chris Lattner via swift-evolution > wrote: > > However, as of the core team meeting last week, it became clear that the > priority of maintaining source stability (and thus, not massively thrashing > source files in the 3->4 conversion) is an overriding concern.

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

> On Apr 12, 2017, at 5:39 PM, Xiaodi Wu wrote: > > On Wed, Apr 12, 2017 at 5:20 PM, Brent Royal-Gordon > wrote: > Wow, maybe I shouldn't have slept. > > Okay, let's deal with trailing newline first. I'm *very* confident that > trailing newlines should be kept by

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

> On Apr 13, 2017, at 5:35 AM, Ricardo Parada via swift-evolution > wrote: > > Take a look at Brent's revised proposal.I personally thin it is perfect. > Take a look: > > https://github.com/johnno1962a/swift-evolution/blob/master/proposals/0168-multi-line-string-literals.md > >

Re: [swift-evolution] [Pitch] Adding safety to arrays

> On Apr 13, 2017, at 9:18 AM, David Sweeris via swift-evolution > wrote: > > In any case, given that we're discussing a "safe subscript", we need a way to > differentiate the safe subscript from the unsafe subscript. The only two ways > to do that are to either add an argument label or change

Re: [swift-evolution] Proposal: Split extensions into implementing methods and adding static functions Was: [swift-evolution-announce] [Review] SE-0164: Remove final support in protocol extensions

> On Apr 13, 2017, at 3:10 PM, Howard Lovatt via swift-evolution > wrote: > > I don't see that retroactive conformance needs to be exportable. If it is > exported then you cannot prevent clashes from two modules, this is a known > problem in C#. Because of this and other problems with C# exten

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

> On Apr 13, 2017, at 4:48 PM, Xiaodi Wu wrote: > > You say "this is the example set by `print`", but I don't think anything else > actually *follows* that example. No other I/O operation in Swift behaves this > way. > > To be more accurate, it's not `print` that specifies this behavior, but

Re: [swift-evolution] [pitch] One-sided Ranges

> On Apr 13, 2017, at 7:29 PM, Félix Cloutier via swift-evolution > wrote: > > template > void foo(T... args) > { > return bar(args...); > } > > In this bad but simple example, bar is called with the same* parameters as > foo. Parameter unpacking uses the postfix … operator. > > * To so

Re: [swift-evolution] And another access control idea

> On Apr 15, 2017, at 2:01 AM, Manolo van Ee via swift-evolution > wrote: > > Hi All, > > I’ve been following the access control discussion a little and I had an idea > that I wanted to throw out here. I know it’s too late and the idea doesn’t > provide source compatibility, but it seemed wor

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0172: One-sided Ranges

> On Apr 19, 2017, at 12:10 PM, Paweł Wojtkowiak via swift-evolution > wrote: > > Maybe writing s[s.startIndex.. classA.structB.stringC[classA.structB.stringC.startIndex.. beautiful or easy to read at all, and sometimes it can get really complex. Of > course, you can assign these to variables f

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

> On Apr 19, 2017, at 3:18 PM, Xiaodi Wu via swift-evolution > wrote: > > Other common tools like Git already flag trailing whitespace by default, so > even if Swift doesn't warn about it, you might still need to satisfy other > tools in your pipeline. > > Isn't that an equally good argument

Re: [swift-evolution] [Review] SE-0172: One-sided Ranges

I would add that I expect variadic generics to be used less often than one-sided ranges, and also to be a more complex and advanced feature. Both of these suggest that one-sided ranges deserve the simpler, friendlier syntax. -- Brent Royal-Gordon Sent from my iPhone > On Apr 20, 2017, at 4:38

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0166: Swift Archival & Serialization

> On Apr 20, 2017, at 10:08 AM, Tony Parker via swift-evolution > wrote: > > * The above will allow those protocols, plus Encodable, Decodable, typealias > Codable, Encoder, Decoder, CodingKey, struct CodingUserInfoKey to be part of > the standard library (not in Foundation), resolving the co

  1   2   3   4   5   6   7   8   9   10   >