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

[Brent Royal-Gordon via swift-evolution]

> 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 
>>> > 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.
> 
> You are correct; I still don't like the fact that you can be in an unkeyed 
> archiver situation and hitting CodingKey adopters that don't provide integer 
> keys. 

You are building this dislike on top of several misconceptions:

* There are no "keyed archivers" and "unkeyed archivers". There are keyed and 
unkeyed *containers*, and all coders handle both kinds.

* Unkeyed containers don't use keys at all, so this has nothing to do with 
keyed vs. unkeyed. Unkeyed containers are for storing a series of values with 
no inherent structure to them, only an order. Array elements and tuples are 
good examples. (But of course, you'd just encode the array as a whole into an 
entry in a keyed container and the array itself would create an unkeyed 
container and put its elements into it.)

* Integer keys are a space-efficient alternative to identifying keys by string 
value; they give supporting coders a fixed-width value they can use to 
represent a key. But they don't need to be contiguous and they don't 
necessarily have any influence on the order that values are encoded in. As long 
as you don't change an existing field's integerValue or reuse an integerValue 
previously assigned to a different key, there should be no versioning problems.

>>> * Encoder has three functions, but only one may ever be called. This API is 
>>> the opposite of "pit of success".
>> 
>> Personally, I'm worried about that too. But I had a lot of trouble coming up 
>> with an alternative that didn't violate a more important goal, like "being 
>> able to throw errors" or "being compatible with classes".
>> 
>> Last-ditch suggestion: Change a bunch of names so that, for instance, 
>> `Encoder` is instead `EncodingContainerizer`. (That's a terrible name, but 
>> "Factory" gives me the hives.) That way, the name of the type gives you a 
>> hint that you're supposed to use it to make a container. You might even 
>> rename the methods to e.g. `useContainer(keyedBy:)`, which sound a little 
>> more stateful and mutually-exclusive.
>> 
>>  func encode(to encoder: EncodingContainerizer) throws {
>>  var container = encoder.useContainer(keyedBy: CodingKeys.self)
>>  try container.encode(name, forKey: .name)
>>  try container.encode(birthDate, forKey: .birthDate)
>>  }
> 
> We could just completely separate the idea of keyed and unkeyed encoding?

As I said, I think you misunderstand what these things are for.

I would like, though, to have the type declare the kind of container it wants. 
In a previous thread, I suggested that `encode(to:)` should take a container 
directly, and we should construct it for them:

func encode(to container: KeyedEncodingContainer) throws {
try container.encode(name, forKey: .name)
try container.encode(birthDate, forKey: .birthDate)
}

The authors pointed out that this would require you to make the `CodingKeys` 
type public and would mean that subclasses couldn't switch container types. 
These really are important problems with any idea of that sort.

>> I argued about this pretty vigorously. They want to avoid the overhead of 
>> building an encoder and single-value container and then making several 
>> generic calls to encode the value into the container. Personally, I think 
>> this is premature optimization of the highest order—particularly since 
>> building an encoder and single-value container are often no-ops—but this is 
>> the design they chose, and I don't think it's worth rejecting for that alone.
> 
> Has someone done performance tests to validate that this is an issue? If 
> nothing else this seems like an implementation detail a conforming type could 
> opt to provide but it shouldn't be required in every implementation.

I don't know what testing they've done, but this is not something that 
individual coders could add after the fact. `encode(to:)` and `init(from:)` are 
passed only protocol existentials containing the coder, so they don't have 
access to any member that isn't in the protocol. The same for containers. 
Accessing any special, coder-specific methods would perhaps not be impossible, 
but it'd be prohibitively difficult. So if any coders want to have this fast 
path, it needs to be part of the protocol ahead of time; it can't be bolted on 
by only the conforming types that want it.

>> I think they've done a 

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

[Brent Royal-Gordon via swift-evolution]

> 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 really cool, but it's generally going to be the 
least-efficient, most-buggy possible way to implement a given feature. There's 
something to be said for just...writing some code. Especially when the computer 
is writing it for you.

-- 
Brent Royal-Gordon
Architechies

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

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

[Jon Shier via swift-evolution]

> What is your evaluation of the proposal?
-1. Like I said in my review of 167, this sort of core API is far too important 
for the implementation to be so flawed.

* This proposal is extensive. An implementation playground would’ve been nice. 
Containers seem fairly odd, so it would’ve been nice to see how they feel in 
use.

* Like 167, this proposal feels very Objective-C like. While we want 
interoperability with NSCoder and NSKeyedArchiver, this should be a native 
Swift solution first and a bridge second. Also, some bits of the API aren’t 
Swifty; any API which uses Type.self just doesn’t feel right. Please, use the 
generics. 

someString = try container.decode(forKey: .someString) can infer the type from 
the assignee, no?

* This sort of API works well when the responses are logically formed, but this 
also forms the basis of the APIs we’ll be using to interact with JSON, which 
can be anything but logically formed. For instance:

struct Veritas {
let truth: Bool
} 

Simple, right?

But say it’s JSON representation is this:

{ “some_Bad_key” : “Yes” }

How would this proposal let me transform a Yes string into the proper boolean 
value? There doesn’t seem to be a solution provided, just the brute force 
method of trying to decode as a string first and then transforming. Plus, if I 
have a single value that I need to do something custom to, I need implement 
init(from decoder:) for my entire type, so it becomes very painful very 
quickly. I foresee a new collection of open source libraries to remedy this 
shortcoming, and they really shouldn’t have to.

Also, what if I wanted to be able to decode this type from both the terrible 
JSON and a nice on disk format? Some way to provide multiple conforming 
initializers would be nice.

Suffice to say my biggest concern here is that this API is designed for the 
ideal and not the messy reality of JSON APIs created by the lowest bidder. 
Since this proposal is supposed to cover both, it needs to offer support for 
the worst case scenarios more easily.

* The errors generated just aren’t good. I covered this in more detail in my 
review of 167, but suffice it to say they’re too limited by the desire to 
bridge them to NSErrors and don’t capture any useful details about what caused 
them in the first place. Also, they shouldn’t live in Foundation, as this is a 
feature the standard library will implement. 

> Is the problem being addressed significant enough to warrant a change to 
> Swift?
Yes, this is a problem worth solving, I just don’t think this proposal is good 
enough.

> Does this proposal fit well with the feel and direction of Swift?
No. Passing types around isn’t Swifty at all. This fits right in in Objective-C 
though.

> If you have used other languages or libraries with a similar feature, how do 
> you feel that this proposal compares to those?
I’ve been an Argo user for 2 years, so I’m used to a certain terseness and 
flexibility in my decoders. This proposal brings neither. Argo also has 
superior errors which capture the keys and types that caused an issue. I 
guarantee there will be at least one open source library which provides 
operators that wrap this proposal’s API so that you can properly transform 
decoded values without multiple lines of code.

> How much effort did you put into your review? A glance, a quick reading, or 
> an in-depth study?
Multiple read throughs, about an hour of analysis. 



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

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

[Félix Cloutier via swift-evolution]

I don't have a strong opinion; are we sure enough that this is what we want the 
postfix operator … to be for? For instance, C++ uses it a lot with variadic 
templates.

> Le 12 avr. 2017 à 13:21, David Hart via swift-evolution 
>  a écrit :
> 
> I remember being against this feature when it was first discussed long ago. 
> But I’ve since appreciated how elegant it is. I also like the i… was chosen 
> instead of i..<
> 
> I guess Range would be a better name for the generic protocol to represent 
> all ranges. But its too late for that now. Correct?
> 
>> On 12 Apr 2017, at 18:40, Ben Cohen via swift-evolution 
>> > wrote:
>> 
>> Hi Swift community,
>> 
>> Another proposal pitch. These operators were mentioned briefly in the String 
>> manifesto as prefixing/suffixing is very common with strings.
>> 
>> Online copy here: 
>> https://github.com/airspeedswift/swift-evolution/blob/71b819d30676c44234bac1aa61fc5c39bcf3/proposals/-OneSidedRanges.md
>>  
>> 
>> One-sided Ranges
>> 
>> Proposal: SE- 
>> 
>> Authors: Ben Cohen , Dave Abrahams 
>> , Brent Royal-Gordon 
>> 
>> Review Manager: TBD
>> Status: Awaiting review
>> Introduction
>> 
>> This proposal introduces the concept of a “one-sided” range, created via 
>> prefix/postfix versions of the existing range operators.
>> 
>> It also introduces a new protocol, RangeExpression, to simplify the creation 
>> of methods that take different kinds of ranges.
>> 
>> Motivation
>> 
>> It is common, given an index into a collection, to want a slice up to or 
>> from that index versus the start/end.
>> 
>> For example (assuming String is once more a Collection):
>> 
>> let s = "Hello, World!"
>> let i = s.index(where: ",")
>> let greeting = s[s.startIndex..> When performing lots of slicing like this, the verbosity of repeating 
>> s.startIndex is tiresome to write and harmful to readability.
>> 
>> Swift 3’s solution to this is a family of methods:
>> 
>> let greeting = s.prefix(upTo: i)
>> let withComma = s.prefix(through: i)
>> let location = s.suffix(from: i)
>> The two very different-looking ways to perform a similar task is jarring. 
>> And as methods, the result cannot be used as an l-value.
>> 
>> A variant of the one-sided slicing syntax found in Python (i.e. s[i:]) is 
>> proposed to resolve this.
>> 
>> Proposed solution
>> 
>> Introduce a one-sided range syntax, where the “missing” side is inferred to 
>> be the start/end:
>> 
>> // half-open right-handed range
>> let greeting = s[..> // closed right-handed range
>> let withComma = s[...i]
>> // left-handed range (no need for half-open variant)
>> let location = s[i...]
>> Additionally, when the index is a countable type, i... should form a 
>> Sequence that counts up from i indefinitely. This is useful in forming 
>> variants of Sequence.enumerated() when you either want them non-zero-based 
>> i.e. zip(1..., greeting), or want to flip the order i.e. zip(greeting, 0...).
>> 
>> This syntax would supercede the existing prefix and suffix operations that 
>> take indices, which will be deprecated in a later release. Note that the 
>> versions that take distances are not covered by this proposal, and would 
>> remain.
>> 
>> This will require the introduction of new range types (e.g. 
>> PartialRangeThrough). There are already multiple range types (e.g. 
>> ClosedRange, CountableHalfOpenRange), which require overloads to allow them 
>> to be used whereever a Range can be.
>> 
>> To unify these different range types, a new protocol, RangeExpression will 
>> be created and all ranges conformed to it. Existing overloads taking 
>> concrete types other than Range can then be replaced with a single generic 
>> method that takes a RangeExpression, converts it to a Range, and then 
>> forward the method on.
>> 
>> A generic version of ~= will also be implemented for all range expressions:
>> 
>> switch i {
>> case 9001...: print("It’s over NINE THOUSAAAND")
>> default: print("There's no way that can be right!")
>> }
>> The existing concrete overloads that take ranges other than Range will be 
>> deprecated in favor of generic ones that take a RangeExpression.
>> 
>> Detailed design
>> 
>> Add the following to the standard library:
>> 
>> (a fuller work-in-progress implementation can be found here: 
>> https://github.com/apple/swift/pull/8710 
>> )
>> 
>> NOTE: The following is subject to change depending on pending compiler 
>> features. Methods may actually be on underscored protocols, and then moved 
>> once recursive protocols are implemented. Types may be collapsed using 
>> conditional conformance. This should not matter from a usage 

Re: [swift-evolution] [Review] SE-0167: Swift Encoders

[Jon Shier via swift-evolution]

> What is your evaluation of the proposal?
-1. There is a lot good here, but this feature is too important to let an 
“okay” proposal through.

* Usage of the API doesn’t feel very Swifty, unless I’m missing some intended 
use case. Why are the encoders / decoders classes? Why do they have mutable 
properties? What is the userInfo value for? It all feels very reminiscent of 
the NSFormatter APIs, which isn’t really a good thing. This is supposed to be 
the Swift native way to encode and decode types, so it should feel native. It’s 
close in a lot of ways (I like the strategies enums) but isn’t really there. 

* This is more for 166, but decode(MyValue.self)? Gross. Use the generic to 
convey the type inside the API.

* This proposal fails to make full usage of the Swift’s error capabilities and 
the errors live in the wrong place. I’m putting this here since this proposal 
defines the errors but really they should be part of 166. These error types are 
inferior to the errors we can produce in Swift right now. They should be Swift 
native errors first and bridged into NSError second, not created with the 
primary intent to be bridged. For example:

public static var coderTypeMismatch: CocoaError.Code

First off, the coder* prefix is unnecessary if this is properly moved into its 
own concrete error type. Second, it doesn’t capture the mismatch values, 
leading to unnecessary debugging overhead. Make the error a proper enum that 
can capture the type found and type expected and it becomes far more useful. 
For example (roughly):

public enum DecoderError: Error {
typeMismatch(expected:actual:)
readCorrupt(underlyingError: Error) // presumably this wraps the underlying 
serialization error?
valueNotFound(forKey: Key)
}

Also, these errors should live in the standard library, otherwise how are 
native types going do their own encoding/decoding without importing Foundation. 
Again, this is more for 166, but they were defined here, so… I understand the 
need to perhaps bridge them to existing errors (I don’t think it’s necessary, 
but I understand the desire), but that should be done under the covers, so to 
speak, and not exposed to Swift developers by limiting a core API so badly. 
Besides, the errors you want to bridge to aren’t very good in the first place. 
"The data couldn't be read because it isn't in the correct format.” Seriously? 
Could we get a little more detail, please?

* There is nothing proposed to add any type safety to the decoding process. We 
know exactly what types can exist in JSON. Why are we still representing it as 
Any or the raw Data? Providing greater safety during the decoding process helps 
developers find what’s wrong faster.

> Is the problem being addressed significant enough to warrant a change to 
> Swift?
Yes, we need native decoding and encoding of common formats like JSON, but I 
don’t believe this solution is good enough.

> Does this proposal fit well with the feel and direction of Swift?
No, this feels like a port of an Objective-C API, and it literally is in some 
ways.

> If you have used other languages or libraries with a similar feature, how do 
> you feel that this proposal compares to those?
I’ve been using Argo for 2 years now. While much of the comparison is more 
relevant to 166, I think it’s still a great example of what a Swift native 
decoding experience should look like. It’s especially superior in the errors it 
produces.

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

Fairly in depth I’d say.



Jon Shier

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

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

[Robert Bennett via swift-evolution]

+1, very nice proposal. I think there was some discussion about this before, 
glad to see it being fleshed out into a full proposal. My only nitpick is that 
I think feel like the syntax `sequence[i…]` is awkward because `…` implies the 
entirety of a range (1…5 includes 1 and 5 and everything in between), but the 
valid indices of a sequence go from 0 to endIndex, and endIndex cannot be 
included when slicing. That is, `sequence[i…]` is equivalent to 
`sequence[i..

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

[Ricardo Parada via swift-evolution]

On Apr 12, 2017, at 6:20 PM, Brent Royal-Gordon via swift-evolution 
> wrote:

> Wow, maybe I shouldn't have slept.

LOL. 

My thoughts so far:

• If and only if the opening """ is followed by a newline then strip it.
• Don't strip the trailing newline.

Example:

print( """
Usage: myapp 

Run myapp to do mything

Options:
-myoption - an option
""" )

Additionally, allow the string to start immediately after the opening """.  In 
this scenario the indentation stripping is performed starting with the second 
line:

case .isExprSameType(let from, let to):
return """checking a value with optional type \(from) \
  against dynamic type \(to) \
  succeeds whenever the value is non-'nil'; \
  did you mean to use '!= nil'?\
  """

And definitely something like this too:

let html = ""

Again, the string literal is allowed to start immediately after the opening 
""".  And No newline stripping is required here because the closing """ is not 
on a line by itself.


> 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 in a line-oriented way, you're usually 
> generating them a line at a time. It's pretty rare that you want to generate 
> half a line and then add more to it in another statement; it's more likely 
> you'll interpolate the data. I'm not saying it doesn't happen, of course, but 
> it happens a lot less often than you would think just sitting by the fire, 
> drinking whiskey and musing over strings.
> 
> I know that, if you're pushing for this feature, it's not satisfying to have 
> the answer be "trust me, it's not what you want". But trust me, it's not what 
> you want.
> 
> Moving to the other end, I think we could do a leading newline strip *if* 
> we're willing to create multiline and non-multiline modes—that is, newlines 
> are _not allowed at all_ unless the opening delimiter ends its line and the 
> closing delimiter starts its line (modulo indentation). But I'm reluctant to 
> do that because, well, it's weird and complicated. I also get the feeling 
> that, if there's a single-line mode and a multi-line mode, we ought to treat 
> them as truly orthogonal features and allow `"`-delimited strings to use 
> multi-line mode, but I'm really not convinced that's a good idea.
> 
> (Note, by the way, that heredocs—a *really* common multiline string 
> design—always strip the leading newline but not the trailing one.)
> 
> Adrian cited this example, where I agree that you really don't want the 
> string to be on the same line as the leading delimiter:
> 
>   let myReallyLongXMLConstantName = """
>
>   
>  John Doe
>  XML Developer's 
> Guide
>  Computer
>  44.95
>   
>\
>"""
> 
> But there are lots of places where it works fine. Is there a good reason to 
> force an additional newline in this?
> 
>   case .isExprSameType(let from, let to):
>   return """checking a value with optional type 
> \(from) against dynamic type \(to) \
> succeeds whenever the value is 
> non-'nil'; did you mean to use '!= nil'?\
> """
> 
> I mean, we certainly could, but I'm not convinced we should. At least, not 
> yet.
> 
> In any case, trailing newline definitely stays. Leading newline, I'm still 
> thinking about.
> 
> As for other things:
> 
> * I see zero reason to fiddle with trailing whitespace. If it's there, it 
> might be significant or it might not be. If we strip it by default and we 
> shouldn't, the developer has no way to protect it. Let's trust the developer. 
> (And their tooling—Xcode, I believe Git, and most linters already have 
> trailing whitespace features. We don't need them too.)
> 
> * Somebody asked about `"""`-delimited heredocs. I think it's a pretty 
> syntax, but it's not compatible with single-line use of `"""`, and I think 
> that's probably more important. We can always add heredocs in another way if 
> we decide we want them. (I think `#to(END)` is another very Swifty syntax we 
> could use for heredocs--less lightweight, but it gives us a Google-able 
> 

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

[Russ Bishop via swift-evolution]

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

You are correct; I still don't like the fact that you can be in an unkeyed 
archiver situation and hitting CodingKey adopters that don't provide integer 
keys. 

> 
>> * Encoder has three functions, but only one may ever be called. This API is 
>> the opposite of "pit of success".
> 
> Personally, I'm worried about that too. But I had a lot of trouble coming up 
> with an alternative that didn't violate a more important goal, like "being 
> able to throw errors" or "being compatible with classes".
> 
> Last-ditch suggestion: Change a bunch of names so that, for instance, 
> `Encoder` is instead `EncodingContainerizer`. (That's a terrible name, but 
> "Factory" gives me the hives.) That way, the name of the type gives you a 
> hint that you're supposed to use it to make a container. You might even 
> rename the methods to e.g. `useContainer(keyedBy:)`, which sound a little 
> more stateful and mutually-exclusive.
> 
>   func encode(to encoder: EncodingContainerizer) throws {
>   var container = encoder.useContainer(keyedBy: CodingKeys.self)
>   try container.encode(name, forKey: .name)
>   try container.encode(birthDate, forKey: .birthDate)
>   }

We could just completely separate the idea of keyed and unkeyed encoding?

You may be right that the downsides make an alternative design untenable.


> 
>> I don't understand why KeyedEncodingContainer needs all those overloads; 
>> automatic conformance to Encodable should be provided for the stdlib types 
>> in those overloads so why would they be necessary?
> 
> I argued about this pretty vigorously. They want to avoid the overhead of 
> building an encoder and single-value container and then making several 
> generic calls to encode the value into the container. Personally, I think 
> this is premature optimization of the highest order—particularly since 
> building an encoder and single-value container are often no-ops—but this is 
> the design they chose, and I don't think it's worth rejecting for that alone.

Has someone done performance tests to validate that this is an issue? If 
nothing else this seems like an implementation detail a conforming type could 
opt to provide but it shouldn't be required in every implementation.


> 
>> I really strongly dislike mixing up the Unkeyed and Keyed concepts. A type 
>> should need to explicitly opt-in to supporting unkeyed and that should be 
>> enforced at compile time. Unkeyed encoding is a potential versioning 
>> nightmare and should be handled with care.
> 
> I think they've done a reasonable job of putting unkeyed coding in a sharps 
> drawer by making you specifically ask for it and giving it an ugly name. 

Can you clarify what you mean? I see keyed and unkeyed spread across various 
protocols and types in the proposal. It's front and center. 

> 
>> C#'s serialization attributes are a better and more comprehensive solution 
>> but we don't have custom attributes in Swift and property behaviors were 
>> deferred. This problem is too important to leave to the future though. If we 
>> did ever add custom attributes or if property behaviors get implemented then 
>> this design could adopt them incrementally without breaking compatibility 
>> (e.g. a serialization transformer behavior that turns a non-Encodable 
>> property into an Encodable one, or a behavior that ignores a property for 
>> serialization purposes).
> 
> On the contrary, I think we *can* safely leave this to the future. If a 
> future version of Swift and Foundation added:
> 
>   @uncoded var foo: Bar
> 
> That would be a completely additive change. Until then, there's an irritating 
> but serviceable solution available—write your own CodingKeys enum and let 
> code generation write the `Codable` conformances based on it.

I didn't write that sentence clearly; I was aiming for your meaning that we can 
leave it for the future.


Russ

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

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

[Jarod Long via swift-evolution]

Thanks Brent, I really appreciate the thoughtful response. Apologies for 
anything I overlooked previously.

I agree with most of your points, although I still find myself preferring the 
common-whitespace logic and leading/trailing newline stripping when considering 
the pros and cons. It doesn't seem likely to gain traction though, so I won't 
spend more time on it.

Thanks again!

Jarod

On Apr 12, 2017, 16:35 -0700, Brent Royal-Gordon , 
wrote:
> > 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 very 
> > natural or intuitive, since I don't think there is any precedent in 
> > standard Swift styling to indent a closing delimiter to the same level as 
> > its content.
>
> String literal delimiters are very different from other delimiters because 
> they switch the parser into a different mode where characters are interpreted 
> in vastly different ways, and every character has a significant meaning. For 
> instance, it's good practice to put either a space, or a newline and 
> indentation, between array and dictionary literal delimiters or curly 
> brackets and their content, but this is not possible with a string literal 
> because the space would count as part of the content. This is the same way: 
> you can't outdent because whitespace is significant inside a string literal, 
> so it would change the meaning.
>
> I think that this probably seems way weirder on paper than it really is in 
> practice. I recommend that you try it and see how it feels.
>
> > Stripping the most common whitespace possible from each line seems to be a 
> > much more intuitive and flexible solution in terms of formatting, and it's 
> > still compatible with the proposed formatting if that's anyone's preference.
>
> I discuss this at length in the Rationale section for indentation stripping. 
> If you'll forgive me for quoting myself:
>
> > We could instead use an algorithm where the longest common whitespace 
> > prefix is removed from all lines; in well-formed code, that would produce 
> > the same behavior as this algorithm. But when not well-formed—when one line 
> > was accidentally indented less than the delimiter, or when a user mixed 
> > tabs and spaces accidentally—it would lead to valid, but incorrect and 
> > undiagnosable, behavior. For instance, if one line used a tab and other 
> > lines used spaces, Swift would not strip indentation from any of the lines; 
> > if most lines were indented four spaces, but one line was indented three, 
> > Swift would strip three spaces of indentation from all lines. And while you 
> > would still be able to create a string with all lines indented by indenting 
> > the closing delimiter less than the others, many users would never discover 
> > this trick.
> Let me provide an example to illustrate what I'm talking about. Suppose you 
> want to say this:
>
> xml += """\↵
> ↵
> \(author)↵
> \(title)↵
> \(genre)↵
> \(price)↵
> ↵
> """↵
>
> But instead, you miss just one little insignificant character:
>
> xml += """\↵
> ···↵
> \(author)↵
> \(title)↵
> \(genre)↵
> \(price)↵
> ↵
> """↵
>
> This is the kind of mistake you will almost certainly never notice by hand 
> inspection. You probably can't see the mistake without looking very 
> carefully—and this is with invisible whitespace replaced with visible dots! 
> But in the least-common-whitespace design, it's perfectly valid, and 
> generates this:
>
> ↵
> ·\(author)↵
> ·\(title)↵
> ·\(genre)↵
> ·\(price)↵
> ·↵
> ·
>
> That is not what you wanted. I'm pretty sure it's almost *never* what you 
> want. But it's valid, it's going to be accepted, and it's going to affect 
> every single line of the literal in a subtle way. (Plus the next line, thanks 
> to that trailing space!) It's not something we can warn about, either, 
> because it's perfectly valid. To fix it, you'll have to notice it's wrong and 
> then work out why that happened.
>
> In the proposed design, on the other hand, we have a single source of truth 
> for indentation: the last line tells us how much we should remove. That means 
> we can actually call a mistake a mistake. The very same example, run through 
> the proposed algorithm, produces this, plus a warning on the first line:
>
> ···↵
> \(author)↵
> \(title)↵
> \(genre)↵
> \(price)↵
> ↵
>
> Notice that there is only one line that comes out incorrectly, that it's the 
> line which has the mistake, that the mistake is large and noticeable in the 
> output, *and* that we were 

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

[Brent Royal-Gordon via swift-evolution]

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

> * Encoder has three functions, but only one may ever be called. This API is 
> the opposite of "pit of success".

Personally, I'm worried about that too. But I had a lot of trouble coming up 
with an alternative that didn't violate a more important goal, like "being able 
to throw errors" or "being compatible with classes".

Last-ditch suggestion: Change a bunch of names so that, for instance, `Encoder` 
is instead `EncodingContainerizer`. (That's a terrible name, but "Factory" 
gives me the hives.) That way, the name of the type gives you a hint that 
you're supposed to use it to make a container. You might even rename the 
methods to e.g. `useContainer(keyedBy:)`, which sound a little more stateful 
and mutually-exclusive.

func encode(to encoder: EncodingContainerizer) throws {
var container = encoder.useContainer(keyedBy: CodingKeys.self)
try container.encode(name, forKey: .name)
try container.encode(birthDate, forKey: .birthDate)
}

> I don't understand why KeyedEncodingContainer needs all those overloads; 
> automatic conformance to Encodable should be provided for the stdlib types in 
> those overloads so why would they be necessary?

I argued about this pretty vigorously. They want to avoid the overhead of 
building an encoder and single-value container and then making several generic 
calls to encode the value into the container. Personally, I think this is 
premature optimization of the highest order—particularly since building an 
encoder and single-value container are often no-ops—but this is the design they 
chose, and I don't think it's worth rejecting for that alone.

> KeyedEncodingContainer.encodeWeak seems like it should be a protocol 
> refinement so you can check for the capability (or potentially know at 
> compile time).

This probably ends up duplicating not only `KeyedEncodingContainerProtocol`,  
but also `UnkeyedEncodingContainer`, `Encoder`, and `Encodable`. Doable, yes. 
Worth it, especially when `encodeWeak` has a pretty sensible fallback behavior? 
Eh.

> (One minor bit of bike shedding: decode/decodeIfPresent could instead be 
> decode(required:) and decode(optional:)).

I don't think `required:` and `optional:` are really helpful. The name here is 
kind of like `addingWithOverflow(_:_:)`—you really want it to be `adding(x, y, 
.withOverflow)`, but it's not worth creating a dummy enum just to make a method 
read properly. Similarly, you'd like `decode(Int.self, .ifPresent)`, but the 
dummy's not worth the better readability.

I'm not sure why we don't do this, though:

// Just showing Unkeyed for simplicity

func decode(_ type: T.Type) throws -> T
func decode(_ type: Optional.Type) throws -> T?

let alwaysInt = try container.decode(Int.self)
let maybeInt = try container.decode(Int?.self)

> I really strongly dislike mixing up the Unkeyed and Keyed concepts. A type 
> should need to explicitly opt-in to supporting unkeyed and that should be 
> enforced at compile time. Unkeyed encoding is a potential versioning 
> nightmare and should be handled with care.

I think they've done a reasonable job of putting unkeyed coding in a sharps 
drawer by making you specifically ask for it and giving it an ugly name. 

> C#'s serialization attributes are a better and more comprehensive solution 
> but we don't have custom attributes in Swift and property behaviors were 
> deferred. This problem is too important to leave to the future though. If we 
> did ever add custom attributes or if property behaviors get implemented then 
> this design could adopt them incrementally without breaking compatibility 
> (e.g. a serialization transformer behavior that turns a non-Encodable 
> property into an Encodable one, or a behavior that ignores a property for 
> serialization purposes).

On the contrary, I think we *can* safely leave this to the future. If a future 
version of Swift and Foundation added:

@uncoded var foo: Bar

That would be a completely additive change. Until then, there's an irritating 
but serviceable solution available—write your own CodingKeys enum and let code 
generation write the `Codable` conformances based on it.

-- 
Brent Royal-Gordon
Architechies

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

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

[Xiaodi Wu via swift-evolution]

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 default. This opinion comes from lots
> of practical experience with multiline string features in other languages.
> In practice, if you're generating files in a line-oriented way, you're
> usually generating them a line at a time. It's pretty rare that you want to
> generate half a line and then add more to it in another statement; it's
> more likely you'll interpolate the data. I'm not saying it doesn't happen,
> of course, but it happens a lot less often than you would think just
> sitting by the fire, drinking whiskey and musing over strings.
>
> I know that, if you're pushing for this feature, it's not satisfying to
> have the answer be "trust me, it's not what you want". But trust me, it's
> not what you want.
>

This is not a very good argument. If you are generating files in a
line-oriented way, it is the function _emitting_ the string that handles
the line-orientedness, not the string itself. That is the example set by
`print()`:

```
print("Hello, world!") // Emits "Hello, world!\n"
```

Once upon a time, if I recall, this function was called `println`, but it
was renamed. This particular example demonstrates why keeping trailing
newlines by default is misguided:

```
print(
  """
  Hello, world!
  """
)
```

Under your proposed rules, this emits "Hello, world!\n\n". It is almost
certainly not what you want. Instead, it is a misguided attempt by the
designers of multiline string syntax to do the job that the designers of
`print()` have already accounted for.

If we were to buy your line of reasoning and adapt it for single-line
strings, we would arrive at a rather absurd result. If you're emitting
multiple single-line strings, you almost certainly want a space to separate
them. Again this is exemplified by the behavior of `print()`:

```
print("Hello", "Brent!")
```

This emits "Hello Brent!" (and not "HelloBrent!"). But we do not take that
reasoning and demand that "This is my string" end with an default trailing
space, nor do we have `+` concatenate strings by default with a separating
space.


Moving to the other end, I think we could do a leading newline strip *if*
> we're willing to create multiline and non-multiline modes—that is, newlines
> are _not allowed at all_ unless the opening delimiter ends its line and the
> closing delimiter starts its line (modulo indentation). But I'm reluctant
> to do that because, well, it's weird and complicated. I also get the
> feeling that, if there's a single-line mode and a multi-line mode, we ought
> to treat them as truly orthogonal features and allow `"`-delimited strings
> to use multi-line mode, but I'm really not convinced that's a good idea.
>
> (Note, by the way, that heredocs—a *really* common multiline string
> design—always strip the leading newline but not the trailing one.)
>
> Adrian cited this example, where I agree that you really don't want the
> string to be on the same line as the leading delimiter:
>
> let myReallyLongXMLConstantName = """
>  
> 
>John Doe
>XML Developer's
> Guide
>Computer
>44.95
> 
>  \
>  """
>
> But there are lots of places where it works fine. Is there a good reason
> to force an additional newline in this?
>
> case .isExprSameType(let from, let to):
> return """checking a value with optional type \(from) against dynamic type
> \(to) \
>   succeeds whenever the value is non-'nil'; did you mean to use '!=
> nil'?\
>   """
>
> I mean, we certainly could, but I'm not convinced we should. At least, not
> yet.
>
> In any case, trailing newline definitely stays. Leading newline, I'm still
> thinking about.
>
> As for other things:
>
> * I see zero reason to fiddle with trailing whitespace. If it's there, it
> might be significant or it might not be. If we strip it by default and we
> shouldn't, the developer has no way to protect it. Let's trust the
> developer. (And their tooling—Xcode, I believe Git, and most linters
> already have trailing whitespace features. We don't need them too.)
>
> * Somebody asked about `"""`-delimited heredocs. I think it's a pretty
> syntax, but it's not compatible with single-line use of `"""`, and I think
> that's probably more important. We can always add heredocs in another way
> if we decide we want them. (I think `#to(END)` is another very Swifty
> syntax we could use for heredocs--less lightweight, but it gives us a
> Google-able keyword.)
>
> * Literal spaces and tabs cannot be 

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

[Adrian Zubarev via swift-evolution]

The example you have provided with where you return a string happens to be 
short before the multi-line string starts and therefore it looks ‘okay’ at that 
moment. However this is the exact example which creates the most problems with 
the multi-line string literal model.

If we’re going to allow that form, that it would be natural to think one could 
also write like this:

"""
Foo
Bar"""
But this is not correct. Furthermore the form from your example also raises the 
question what happens if you add a newline after the starting delimiter? Does 
it add a new line to the string, because at any other line it would. This 
creates an inconsistent behavior and overcomplicates everything?!

The starting delimiter should really only tell you, that the next line will be 
the start of your string and the indent is controlled by the closing delimiter. 
This is way easier. Seriously you will only need to sacrifice one line for that 
behavior, but the ident of your string would align perfectly.

case .isExprSameType(let from, let to):
return """
checking a value with optional type \(from) against dynamic type \(to) \
succeeds whenever the value is non-'nil'; did you mean to use '!= nil'?\
"""
This eliminates all the previously mentioned issues.

I strongly discourage the idea of allowing trailing whitespaces in a line which 
has no backslash at the end. Normal string indicates all its whitespaces 
visually, even if it’s hard to count them, but it does this job for you. At 
least you could approximately guess how many trailing whitespaces you’d have or 
count them with the cursor if needed.

The following string could have 200 characters, but you wouldn’t even notice if 
I don’t tell you so:

"""
foo
"""
That is a really bad idea to support this. Your IDE maybe strip the 
whitespaces, so even if you’d want them to be there, you’ll tap into a corner 
where you’ll have to sacrifice that IDE feature for the whole project in order 
to support it for multi-line string literals in Swift. That is simply wrong.

I called from the beginning for trailing precision, and that’s exactly what the 
backslashes are meant for, plus that they disable the new line injection.

"""
foo  \
"""
Can you now guess how many characters this string will have? Now it’s way 
easier to tell.

I’m not a compiler expert, but shouldn’t the tokenizer simply swallow every 
space characters after a backslash until it finds a new line character at the 
end to the current line? That’s what I would expect it to do, because otherwise 
you’ll end up with error messages, because you cannot rely on your IDE in that 
case. Notice that this is different from the trailing stripping behavior I was 
talking above.



-- 
Adrian Zubarev
Sent with Airmail

Am 13. April 2017 um 00:20:41, Brent Royal-Gordon (br...@architechies.com) 
schrieb:

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 in a line-oriented way, you're usually 
generating them a line at a time. It's pretty rare that you want to generate 
half a line and then add more to it in another statement; it's more likely 
you'll interpolate the data. I'm not saying it doesn't happen, of course, but 
it happens a lot less often than you would think just sitting by the fire, 
drinking whiskey and musing over strings.

I know that, if you're pushing for this feature, it's not satisfying to have 
the answer be "trust me, it's not what you want". But trust me, it's not what 
you want.

Moving to the other end, I think we could do a leading newline strip *if* we're 
willing to create multiline and non-multiline modes—that is, newlines are _not 
allowed at all_ unless the opening delimiter ends its line and the closing 
delimiter starts its line (modulo indentation). But I'm reluctant to do that 
because, well, it's weird and complicated. I also get the feeling that, if 
there's a single-line mode and a multi-line mode, we ought to treat them as 
truly orthogonal features and allow `"`-delimited strings to use multi-line 
mode, but I'm really not convinced that's a good idea.

(Note, by the way, that heredocs—a *really* common multiline string 
design—always strip the leading newline but not the trailing one.)

Adrian cited this example, where I agree that you really don't want the string 
to be on the same line as the leading delimiter:

let myReallyLongXMLConstantName = """
                                     
                                        
                                           John Doe
                                           XML Developer's Guide
                                           Computer
                                           44.95
                                        
                                     \
              

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

[Brent Royal-Gordon via swift-evolution]

> 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 very natural or 
> intuitive, since I don't think there is any precedent in standard Swift 
> styling to indent a closing delimiter to the same level as its content.

String literal delimiters are very different from other delimiters because they 
switch the parser into a different mode where characters are interpreted in 
vastly different ways, and every character has a significant meaning. For 
instance, it's good practice to put either a space, or a newline and 
indentation, between array and dictionary literal delimiters or curly brackets 
and their content, but this is not possible with a string literal because the 
space would count as part of the content. This is the same way: you can't 
outdent because whitespace is significant inside a string literal, so it would 
change the meaning.

I think that this probably seems way weirder on paper than it really is in 
practice. I recommend that you try it and see how it feels.

> Stripping the most common whitespace possible from each line seems to be a 
> much more intuitive and flexible solution in terms of formatting, and it's 
> still compatible with the proposed formatting if that's anyone's preference.

I discuss this at length in the Rationale section for indentation stripping. If 
you'll forgive me for quoting myself:

We could instead use an algorithm where the longest common whitespace prefix is 
removed from all lines; in well-formed code, that would produce the same 
behavior as this algorithm. But when not well-formed—when one line was 
accidentally indented less than the delimiter, or when a user mixed tabs and 
spaces accidentally—it would lead to valid, but incorrect and undiagnosable, 
behavior. For instance, if one line used a tab and other lines used spaces, 
Swift would not strip indentation from any of the lines; if most lines were 
indented four spaces, but one line was indented three, Swift would strip three 
spaces of indentation from all lines. And while you would still be able to 
create a string with all lines indented by indenting the closing delimiter less 
than the others, many users would never discover this trick.

Let me provide an example to illustrate what I'm talking about. Suppose you 
want to say this:

xml += """\↵
↵
\(author)↵
\(title)↵
\(genre)↵
\(price)↵
↵
"""↵

But instead, you miss just one little insignificant character:

xml += """\↵
···↵
\(author)↵
\(title)↵
\(genre)↵
\(price)↵
↵
"""↵

This is the kind of mistake you will almost certainly never notice by hand 
inspection. You probably can't see the mistake without looking very 
carefully—and this is with invisible whitespace replaced with visible dots! But 
in the least-common-whitespace design, it's perfectly valid, and generates this:

↵
·\(author)↵
·\(title)↵
·\(genre)↵
·\(price)↵
·↵
·

That is not what you wanted. I'm pretty sure it's almost *never* what you want. 
But it's valid, it's going to be accepted, and it's going to affect every 
single line of the literal in a subtle way. (Plus the next line, thanks to that 
trailing space!) It's not something we can warn about, either, because it's 
perfectly valid. To fix it, you'll have to notice it's wrong and then work out 
why that happened.

In the proposed design, on the other hand, we have a single source of truth for 
indentation: the last line tells us how much we should remove. That means we 
can actually call a mistake a mistake. The very same example, run through the 
proposed algorithm, produces this, plus a warning on the first line:

···↵
\(author)↵
\(title)↵
\(genre)↵
\(price)↵
↵

Notice that there is only one line that comes out incorrectly, that it's the 
line which has the mistake, that the mistake is large and noticeable in the 
output, *and* that we were also able to emit a compile-time warning pointing to 
the exact line of code that was mistaken. That outcome is night-and-day better.

Now consider mixed tabs and spaces:

xml += """\↵
↵
\(author)↵
⇥   \(title)↵
\(genre)↵
\(price)↵
↵
"""↵

(I'm assuming a tab stop of 4, so mentally adjust that 

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

[John Holdsworth via swift-evolution]

I suppose by pure I mean consistent - treatment of the end of the string
is the same as the treatment of the beginning of the string period.

Practical for me is to do with how you might “want” it to behave. For example
Brent came up with a glitch in previous processing where you had “ inside each
end of the literal.

print(hello world)
 
prints 

"hello world"

To achieve this I had to doctor the termination logic to do something that isn’t
entirely consistent in treatment of the initial and final internal “ but seemed
what people might expect rather than having to escape it.

I would argue we need something analogous for an initial blank line in the 
source
which we definitely want but not necessarily extend this to the closing newline.
Not rigorous in some sense but likely to better suited to most use cases.


> On 12 Apr 2017, at 22:49, Xiaodi Wu  wrote:
> 
> Sorry, what do you mean by "pure" or "practical"?
> On Wed, Apr 12, 2017 at 16:41 John Holdsworth  > wrote:
> There isn’t much in it TBH and I could live with either. Option 1 seems to 
> have been a regression.
> 
> Option 3 is the pure route in one sense but for me Option 2 the more 
> practical which I
> was hoping to demonstrate with the example strings. I’d also ague lines 
> should be
> complete (have line endings unless escaped) by default in a multiline string.
> 
>> On 12 Apr 2017, at 22:31, Xiaodi Wu > > wrote:
>> 
>> John, why do you think that option 2 is superior to option 3?
>> 
>> 
>> On Wed, Apr 12, 2017 at 16:14 John Holdsworth via swift-evolution 
>> > wrote:
>> I think we’re agreeing. Looks like I need to clarify my last post a little. 
>> When I included the following strings:
>> 
>> let longstring = """\
>> Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do 
>> eiusmod \
>> tempor incididunt ut labore et dolore magna aliqua. Ut enim ad 
>> minim veniam, \
>> quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea 
>> commodo consequat.\
>> """
>> 
>> print( """\
>> Usage: myapp 
>> 
>> Run myapp to do mything
>> 
>> Options:
>> -myoption - an option
>> """ )
>> 
>> These were expressed in term of the proposal after last nights changes.
>> 
>> By advocating option 2) I’m accepting we should revert back to the following:
>> 
>> let longstring = """
>> Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do 
>> eiusmod \
>> tempor incididunt ut labore et dolore magna aliqua. Ut enim ad 
>> minim veniam, \
>> quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea 
>> commodo consequat.\
>> """
>> 
>> print( """
>> Usage: myapp 
>> 
>> Run myapp to do mything
>> 
>> Options:
>> -myoption - an option
>> ""” )
>> 
>>> 1) Proposal as it stands  - no magic removal of leading/training blank 
>>> lines.
>>> 2) Removal of a leading blank line when indent stripping is being applied.
>>> 3) Removal of leading blank line and trailing newline when indent stripping 
>>> is being applied.
>> 
>> 
>> Also, note: the toolchain does not seem to work at all with playgrounds. 
>> I’ve been using small test apps.
>> 
>>> On 12 Apr 2017, at 21:06, Adrian Zubarev via swift-evolution 
>>> > wrote:
>>> 
>>> Exactly, I feel like we found a Swifty version of a multi-line string 
>>> literal. :)
>>> 
>>> 
>>> 
>>> 
>>> -- 
>>> Adrian Zubarev
>>> Sent with Airmail
>>> 
>>> Am 12. April 2017 um 21:58:37, Vladimir.S via swift-evolution 
>>> (swift-evolution@swift.org ) schrieb:
>>> 
 this:
 """
 one
 two
 """
 should be just the same as "one\ntwo\n"
 
 If one wants some advanced tuning of line ends, he/she can use a 
 backslash, for example
 """
 one
 two\
 """
 should produce "one\ntwo"
> 
>>> 
>>> ___
>>> swift-evolution mailing list
>>> swift-evolution@swift.org 
>>> https://lists.swift.org/mailman/listinfo/swift-evolution 
>>> 
> 
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org 
>> https://lists.swift.org/mailman/listinfo/swift-evolution 
>> 

___
swift-evolution mailing list
swift-evolution@swift.org

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

[Xiaodi Wu via swift-evolution]

Sorry, what do you mean by "pure" or "practical"?
On Wed, Apr 12, 2017 at 16:41 John Holdsworth 
wrote:

> There isn’t much in it TBH and I could live with either. Option 1 seems to
> have been a regression.
>
> Option 3 is the pure route in one sense but for me Option 2 the more
> practical which I
> was hoping to demonstrate with the example strings. I’d also ague lines
> should be
> complete (have line endings unless escaped) by default in a multiline
> string.
>
> On 12 Apr 2017, at 22:31, Xiaodi Wu  wrote:
>
> John, why do you think that option 2 is superior to option 3?
>
>
> On Wed, Apr 12, 2017 at 16:14 John Holdsworth via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> I think we’re agreeing. Looks like I need to clarify my last post a
> little. When I included the following strings:
>
> let longstring = """\
> Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed
> do eiusmod \
> tempor incididunt ut labore et dolore magna aliqua. Ut enim ad
> minim veniam, \
> quis nostrud exercitation ullamco laboris nisi ut aliquip ex
> ea commodo consequat.\
> """
>
> print( """\
> Usage: myapp 
>
> Run myapp to do mything
>
> Options:
> -myoption - an option
> """ )
>
> These were expressed in term of the proposal after last nights changes.
>
> By advocating option 2) I’m accepting we should revert back to the
> following:
>
> let longstring = """
> Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed
> do eiusmod \
> tempor incididunt ut labore et dolore magna aliqua. Ut enim ad
> minim veniam, \
> quis nostrud exercitation ullamco laboris nisi ut aliquip ex
> ea commodo consequat.\
> """
>
> print( """
> Usage: myapp 
>
> Run myapp to do mything
>
> Options:
> -myoption - an option
> ""” )
>
> 1) Proposal as it stands  - no magic removal of leading/training blank
> lines.
> 2) Removal of a leading blank line when indent stripping is being applied.
> 3) Removal of leading blank line and trailing newline when indent
> stripping is being applied.
>
>
> Also, note: the toolchain does not seem to work at all with playgrounds.
> I’ve been using small test apps.
>
> On 12 Apr 2017, at 21:06, Adrian Zubarev via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> Exactly, I feel like we found a Swifty version of a multi-line string
> literal. :)
>
>
>
> --
> Adrian Zubarev
> Sent with Airmail
>
> Am 12. April 2017 um 21:58:37, Vladimir.S via swift-evolution (
> swift-evolution@swift.org) schrieb:
>
> this:
> """
> one
> two
> """
> should be just the same as "one\ntwo\n"
>
> If one wants some advanced tuning of line ends, he/she can use a
> backslash, for example
> """
> one
> two\
> """
> should produce "one\ntwo"
>
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[John Holdsworth via swift-evolution]

There isn’t much in it TBH and I could live with either. Option 1 seems to have 
been a regression.

Option 3 is the pure route in one sense but for me Option 2 the more practical 
which I
was hoping to demonstrate with the example strings. I’d also ague lines should 
be
complete (have line endings unless escaped) by default in a multiline string.

> On 12 Apr 2017, at 22:31, Xiaodi Wu  wrote:
> 
> John, why do you think that option 2 is superior to option 3?
> 
> 
> On Wed, Apr 12, 2017 at 16:14 John Holdsworth via swift-evolution 
> > wrote:
> I think we’re agreeing. Looks like I need to clarify my last post a little. 
> When I included the following strings:
> 
> let longstring = """\
> Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do 
> eiusmod \
> tempor incididunt ut labore et dolore magna aliqua. Ut enim ad 
> minim veniam, \
> quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea 
> commodo consequat.\
> """
> 
> print( """\
> Usage: myapp 
> 
> Run myapp to do mything
> 
> Options:
> -myoption - an option
> """ )
> 
> These were expressed in term of the proposal after last nights changes.
> 
> By advocating option 2) I’m accepting we should revert back to the following:
> 
> let longstring = """
> Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do 
> eiusmod \
> tempor incididunt ut labore et dolore magna aliqua. Ut enim ad 
> minim veniam, \
> quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea 
> commodo consequat.\
> """
> 
> print( """
> Usage: myapp 
> 
> Run myapp to do mything
> 
> Options:
> -myoption - an option
> ""” )
> 
>> 1) Proposal as it stands  - no magic removal of leading/training blank lines.
>> 2) Removal of a leading blank line when indent stripping is being applied.
>> 3) Removal of leading blank line and trailing newline when indent stripping 
>> is being applied.
> 
> 
> Also, note: the toolchain does not seem to work at all with playgrounds. I’ve 
> been using small test apps.
> 
>> On 12 Apr 2017, at 21:06, Adrian Zubarev via swift-evolution 
>> > wrote:
>> 
>> Exactly, I feel like we found a Swifty version of a multi-line string 
>> literal. :)
>> 
>> 
>> 
>> 
>> -- 
>> Adrian Zubarev
>> Sent with Airmail
>> 
>> Am 12. April 2017 um 21:58:37, Vladimir.S via swift-evolution 
>> (swift-evolution@swift.org ) schrieb:
>> 
>>> this:
>>> """
>>> one
>>> two
>>> """
>>> should be just the same as "one\ntwo\n"
>>> 
>>> If one wants some advanced tuning of line ends, he/she can use a backslash, 
>>> for example
>>> """
>>> one
>>> two\
>>> """
>>> should produce "one\ntwo"
>> 
>> 
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org 
>> https://lists.swift.org/mailman/listinfo/swift-evolution 
>> 
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org 
> https://lists.swift.org/mailman/listinfo/swift-evolution 
> 

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

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

[Xiaodi Wu via swift-evolution]

John, why do you think that option 2 is superior to option 3?


On Wed, Apr 12, 2017 at 16:14 John Holdsworth via swift-evolution <
swift-evolution@swift.org> wrote:

> I think we’re agreeing. Looks like I need to clarify my last post a
> little. When I included the following strings:
>
> let longstring = """\
> Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed
> do eiusmod \
> tempor incididunt ut labore et dolore magna aliqua. Ut enim ad
> minim veniam, \
> quis nostrud exercitation ullamco laboris nisi ut aliquip ex
> ea commodo consequat.\
> """
>
> print( """\
> Usage: myapp 
>
> Run myapp to do mything
>
> Options:
> -myoption - an option
> """ )
>
> These were expressed in term of the proposal after last nights changes.
>
> By advocating option 2) I’m accepting we should revert back to the
> following:
>
> let longstring = """
> Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed
> do eiusmod \
> tempor incididunt ut labore et dolore magna aliqua. Ut enim ad
> minim veniam, \
> quis nostrud exercitation ullamco laboris nisi ut aliquip ex
> ea commodo consequat.\
> """
>
> print( """
> Usage: myapp 
>
> Run myapp to do mything
>
> Options:
> -myoption - an option
> ""” )
>
> 1) Proposal as it stands  - no magic removal of leading/training blank
> lines.
> 2) Removal of a leading blank line when indent stripping is being applied.
> 3) Removal of leading blank line and trailing newline when indent
> stripping is being applied.
>
>
> Also, note: the toolchain does not seem to work at all with playgrounds.
> I’ve been using small test apps.
>
> On 12 Apr 2017, at 21:06, Adrian Zubarev via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> Exactly, I feel like we found a Swifty version of a multi-line string
> literal. :)
>
>
>
> --
> Adrian Zubarev
> Sent with Airmail
>
> Am 12. April 2017 um 21:58:37, Vladimir.S via swift-evolution (
> swift-evolution@swift.org) schrieb:
>
> this:
> """
> one
> two
> """
> should be just the same as "one\ntwo\n"
>
> If one wants some advanced tuning of line ends, he/she can use a
> backslash, for example
> """
> one
> two\
> """
> should produce "one\ntwo"
>
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Adrian Zubarev via swift-evolution]

Sorry for spamming the list with small correction mails. The forum cannot come 
faster so I could edit my typos.

Anyways I meant that the example literal won’t work correctly.



-- 
Adrian Zubarev
Sent with Airmail

Am 12. April 2017 um 23:10:39, Adrian Zubarev (adrian.zuba...@devandartist.com) 
schrieb:

If I understand #2 correctly than it work for this literal.

let x = """↵
abc↵
"""
Iff we only remove the top new line when the below part is indented than the 
literal from above would produce "\nabc\n", which I wouldn’t expect.

Compared to:

let x = """↵
··abc↵
··"""
In the multi-lined version of that literal, the starting delimiter does only 
one job: “look I’m gonna provide a multi-line string in between me and the 
closing delimiter”. That’s it’s only job. (Not yet officially proposed, nor 
it’s in the current toolchain.)

The closing delimiter however covers the leading precision and the indent of 
the current literal. However this is partly visible for a literal that fully 
fits onto your screen. (That’s already included in current toolchain.)

The trailing precision is covered by the backslash (because it’s visible and 
intuitive for the developer), otherwise all whitespace characters are stripped 
at the end and a new line character is implicitly added to that line. (Not 
handled in the current toolchain.)



-- 
Adrian Zubarev
Sent with Airmail

Am 12. April 2017 um 21:08:19, John Holdsworth via swift-evolution 
(swift-evolution@swift.org) schrieb:

Finally.. a new Xcode toolchain is available largely in sync with the proposal 
as is.
(You need to restart Xcode after selecting the toolchain to restart SourceKit)

I personally am undecided whether to remove the first line if it is empty. The 
new
rules are more consistent but somehow less practical. A blank initial line is 
almost
never what a user would want and I would tend towards removing it automatically.
This is almost what a user would it expect it to do.

I’m less sure the same applies to the trailing newline. If this is a syntax for
multi-line strings, I'd argue that they should normally be complete lines -
particularly since the final newline can so easily be escaped.

        let longstring = """\
            Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do 
eiusmod \
            tempor incididunt ut labore et dolore magna aliqua. Ut enim ad 
minim veniam, \
            quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea 
commodo consequat.\
            """

        print( """\
            Usage: myapp 
            
            Run myapp to do mything
            
            Options:
            -myoption - an option
            """ )

(An explicit “\n" in the string should never be stripped btw)

Can we have a straw poll for the three alternatives:

1) Proposal as it stands  - no magic removal of leading/training blank lines.
2) Removal of a leading blank line when indent stripping is being applied.
3) Removal of leading blank line and trailing newline when indent stripping is 
being applied.

My vote is for the pragmatic path: 2)

(The main intent of this revision was actually removing the link between how the
string started and whether indent stripping was applied which was unnecessary.)

On 12 Apr 2017, at 17:48, Xiaodi Wu via swift-evolution 
 wrote:

Agree. I prefer the new rules over the old, but considering common use cases, 
stripping the leading and trailing newline makes for a more pleasant experience 
than not stripping either of them.

I think that is generally worth prioritizing over a simpler algorithm or even 
accommodating more styles. Moreover, a user who wants a trailing or leading 
newline merely types an extra one if there is newline stripping, so no use 
cases are made difficult, only a very common one is made more ergonomic.

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

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

[John Holdsworth via swift-evolution]

I think we’re agreeing. Looks like I need to clarify my last post a little. 
When I included the following strings:

let longstring = """\
Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do 
eiusmod \
tempor incididunt ut labore et dolore magna aliqua. Ut enim ad 
minim veniam, \
quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea 
commodo consequat.\
"""

print( """\
Usage: myapp 

Run myapp to do mything

Options:
-myoption - an option
""" )

These were expressed in term of the proposal after last nights changes.

By advocating option 2) I’m accepting we should revert back to the following:

let longstring = """
Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do 
eiusmod \
tempor incididunt ut labore et dolore magna aliqua. Ut enim ad 
minim veniam, \
quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea 
commodo consequat.\
"""

print( """
Usage: myapp 

Run myapp to do mything

Options:
-myoption - an option
""” )

> 1) Proposal as it stands  - no magic removal of leading/training blank lines.
> 2) Removal of a leading blank line when indent stripping is being applied.
> 3) Removal of leading blank line and trailing newline when indent stripping 
> is being applied.


Also, note: the toolchain does not seem to work at all with playgrounds. I’ve 
been using small test apps.

> On 12 Apr 2017, at 21:06, Adrian Zubarev via swift-evolution 
>  wrote:
> 
> Exactly, I feel like we found a Swifty version of a multi-line string 
> literal. :)
> 
> 
> 
> 
> -- 
> Adrian Zubarev
> Sent with Airmail
> 
> Am 12. April 2017 um 21:58:37, Vladimir.S via swift-evolution 
> (swift-evolution@swift.org ) schrieb:
> 
>> this:
>> """
>> one
>> two
>> """
>> should be just the same as "one\ntwo\n"
>> 
>> If one wants some advanced tuning of line ends, he/she can use a backslash, 
>> for example
>> """
>> one
>> two\
>> """
>> should produce "one\ntwo"
> 
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org 
> https://lists.swift.org/mailman/listinfo/swift-evolution 
> 

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

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

[Zach Waldowski via swift-evolution]

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.

  Zachary Waldowski
  z...@waldowski.me

On Wed, Apr 12, 2017, at 03:22 PM, Brad Hilton via swift-evolution
wrote:
> -1. I support the motivation, but I think this proposal and SE-0167 are
> too premature.
> 
> Don’t get me wrong, I think that Swift leaves much to be desired as far
> as serialization/deserialization goes. However I think that these
> proposals are putting the cart before the horse. I think we first need to
> add genuine reflection APIs before adding encoding/decoding capabilities
> to the stdlib. Reflection will substantially simply most
> serialization/deserialization task. These APIs borrow too much Cocoa’s
> native archiving capabilities for my taste and I’d rather not introduce
> something that may be considered legacy in the future.
> 
> 
> > Hello Swift community,
> > 
> > 
> > The review of SE-0166 "Swift Archival" begins now and runs 
> > through April 12, 2017. The proposal is available here:
> > 
> > > https://github.com/apple/swift-evolution/blob/master/proposals/0166-swift-archival-serialization.md
> > Reviews are an important part of the Swift evolution process. All reviews 
> > should be sent to the swift-evolution mailing list at
> > 
> > > https://lists.swift.org/mailman/listinfo/swift-evolution
> > or, if you would like to keep your feedback private, directly to the review 
> > manager. When replying, please try to keep the proposal link at the top of 
> > the message:
> > 
> > > 
> > > Proposal link:
> > > 
> > > > https://github.com/apple/swift-evolution/blob/master/proposals/0166-swift-archival-serialization.md
> > > 
> > > Reply text
> > > > Other replies
> > > 
> > What goes into a review?
> > 
> > The goal of the review process is to improve the proposal under review 
> > through constructive criticism and, eventually, determine the direction of 
> > Swift. When writing your review, here are some questions you might want to 
> > answer in your review:
> > 
> > What is your evaluation of the proposal?
> > Is the problem being addressed significant enough to warrant a change to 
> > Swift?
> > Does this proposal fit well with the feel and direction of Swift?
> > If you have used other languages or libraries with a similar feature, how 
> > do you feel that this proposal compares to those?
> > How much effort did you put into your review? A glance, a quick reading, or 
> > an in-depth study?
> > 
> > 
> > More information about the Swift evolution process is available at
> > 
> > > https://github.com/apple/swift-evolution/blob/master/process.md
> > Thank you,
> > 
> > 
> > -Doug
> > 
> > 
> > Review Manager
> > 
> > 
> > 
> > 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Adrian Zubarev via swift-evolution]

If I understand #2 correctly than it work for this literal.

let x = """↵
abc↵
"""
Iff we only remove the top new line when the below part is indented than the 
literal from above would produce "\nabc\n", which I wouldn’t expect.

Compared to:

let x = """↵
··abc↵
··"""
In the multi-lined version of that literal, the starting delimiter does only 
one job: “look I’m gonna provide a multi-line string in between me and the 
closing delimiter”. That’s it’s only job. (Not yet officially proposed, nor 
it’s in the current toolchain.)

The closing delimiter however covers the leading precision and the indent of 
the current literal. However this is partly visible for a literal that fully 
fits onto your screen. (That’s already included in current toolchain.)

The trailing precision is covered by the backslash (because it’s visible and 
intuitive for the developer), otherwise all whitespace characters are stripped 
at the end and a new line character is implicitly added to that line. (Not 
handled in the current toolchain.)



-- 
Adrian Zubarev
Sent with Airmail

Am 12. April 2017 um 21:08:19, John Holdsworth via swift-evolution 
(swift-evolution@swift.org) schrieb:

Finally.. a new Xcode toolchain is available largely in sync with the proposal 
as is.
(You need to restart Xcode after selecting the toolchain to restart SourceKit)

I personally am undecided whether to remove the first line if it is empty. The 
new
rules are more consistent but somehow less practical. A blank initial line is 
almost
never what a user would want and I would tend towards removing it automatically.
This is almost what a user would it expect it to do.

I’m less sure the same applies to the trailing newline. If this is a syntax for
multi-line strings, I'd argue that they should normally be complete lines -
particularly since the final newline can so easily be escaped.

        let longstring = """\
            Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do 
eiusmod \
            tempor incididunt ut labore et dolore magna aliqua. Ut enim ad 
minim veniam, \
            quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea 
commodo consequat.\
            """

        print( """\
            Usage: myapp 
            
            Run myapp to do mything
            
            Options:
            -myoption - an option
            """ )

(An explicit “\n" in the string should never be stripped btw)

Can we have a straw poll for the three alternatives:

1) Proposal as it stands  - no magic removal of leading/training blank lines.
2) Removal of a leading blank line when indent stripping is being applied.
3) Removal of leading blank line and trailing newline when indent stripping is 
being applied.

My vote is for the pragmatic path: 2)

(The main intent of this revision was actually removing the link between how the
string started and whether indent stripping was applied which was unnecessary.)

On 12 Apr 2017, at 17:48, Xiaodi Wu via swift-evolution 
 wrote:

Agree. I prefer the new rules over the old, but considering common use cases, 
stripping the leading and trailing newline makes for a more pleasant experience 
than not stripping either of them.

I think that is generally worth prioritizing over a simpler algorithm or even 
accommodating more styles. Moreover, a user who wants a trailing or leading 
newline merely types an extra one if there is newline stripping, so no use 
cases are made difficult, only a very common one is made more ergonomic.

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

Re: [swift-evolution] [Review] SE-0167: Swift Encoders

[Douglas Gregor via swift-evolution]

> On Apr 12, 2017, at 11:49 AM, Russ Bishop  wrote:
> 
> Doug,
> 
> Would it be worth deferring this slightly since it relies on SE-0166? If 
> changes are made to SE-0166 as a result of review it will necessarily impact 
> this proposal.

If there are changes to SE-0166 that affect this, we can always hold off on a 
decision to make more adjustments. I don’t think we need to stagger the review 
of two closely-related proposals like this.

- Doug

> 
> 
> Russ Bishop
> 
> 
>> On Apr 6, 2017, at 11:10 AM, Douglas Gregor via swift-evolution 
>> > wrote:
>> 
>> Hello Swift community,
>> 
>> The review of SE-0167 "Swift Encoders" begins now and runs through April 12, 
>> 2017. The proposal is available here:
>> 
>> https://github.com/apple/swift-evolution/blob/master/proposals/0167-swift-encoders.md
>>  
>> 
>> Note that this proposal is closely related to (and dependent on) SE-0166: 
>> Swift Archival & Serialization 
>> .
>>  Please read and review that proposal as well!
>> 
>> Reviews are an important part of the Swift evolution process. All reviews 
>> should be sent to the swift-evolution mailing list at
>> 
>> https://lists.swift.org/mailman/listinfo/swift-evolution 
>> 
>> or, if you would like to keep your feedback private, directly to the review 
>> manager. When replying, please try to keep the proposal link at the top of 
>> the message:
>> 
>> Proposal link:
>> 
>> https://github.com/apple/swift-evolution/blob/master/proposals/0167-swift-encoders.md
>>  
>> 
>> Reply text
>> Other replies
>>  
>> What
>>  goes into a review?
>> 
>> The goal of the review process is to improve the proposal under review 
>> through constructive criticism and, eventually, determine the direction of 
>> Swift. When writing your review, here are some questions you might want to 
>> answer in your review:
>> 
>> What is your evaluation of the proposal?
>> Is the problem being addressed significant enough to warrant a change to 
>> Swift?
>> Does this proposal fit well with the feel and direction of Swift?
>> If you have used other languages or libraries with a similar feature, how do 
>> you feel that this proposal compares to those?
>> How much effort did you put into your review? A glance, a quick reading, or 
>> an in-depth study?
>> More information about the Swift evolution process is available at
>> 
>> https://github.com/apple/swift-evolution/blob/master/process.md 
>> 
>> Thank you,
>> 
>> -Doug
>> 
>> Review Manager
>> 
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org 
>> https://lists.swift.org/mailman/listinfo/swift-evolution 
>> 
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Adrian Zubarev via swift-evolution]

Below you can read a part of my message to John, where I was testing the 
toolchain.

If that design for the trailing spaces is indented then I disagree with that 
design choice.

In a normal string literal it’s crystal clear that it contains multiple space 
characters at the end, because it’s visible to the reader of that code. As 
shown below, if Xcode wouldn’t help here, the end result might contain spaces 
which could be caused by an accident and are not clear to the reader at all.

I suggest to align this behavior with normal string literals by stripping all 
space characters at the end of each line, just like Xcode does, unless they are 
explicitly annotated by a backslash, which would be clear to the reader of the 
code.

That said, this:

let s0 = "abc\n"

let s1 = """↵
abc···↵
"""
 
let s2 = """↵
abc···\↵
"""
 
let s3 = """↵
abc···\n\↵
"""
 
s0 == s1 // => true
s0 == s2 // => false
s2 == "abc···"   // => true
s3 == "abc···\n" // => true
Xcode does trip trailing spaces by default for me, however I was able to press 
spacebar a couple times and these spaces where not trimmed by the current 
toolchain.

“”"↵
AA↵
“”"

The string was equivalent to “\nAA\n”




The strange character is actually a white space displayed by Xcode.

-- 
Adrian Zubarev
Sent with Airmail

Am 12. April 2017 um 22:06:01, Adrian Zubarev (adrian.zuba...@devandartist.com) 
schrieb:

Exactly, I feel like we found a Swifty version of a multi-line string literal. 
:)



-- 
Adrian Zubarev
Sent with Airmail

Am 12. April 2017 um 21:58:37, Vladimir.S via swift-evolution 
(swift-evolution@swift.org) schrieb:

this:
"""
one
two
"""
should be just the same as "one\ntwo\n"

If one wants some advanced tuning of line ends, he/she can use a backslash, for 
example
"""
one
two\
"""
should produce "one\ntwo"
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Ricardo Parada via swift-evolution]

Yes, you are right.  I tested using the IBM Swift Sandbox 
.

In Xcode the output is as expected with the empty line in between the two lines.


> On Apr 12, 2017, at 2:33 PM, Adrian Zubarev  
> wrote:
> 
> You’re wrong there, Xcode does print this for me:
> 
> Line1
> 
> Line 2
> The new line is there as expected.
> 
> 
> 
> 
> -- 
> Adrian Zubarev
> Sent with Airmail
> 
> Am 12. April 2017 um 20:30:00, Ricardo Parada (rpar...@mac.com 
> ) schrieb:
> 
>> print("Line1\n")
>> print("Line 2")
> 

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

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

[David Hart via swift-evolution]

> On 12 Apr 2017, at 20:44, Russ Bishop via swift-evolution 
>  wrote:
> 
> 
>> On Apr 6, 2017, at 11:10 AM, Douglas Gregor via swift-evolution 
>> > wrote:
>> 
>> Hello Swift community,
>> 
>> The review of SE-0166 "Swift Archival & Serialization" begins now and runs 
>> through April 12, 2017. The proposal is available here:
>> 
>> https://github.com/apple/swift-evolution/blob/master/proposals/0166-swift-archival-serialization.md
>>  
>> 
>> Reviews are an important part of the Swift evolution process. All reviews 
>> should be sent to the swift-evolution mailing list at
>> 
>> https://lists.swift.org/mailman/listinfo/swift-evolution 
>> 
>> or, if you would like to keep your feedback private, directly to the review 
>> manager. When replying, please try to keep the proposal link at the top of 
>> the message:
>> 
>> Proposal link:
>> 
>> https://github.com/apple/swift-evolution/blob/master/proposals/0166-swift-archival-serialization.md
>>  
>> 
>> Reply text
>> Other replies
>>  
>> What
>>  goes into a review?
>> 
>> The goal of the review process is to improve the proposal under review 
>> through constructive criticism and, eventually, determine the direction of 
>> Swift. When writing your review, here are some questions you might want to 
>> answer in your review:
>> 
>> What is your evaluation of the proposal?
> It is a good first step but I feel like it tries to match NSSecureCoding 
> design patterns too strongly and introduces a lot of potential for API misuse 
> (convention rather than using the type system to our advantage). If we ask 
> "what does a modern take on NSSecureCoding look like?", this proposal is the 
> answer. If we ask "how can we do better than NSSecureCoding?" then this 
> proposal needs a little bit of refinement.

I also agree that the API feels slightly more influenced by NSCoding and 
Objective-C paradigms than by Swift idioms.

> Some examples:
> 
> * String and Int keys being optional, giving a CodingKey the opportunity to 
> return nil for both at runtime.
> * Encoder has three functions, but only one may ever be called. This API is 
> the opposite of "pit of success”.

The amount of preconditions in the documentation of Coder and then 
CocoaError.coderTypeMismatch errors of Decoder paint the same picture. I 
understand the argument that writing this proposal taking full advantage of the 
type system would exponentially increase the number of types and worsen the 
API. But perhaps the Encoder/Decoder protocols could take advantage of more 
types.

> There is also the problem of an implementation cliff: A type that has one 
> non-Encodable property suddenly needs to provide a complete implementation. 
> It is relatively common to have ephemeral data you don't even want to be 
> encoded but again it seems like you need to jump immediately to a completely 
> manual solution.

I don’t think you’re right here. The proposal states:

• Types falling into (1) — and types which manually provide a CodingKey 
enum (named CodingKeys, directly, or via a typealias) whose cases map 1-to-1 to 
Encodable/Decodable properties by name — get automatic synthesis of init(from:) 
and encode(to:) as appropriate, using those properties and keys

So if you do have ephemeral data, you’d only need to define the CodingKey enum 
and be good to go.

> There may not be a way to square this circle but it is worth thinking about. 
> One improvement would be that a type can provide its own CodingKey but still 
> get automatic conformance for all properties that match. At least then you 
> would have a way to filter out the properties you don't want.
> 
> 
> I don't understand why KeyedEncodingContainer needs all those overloads; 
> automatic conformance to Encodable should be provided for the stdlib types in 
> those overloads so why would they be necessary?

I’ve been beating the same bush. I know the arguments but it just feels wrong 
to me. That’s a case where this API definitely feels more like Objective-C than 
Swift.

> KeyedEncodingContainer.encodeWeak seems like it should be a protocol 
> refinement so you can check for the capability (or potentially know at 
> compile time).  The decoder begs a similar question: why not rely on the 
> generic functions? (One minor bit of bike shedding: decode/decodeIfPresent 
> could instead be decode(required:) and decode(optional:)).
> 
> 
> I really strongly dislike mixing up the Unkeyed and Keyed concepts. A type 
> should need to explicitly opt-in to supporting unkeyed and that should be 
> enforced at compile time. 

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

[Matthew Johnson via swift-evolution]

> On Apr 12, 2017, at 3:15 PM, Nevin Brackett-Rozinsky via swift-evolution 
>  wrote:
> 
> In order to evaluate this proposal, I created a table of as many relevant 
> scenarios as I could think of, and listed how each of the proposed solutions 
> would work there. The four access level systems I compared are:
> 
> No change: The existing Swift 3 status quo with “fileprivate” and “private”.
> 
> SE–0159: Revert to the Swift 2 meaning of “private” (file visibility) and 
> eliminate scoped access altogether.
> 
> SE–0169: Expand “private” to include the current type and all its extensions 
> in the same file.
> 
> Rename: Change the spelling of “private” to “scoped”, and “fileprivate” to 
> “private”.
> 
> I ended up with a list of eight scenarios to evaluate. These are:
> 
> 1. “Simple file”, a single type with no extensions.
> 2. “Extensions”, a single type and extensions thereof.
> 3. “Sharing”, multiple types that need privileged access to each other.
> 4. “Helper visible”, the interface of a helper (or nested) type for use 
> within the file.
> 5. “Helper hidden”, the details of a helper type that should not be visible 
> to other types.
> 6. “Invariants”, the details of a type that should only be touched by 
> dedicated methods.
> 7. “Multi-type”, multiple types that should not have privileged access to 
> each other.
> 8. “Multi-type + ext”, multiple types that should not have privileged access 
> to each other, and extensions thereof.
> 
> The entries in the table have seven possible values:
> 
> private: The “private” keyword works.
> 
> fileprivate: The “fileprivate” keyword works.
> 
> scoped: The “scoped” keyword works.
> 
> private x2: The “private” keyword works if the types are put into separate 
> files.
> 
> fileprivate x2: The “fileprivate” keyword works if the types are put into 
> separate files.
> 
> helper type: The goal can only be achieved by creating a helper type.
> 
> no hiding: The specified items cannot be hidden from the rest of the file.
> 
> Here is the completed and color-coded table (I hope it displays properly in 
> this email):
> 
> 
> 
> No change
> SE–0159
> SE–0169
> Rename
> Simple file
> private
> private
> private
> private
> Extensions
> fileprivate
> private
> private
> private
> Sharing
> fileprivate
> private
> fileprivate
> private
> Helper visible
> fileprivate
> private
> fileprivate
> private
> Helper hidden
> private
> no hiding
> private
> scoped
> Invariants
> private
> no hiding
> helper type
> scoped
> Multi-type
> private
> private x2
> private
> scoped
> Multi-type + ext
> fileprivate x2
> private x2
> private
> private x2
> 
> 
> Analysis
> 
> Some people have said on-list that they view cross-type sharing as an 
> anti-pattern. If that is true, then we can simply ignore the “Sharing” row 
> because it would not be worth optimizing for. This hardly changes the table 
> though, as that row is identical to the “Helper visible” row below it.
> 
> Regarding the “Invariants” row, note that a helper type can be used for this 
> purpose under “No change” and “Rename” just as well as under “SE–0169”. The 
> difference is that SE-0169 provides no other way to hide invariants from the 
> rest of the type, whereas the other two have an access level suited to the 
> purpose. Similarly, the multi-type rows can be satisfied by separate files 
> regardless of which access system is in place.
> 
> If a person takes the view that things in the same file should naturally have 
> access to one another, then the bottom four rows of the table can be ignored. 
> Such a person might have the mantra, “Only put things together if they belong 
> together”, and they would ask, “What else is in the file that you are trying 
> to hide from?”
> 
> For someone whose primary use-case is to put one type in a file and build it 
> up through extensions, the “Extension” row is of greatest concern. To them, 
> any of SE–0159, SE–0169, or renaming would let them use “private” instead of 
> “fileprivate” everywhere.
> 
> As a final remark, each of the four options has one notable benefit and one 
> notable drawback, not all of which are apparent from the above table:
> 
> No change
> Benefit: No change to the language.
> Drawback: Must use “fileprivate” to build up a type through extensions.
> 
> SE–0159
> Benefit: Simplifies the access control model.
> Drawback: Cannot protect invariants within a file.
> 
> SE–0169
> Benefit: Cross-type sharing is clearly marked.
> Drawback: Must use a helper type to protect invariants within a file.

FWIW, a secondary drawback to SE-0169 is that the protection afforded by this 
helper type is permeable - the helper type can be extended anywhere inside the 
file.  It is more than SE-0159 but not as strong a guarantee as either no 
change or rename.  Extensions to the helper type will stand out much more 
clearly than inadvertent use of a `private` member under SE-0159 but readers 
still need to know they don’t exist or look 

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

[David Hart via swift-evolution]

I remember being against this feature when it was first discussed long ago. But 
I’ve since appreciated how elegant it is. I also like the i… was chosen instead 
of i..<

I guess Range would be a better name for the generic protocol to represent all 
ranges. But its too late for that now. Correct?

> On 12 Apr 2017, at 18:40, Ben Cohen via swift-evolution 
>  wrote:
> 
> Hi Swift community,
> 
> Another proposal pitch. These operators were mentioned briefly in the String 
> manifesto as prefixing/suffixing is very common with strings.
> 
> Online copy here: 
> https://github.com/airspeedswift/swift-evolution/blob/71b819d30676c44234bac1aa61fc5c39bcf3/proposals/-OneSidedRanges.md
>  
> 
> One-sided Ranges
> 
> Proposal: SE- 
> 
> Authors: Ben Cohen , Dave Abrahams 
> , Brent Royal-Gordon 
> 
> Review Manager: TBD
> Status: Awaiting review
> Introduction
> 
> This proposal introduces the concept of a “one-sided” range, created via 
> prefix/postfix versions of the existing range operators.
> 
> It also introduces a new protocol, RangeExpression, to simplify the creation 
> of methods that take different kinds of ranges.
> 
> Motivation
> 
> It is common, given an index into a collection, to want a slice up to or from 
> that index versus the start/end.
> 
> For example (assuming String is once more a Collection):
> 
> let s = "Hello, World!"
> let i = s.index(where: ",")
> let greeting = s[s.startIndex.. When performing lots of slicing like this, the verbosity of repeating 
> s.startIndex is tiresome to write and harmful to readability.
> 
> Swift 3’s solution to this is a family of methods:
> 
> let greeting = s.prefix(upTo: i)
> let withComma = s.prefix(through: i)
> let location = s.suffix(from: i)
> The two very different-looking ways to perform a similar task is jarring. And 
> as methods, the result cannot be used as an l-value.
> 
> A variant of the one-sided slicing syntax found in Python (i.e. s[i:]) is 
> proposed to resolve this.
> 
> Proposed solution
> 
> Introduce a one-sided range syntax, where the “missing” side is inferred to 
> be the start/end:
> 
> // half-open right-handed range
> let greeting = s[.. // closed right-handed range
> let withComma = s[...i]
> // left-handed range (no need for half-open variant)
> let location = s[i...]
> Additionally, when the index is a countable type, i... should form a Sequence 
> that counts up from i indefinitely. This is useful in forming variants of 
> Sequence.enumerated() when you either want them non-zero-based i.e. zip(1..., 
> greeting), or want to flip the order i.e. zip(greeting, 0...).
> 
> This syntax would supercede the existing prefix and suffix operations that 
> take indices, which will be deprecated in a later release. Note that the 
> versions that take distances are not covered by this proposal, and would 
> remain.
> 
> This will require the introduction of new range types (e.g. 
> PartialRangeThrough). There are already multiple range types (e.g. 
> ClosedRange, CountableHalfOpenRange), which require overloads to allow them 
> to be used whereever a Range can be.
> 
> To unify these different range types, a new protocol, RangeExpression will be 
> created and all ranges conformed to it. Existing overloads taking concrete 
> types other than Range can then be replaced with a single generic method that 
> takes a RangeExpression, converts it to a Range, and then forward the method 
> on.
> 
> A generic version of ~= will also be implemented for all range expressions:
> 
> switch i {
> case 9001...: print("It’s over NINE THOUSAAAND")
> default: print("There's no way that can be right!")
> }
> The existing concrete overloads that take ranges other than Range will be 
> deprecated in favor of generic ones that take a RangeExpression.
> 
> Detailed design
> 
> Add the following to the standard library:
> 
> (a fuller work-in-progress implementation can be found here: 
> https://github.com/apple/swift/pull/8710 
> )
> 
> NOTE: The following is subject to change depending on pending compiler 
> features. Methods may actually be on underscored protocols, and then moved 
> once recursive protocols are implemented. Types may be collapsed using 
> conditional conformance. This should not matter from a usage perspective – 
> users are not expected to use these types directly or override any of the 
> behaviors in their own types. Any final implementation will follow the below 
> in spirit if not in practice.
> 
> public protocol RangeExpression {
> associatedtype Bound: Comparable
> 
> /// Returns `self` expressed as a range of indices within `collection`.
> ///
> /// -Parameter collection: The collection `self` should 

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

[Ted F.A. van Gaalen via swift-evolution]

Hi,

(wrote a bit or two about this before)
For a moment, let's make the unlikely assumption that really no one has a 
problem 
with changing the next Swift version, having lexical scope as the only scope 
mechanism. . . 
which would be that each and every item is visible and accessible only inside 
the source level where it is declared,
unless of course revealed outwards with an access modifier. 
(.e.g. protected, internal, public (private would be implicit))  
Like it is in most other procedural/OOP languages.

Now, also assume that Swift has always been that way: lexical scope only.

Given this, as yet, hypothetical Swift environment, my questions are: 
Would this be feasible in Swift? 

E.g. does it constrain/conflict with current Swift language 
constructs/organisation ? 
(you can reveal items to the outside scope with access modifiers)

Side effects, technical limitations?

Am I right in thinking that Swift would be a lot easier to work with if lexical 
scope had
been there from the very beginning?

If Swift 4 would be set to lexical scope only, could the source conversion be 
automated successfully?
 E.g. by automatically adding the "internal" access modifier to all items that 
don't have an access modifier right now in Swift 3.x ? 

If all this would be possible, it would of course be a very drastic change, 
but what is it worth to finally get scope access right once and for all ?  
(imho)

The necessity of “private” or “fileprivate” keywords is by itself
a clear signal that the current access mechanism is wrong, I think. 

Very interested in your opinion, thank you.
Anyone?


TedvG
www.tedvg.com




> 
> Date: Wed, 12 Apr 2017 07:30:04 +0200
> From: David Hart >
> To: Chris Lattner >
> Cc: swift-evolution  >
> Subject: Re: [swift-evolution] Enhancing access levels without
>   breakingchanges
> Message-ID:  >
> Content-Type: text/plain; charset=utf-8
> 
> 
> On 12 Apr 2017, at 07:16, Chris Lattner  > wrote:
> 
> On Apr 11, 2017, at 3:53 AM, David Hart via swift-evolution 
> > wrote:
>> 
 I understand what you are saying and I wouldn't be against relaxing that 
 requirement (not talking for Chris here).
 
 The model would change from "Types share scopes with their extensions in 
 the same file the type was defined" to "Types and their extensions share 
 the same scope in each file".
>>> 
>>> Oh, I had missed that somehow.  I agree that that is a very strange rule.  
>>> Do you know why it was proposed that way?
>> 
>> We had to take a stance and Chris seemed to prefer the rule that was 
>> proposed. I didn't press because I'm sure he has reasons for preferring it 
>> that way. But I have a preference for generalizing visibility to all 
>> extensions, even to those in a different file than the type.
> 
> To me, the reason for limiting it to a file is about predictability, the 
> ability to locally reason about a type, and the need to define some boundary 
> (for symbol visibility reasons).  Saying that extensions to a type have 
> access to private members if they are in the same module is just as arbitrary 
> as limiting it to a single file, and a whole lot less useful from the 
> “reasoning about a type” perspective.
> 
> I think you misunderstand. We were talking about two extensions of a type, in 
> a different file from the type, to share private members between themselves.
> Doug Gregor mentioned it during the PR process and we added an example to 
> disallow it, but in hindsight, I think it should be allowed.
> Expanding it beyond a module would require a ton of stuff to be exported that 
> otherwise wouldn’t be, and would defeat a ton of optimization potential that 
> we can’t accept.
> 
> -Chris
> 
> 
> 
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] switch must be exhaustive, consider adding a default clause

[Joe Groff via swift-evolution]

> On Apr 11, 2017, at 11:24 AM, Drew Crawford  wrote:
> 
> 
> 
> 
> On April 11, 2017 at 11:38:05 AM, Joe Groff (jgr...@apple.com 
> ) wrote:
> 
>> By design, Swift avoids making semantic rules based on that kind of 
>> analysis, since it would be brittle and difficult to describe when the 
>> compiler can and can't see that a condition holds nonlocally like this.
> 
> Swift *currently implements* semantic rules based on this kind of analysis.  
> Exhibit A:
> 
> func foo() {
> 
> let a: Bool
> 
> if UUID().uuidString == "non-local condition" {
> 
> a = true
> 
> }
> 
> else {
> 
> preconditionFailure("Don't initialize a")
> 
> }
> 
> print("\(a)") //NOT: error: a is uninitialized
> 
> }
> 
That analysis is pretty strictly limited as well. The DI assignment has to 
happen once along every code path before the variable is ever read or escaped, 
so the effects are localized. To do pattern matching refinement something like 
you're proposing, we need to know that the value isn't mutated between 
switches. That becomes impossible if the variable is ever escaped, so you'd get 
spooky action at a distance where referencing the variable in a closure 
somewhere would cause seemingly-unrelated control flow errors to spring up 
seeming randomly; global variables and class properties would also 
fundamentally never benefit from this analysis, making it feel inconsistent 
when exactly the refined switch is allowed.

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

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

[Nevin Brackett-Rozinsky via swift-evolution]

In order to evaluate this proposal, I created a table of as many relevant
scenarios as I could think of, and listed how each of the proposed
solutions would work there. The four access level systems I compared are:

*No change:* The existing Swift 3 *status quo* with “fileprivate” and
“private”.

*SE–0159:* Revert to the Swift 2 meaning of “private” (file visibility) and
eliminate scoped access altogether.

*SE–0169:* Expand “private” to include the current type and all its
extensions in the same file.

*Rename:* Change the spelling of “private” to “scoped”, and “fileprivate”
to “private”.

I ended up with a list of eight scenarios to evaluate. These are:

1. “Simple file”, a single type with no extensions.
2. “Extensions”, a single type and extensions thereof.
3. “Sharing”, multiple types that need privileged access to each other.
4. “Helper visible”, the interface of a helper (or nested) type for use
within the file.
5. “Helper hidden”, the details of a helper type that should not be visible
to other types.
6. “Invariants”, the details of a type that should only be touched by
dedicated methods.
7. “Multi-type”, multiple types that should not have privileged access to
each other.
8. “Multi-type + ext”, multiple types that should not have privileged
access to each other, and extensions thereof.

The entries in the table have seven possible values:

*private:* The “private” keyword works.

*fileprivate:* The “fileprivate” keyword works.

*scoped:* The “scoped” keyword works.

*private x2:* The “private” keyword works if the types are put into
separate files.

*fileprivate x2:* The “fileprivate” keyword works if the types are put into
separate files.

*helper type:* The goal can only be achieved by creating a helper type.

*no hiding:* The specified items cannot be hidden from the rest of the file.

Here is the completed and color-coded table (I hope it displays properly in
this email):



*No change*

*SE–0159*

*SE–0169*

*Rename*

*Simple file*

private

private

private

private

*Extensions*

fileprivate

private

private

private

*Sharing*

fileprivate

private

fileprivate

private

*Helper visible*

fileprivate

private

fileprivate

private

*Helper hidden*

private

no hiding

private

scoped

*Invariants*

private

no hiding

helper type

scoped

*Multi-type*

private

private x2

private

scoped

*Multi-type + ext*

fileprivate x2

private x2

private

private x2


*Analysis*

Some people have said on-list that they view cross-type sharing as an
anti-pattern. If that is true, then we can simply ignore the “Sharing” row
because it would not be worth optimizing for. This hardly changes the table
though, as that row is identical to the “Helper visible” row below it.

Regarding the “Invariants” row, note that a helper type can be used for
this purpose under “No change” and “Rename” just as well as under
“SE–0169”. The difference is that SE-0169 provides no other way to hide
invariants from the rest of the type, whereas the other two have an access
level suited to the purpose. Similarly, the multi-type rows can be
satisfied by separate files regardless of which access system is in place.

If a person takes the view that things in the same file should naturally
have access to one another, then the bottom four rows of the table can be
ignored. Such a person might have the mantra, “Only put things together if
they belong together”, and they would ask, “What else is in the file that
you are trying to hide from?”

For someone whose primary use-case is to put one type in a file and build
it up through extensions, the “Extension” row is of greatest concern. To
them, any of SE–0159, SE–0169, or renaming would let them use “private”
instead of “fileprivate” everywhere.

As a final remark, each of the four options has one notable benefit and one
notable drawback, not all of which are apparent from the above table:

*No change*
Benefit: No change to the language.
Drawback: Must use “fileprivate” to build up a type through extensions.

*SE–0159*
Benefit: Simplifies the access control model.
Drawback: Cannot protect invariants within a file.

*SE–0169*
Benefit: Cross-type sharing is clearly marked.
Drawback: Must use a helper type to protect invariants within a file.

*Rename*
Benefit: No change to semantics.
Drawback: Two separate keywords are changed.

 • • •

And now, having said all that, I need to go take a nap!

Once everything has percolated, I’ll come back to write a review of the
current proposal.

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

Re: [swift-evolution] Unify the way properties and methods work to make key-value coding more natural

[Joe Groff via swift-evolution]

> On Apr 12, 2017, at 7:48 AM, Andrey Volodin via swift-evolution 
>  wrote:
> 
> Recently I’ve seen some upcoming changes for #keyPath, but the whole things 
> look a bit messy to me. Today I came up with a simple idea of code 
> generation, but I thought maybe it would be nice to make this a part of the 
> language?
> 
> Look at this code:
> 
> public class Foo {
> public var a: Int = 0
> }
> 
> public final class Property {
> public var `get`: (U) -> () -> V
> public var `set`: (U) -> (V) -> Void
> 
> public init(getter: @escaping (U) -> () -> V, setter: @escaping (U) -> 
> (V) -> Void) {
> self.get = getter
> self.set = setter
> }
> }
> 
> // Generated code
> public extension Foo {
> public static let a: Property = {
> return Property(getter: { instance -> (Void) -> Int in
> return { return instance.a} },
>   setter: { instance -> (Int) -> Void in
> return { value -> Void in 
> instance.a = value } })
> }()
> }
> 
> let foo = Foo()
> foo.a = 5
> 
> let _a = Foo.a.get(foo)()
> print(_a)
> 
> Foo.a.set(foo)(10)
> print(foo.a)
> 
> The idea is to make properties work the same way the methods work right now. 
> That will allow things like tweening properties in the game engine, by simply 
> passing the property to some sort of ActionManager.
> 
> Of course, this can be achieved by code-generator, but I bet this will be 
> very ineffecient in terms of performance. 
> 
> The only draw back here from top of my head: It will be impossible to have 
> instance- and static- variables with the same name. 
> 
> What do you think about this?

KeyPath is pretty much exactly your Property; however, keypaths are 
also intended to support equality as well as other reflective features down the 
line, so they need a bit more information under the hood than just an opaque 
closure. Our original proposal suggested exactly this syntax, but we rejected 
it because we felt like the unapplied member syntax looks too much like a 
concrete property/method reference, even in its existing form for methods. 
While the \ syntax will only apply to key paths to begin with, we want to look 
into unifying all unapplied member references under that syntax.

-Joe

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

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

[Adrian Zubarev via swift-evolution]

Exactly, I feel like we found a Swifty version of a multi-line string literal. 
:)



-- 
Adrian Zubarev
Sent with Airmail

Am 12. April 2017 um 21:58:37, Vladimir.S via swift-evolution 
(swift-evolution@swift.org) schrieb:

this:
"""
one
two
"""
should be just the same as "one\ntwo\n"

If one wants some advanced tuning of line ends, he/she can use a backslash, for 
example
"""
one
two\
"""
should produce "one\ntwo"
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Vladimir.S via swift-evolution]

On 12.04.2017 22:07, John Holdsworth via swift-evolution wrote:
Finally.. a new Xcode toolchain 
 is available largely 
in sync with the proposal as is.

(You need to restart Xcode after selecting the toolchain to restart SourceKit)

I personally am undecided whether to remove the first line if it is empty. The 
new
rules are more consistent but somehow less practical. A blank initial line is 
almost
never what a user would want and I would tend towards removing it automatically.
This is almost what a user would it expect it to do.


IMO the rule should be simple: """ is a *marker* of the begin/end of multi-line 
string, not the part of multi-line string itself.
And so there is no question regarding "new line" symbol injection after leading """ 
and before/after trailing """. Each line *between* leading and trailing triple quotes 
- the only lines of multi-string.


And as soon as last line *of text* inside multi-line string has new line, the result 
text also should have it. It is common to have, for example, a text file where last 
line ends with \n symbol, i.e. with "new line" character. It is common to end the 
text in text editor by pressing Enter, so last symbol will be \n. Even in XML/JSON file.

Why we invent a complex/confused rules for multi-line string in Swift code?

I.e.

this:
"""
one
two
"""
should be just the same as "one\ntwo\n"

If one wants some advanced tuning of line ends, he/she can use a backslash, for 
example
"""
one
two\
"""
should produce "one\ntwo"

Btw, in which situations it is important to remove the trailing \n character from 
*multi-line* string? How is common this use-case? Because I can't think of 
XML/JSON/SQL text, they should not depend on trailing new line symbol.




I’m less sure the same applies to the trailing newline. If this is a syntax for
multi-line strings, I'd argue that they should normally be complete lines -
particularly since the final newline can so easily be escaped.

letlongstring = """\
 Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do 
eiusmod \
 tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim 
veniam, \
 quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo 
consequat.\

 """

print( """\
 Usage: myapp 


 Run myapp to do mything


 Options:
 -myoption - an option
 """ )

(An explicit “\n" in the string should never be stripped btw)

Can we have a straw poll for the three alternatives:

1) Proposal as it stands  - no magic removal of leading/training blank lines.
2) Removal of a leading blank line when indent stripping is being applied.
3) Removal of leading blank line and trailing newline when indent stripping is being 
applied.


My vote is for the pragmatic path: 2)

(The main intent of this revision was actually removing the link between how the
string started and whether indent stripping was applied which was unnecessary.)

On 12 Apr 2017, at 17:48, Xiaodi Wu via swift-evolution > wrote:


Agree. I prefer the new rules over the old, but considering common use cases, 
stripping the leading and trailing newline makes for a more pleasant experience 
than not stripping either of them.


I think that is generally worth prioritizing over a simpler algorithm or even 
accommodating more styles. Moreover, a user who wants a trailing or leading newline 
merely types an extra one if there is newline stripping, so no use cases are made 
difficult, only a very common one is made more ergonomic.




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


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

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

[Adrian Zubarev via swift-evolution]

Quickly correcting myself. I meant to say:

As already mentioned a couple times the rules can be simplified by disallowing 
text in the same line after and before the starting/closing delimiters.


-- 
Adrian Zubarev
Sent with Airmail

Am 12. April 2017 um 21:34:34, Adrian Zubarev (adrian.zuba...@devandartist.com) 
schrieb:

As already mentioned a couple times the rules can be simplified by disallowing 
text after and before the starting/leading delimiters.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Adrian Zubarev via swift-evolution]

Thank you for the toolchain, I’m currently downloading it to test.

As already mentioned a couple times the rules can be simplified by disallowing 
text after and before the starting/leading delimiters.

Allow single line tripled string """text"""

Multi-lined text should always be between the delimiter lines. Therefore there 
is no need for an implicit leading new line or something like """\. The 
trailing new line is the artifact of the rule #3.

Each line in between the delimiter lines produces an implicit new line if not 
disabled with an explicit backslash at the end of that line. (Last line 
produces the mentioned artifact in #2.)

The backslash is also used for trailing precision if needed, however the cost 
is that the implicit new line is disabled and one would need to write \n\.

The closing delimiter determines the indent for the current multi-line string 
literal, by calculating its indent-prefix from the start of that line to the 
delimiter itself.

Each line in between the delimiters is stripped exactly like the calculated 
indent-prefix in #5. If it’s not possible, because of a mismatch of the spacing 
characters or a non-spacing character was found before the algorithm finished 
stripping the current line, a warning is emitted to fix the indent. (This rule 
covers literally everyones indent preferences, because it should not care if 
the ident is using spaces only, tabs only or a mix of them.)

#5 and #7 also allows easy leading spacing precision, which was a tedious 
approach with continuation quotes.

I think I pretty much covered everything here now.

Let me know if I missed something.



-- 
Adrian Zubarev
Sent with Airmail

Am 12. April 2017 um 21:08:19, John Holdsworth via swift-evolution 
(swift-evolution@swift.org) schrieb:

Finally.. a new Xcode toolchain is available largely in sync with the proposal 
as is.
(You need to restart Xcode after selecting the toolchain to restart SourceKit)

I personally am undecided whether to remove the first line if it is empty. The 
new
rules are more consistent but somehow less practical. A blank initial line is 
almost
never what a user would want and I would tend towards removing it automatically.
This is almost what a user would it expect it to do.

I’m less sure the same applies to the trailing newline. If this is a syntax for
multi-line strings, I'd argue that they should normally be complete lines -
particularly since the final newline can so easily be escaped.

        let longstring = """\
            Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do 
eiusmod \
            tempor incididunt ut labore et dolore magna aliqua. Ut enim ad 
minim veniam, \
            quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea 
commodo consequat.\
            """

        print( """\
            Usage: myapp 
            
            Run myapp to do mything
            
            Options:
            -myoption - an option
            """ )

(An explicit “\n" in the string should never be stripped btw)

Can we have a straw poll for the three alternatives:

1) Proposal as it stands  - no magic removal of leading/training blank lines.
2) Removal of a leading blank line when indent stripping is being applied.
3) Removal of leading blank line and trailing newline when indent stripping is 
being applied.

My vote is for the pragmatic path: 2)

(The main intent of this revision was actually removing the link between how the
string started and whether indent stripping was applied which was unnecessary.)

On 12 Apr 2017, at 17:48, Xiaodi Wu via swift-evolution 
 wrote:

Agree. I prefer the new rules over the old, but considering common use cases, 
stripping the leading and trailing newline makes for a more pleasant experience 
than not stripping either of them.

I think that is generally worth prioritizing over a simpler algorithm or even 
accommodating more styles. Moreover, a user who wants a trailing or leading 
newline merely types an extra one if there is newline stripping, so no use 
cases are made difficult, only a very common one is made more ergonomic.

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

[swift-evolution] Unify the way properties and methods work to make key-value coding more natural

[Brad Hilton via swift-evolution]

I like the .get syntax better than \
I’d be okay with the slightly more verbose .getter
Foo.a could return a tuple: (getter: (Foo) -> () -> A, setter: (Foo) -> (A) -> 
())

> Recently I’ve seen some upcoming changes for #keyPath, but the whole things 
> look a bit messy to me. Today I came up with a simple idea of code 
> generation, but I thought maybe it would be nice to make this a part of the 
> language?
> 
> Look at this code:
> 
> publicclassFoo {
> publicvara:Int=0
> }
> 
> publicfinalclassProperty{
> publicvar`get`: (U) ->() ->V
> publicvar`set`: (U) ->(V) ->Void
> 
> publicinit(getter:@escaping(U) ->() ->V, setter:@escaping(U) ->(V) ->Void) {
> self.get = getter
> self.set = setter
> }
> }
> 
> // Generated code
> publicextensionFoo{
> publicstaticleta:Property= {
> returnProperty(getter: { instance ->(Void) ->Intin
> return{returninstance.a} },
> setter: { instance ->(Int) ->Voidin
> return{ value ->Voidininstance.a = value } })
> }()
> }
> 
> letfoo = Foo()
> foo.a =5
> 
> let_a = Foo.a.get(foo)()
> print(_a)
> 
> Foo.a.set(foo)(10)
> print(foo.a)
> 
> 
> The idea is to make properties work the same way the methods work right now. 
> That will allow things like tweening properties in the game engine, by simply 
> passing the property to some sort of ActionManager.
> 
> Of course, this can be achieved by code-generator, but I bet this will be 
> very ineffecient in terms of performance.
> 
> The only draw back here from top of my head: It will be impossible to have 
> instance- and static- variables with the same name.
> 
> What do you think about this?___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
> 
> 
> 
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

[swift-evolution] [Review] SE-0167: Swift Encoders

[Brad Hilton via swift-evolution]

-1. I left my feedback for this proposal and SE-0166 on the other thread, but 
TLDR; I think this is premature until we add true reflection capabilities
to Swift.

> Hello Swift community,
> 
> 
> The review of SE-0167 "Swift Encoders" begins now and runs through April 12, 
> 2017. The proposal is available here:
> 
> > https://github.com/apple/swift-evolution/blob/master/proposals/0167-swift-encoders.md
> Note that this proposal is closely related to (and dependent on)SE-0166: 
> Swift 
> Archival(https://github.com/apple/swift-evolution/blob/master/proposals/0166-swift-archival-serialization.md).
>  Please read and review that proposal as well!
> 
> 
> Reviews are an important part of the Swift evolution process. All reviews 
> should be sent to the swift-evolution mailing list at
> 
> > https://lists.swift.org/mailman/listinfo/swift-evolution
> or, if you would like to keep your feedback private, directly to the review 
> manager. When replying, please try to keep the proposal link at the top of 
> the message:
> 
> > 
> > Proposal link:
> > 
> > > https://github.com/apple/swift-evolution/blob/master/proposals/0167-swift-encoders.md
> > 
> > Reply text
> > > Other replies
> > 
> What goes into a review?
> 
> The goal of the review process is to improve the proposal under review 
> through constructive criticism and, eventually, determine the direction of 
> Swift. When writing your review, here are some questions you might want to 
> answer in your review:
> 
> What is your evaluation of the proposal?
> Is the problem being addressed significant enough to warrant a change to 
> Swift?
> Does this proposal fit well with the feel and direction of Swift?
> If you have used other languages or libraries with a similar feature, how do 
> you feel that this proposal compares to those?
> How much effort did you put into your review? A glance, a quick reading, or 
> an in-depth study?
> 
> 
> More information about the Swift evolution process is available at
> 
> > https://github.com/apple/swift-evolution/blob/master/process.md
> Thank you,
> 
> 
> -Doug
> 
> 
> Review Manager
> 
> 
> 
> 
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Brad Hilton via swift-evolution]

-1. I support the motivation, but I think this proposal and SE-0167 are too 
premature.

Don’t get me wrong, I think that Swift leaves much to be desired as far as 
serialization/deserialization goes. However I think that these proposals are 
putting the cart before the horse. I think we first need to add genuine 
reflection APIs before adding encoding/decoding capabilities to the stdlib. 
Reflection will substantially simply most serialization/deserialization task. 
These APIs borrow too much Cocoa’s native archiving capabilities for my taste 
and I’d rather not introduce something that may be considered legacy in the 
future.


> Hello Swift community,
> 
> 
> The review of SE-0166 "Swift Archival" begins now and runs 
> through April 12, 2017. The proposal is available here:
> 
> > https://github.com/apple/swift-evolution/blob/master/proposals/0166-swift-archival-serialization.md
> Reviews are an important part of the Swift evolution process. All reviews 
> should be sent to the swift-evolution mailing list at
> 
> > https://lists.swift.org/mailman/listinfo/swift-evolution
> or, if you would like to keep your feedback private, directly to the review 
> manager. When replying, please try to keep the proposal link at the top of 
> the message:
> 
> > 
> > Proposal link:
> > 
> > > https://github.com/apple/swift-evolution/blob/master/proposals/0166-swift-archival-serialization.md
> > 
> > Reply text
> > > Other replies
> > 
> What goes into a review?
> 
> The goal of the review process is to improve the proposal under review 
> through constructive criticism and, eventually, determine the direction of 
> Swift. When writing your review, here are some questions you might want to 
> answer in your review:
> 
> What is your evaluation of the proposal?
> Is the problem being addressed significant enough to warrant a change to 
> Swift?
> Does this proposal fit well with the feel and direction of Swift?
> If you have used other languages or libraries with a similar feature, how do 
> you feel that this proposal compares to those?
> How much effort did you put into your review? A glance, a quick reading, or 
> an in-depth study?
> 
> 
> More information about the Swift evolution process is available at
> 
> > https://github.com/apple/swift-evolution/blob/master/process.md
> Thank you,
> 
> 
> -Doug
> 
> 
> Review Manager
> 
> 
> 
> 
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Adrian Zubarev via swift-evolution]

That’s already a huge part of the proposal. If I understood the indent 
algorithm correctly than it should already support everyones preferences for 
their indent style. The indent is determined by the prefix indent before the 
closing delimiter.

The example you proved should, for my understanding emit 3 warnings that each 
line in between the delimiter has wrong ident. It also could help you with 
fix-its to fix that issue and add another whitespace of tab, depending on which 
indent prefix the closing delimiter has.

The string itself should be equivalent to "aa\nbb\ncc\n" even if you have 
warnings to fix.



-- 
Adrian Zubarev
Sent with Airmail

Am 12. April 2017 um 21:00:08, Jarod Long via swift-evolution 
(swift-evolution@swift.org) schrieb:

The only functional limitation that I see is that if you can't have leading 
whitespace in the interpreted string if you actually want that. That doesn't 
seem like a very important use case to me, but if we think it is important, it 
could be supported by something like having a backslash in the leading 
whitespace at the location where it should be preserved from.

If we're set on the proposed behavior, have we considered what happens if the 
closing delimiter goes beyond the non-whitespace content of the string?

let string = """
    aa
    bb
    cc
     """

Does it strip the non-whitespace characters? Does it strip up to the 
non-whitespace characters? Does it generate an error?
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[John Holdsworth via swift-evolution]

Finally.. a new Xcode toolchain 
 is available 
largely in sync with the proposal as is.
(You need to restart Xcode after selecting the toolchain to restart SourceKit)

I personally am undecided whether to remove the first line if it is empty. The 
new
rules are more consistent but somehow less practical. A blank initial line is 
almost
never what a user would want and I would tend towards removing it automatically.
This is almost what a user would it expect it to do.

I’m less sure the same applies to the trailing newline. If this is a syntax for
multi-line strings, I'd argue that they should normally be complete lines -
particularly since the final newline can so easily be escaped.

let longstring = """\
Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do 
eiusmod \
tempor incididunt ut labore et dolore magna aliqua. Ut enim ad 
minim veniam, \
quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea 
commodo consequat.\
"""

print( """\
Usage: myapp 

Run myapp to do mything

Options:
-myoption - an option
""" )

(An explicit “\n" in the string should never be stripped btw)

Can we have a straw poll for the three alternatives:

1) Proposal as it stands  - no magic removal of leading/training blank lines.
2) Removal of a leading blank line when indent stripping is being applied.
3) Removal of leading blank line and trailing newline when indent stripping is 
being applied.

My vote is for the pragmatic path: 2)

(The main intent of this revision was actually removing the link between how the
string started and whether indent stripping was applied which was unnecessary.)

> On 12 Apr 2017, at 17:48, Xiaodi Wu via swift-evolution 
>  wrote:
> 
> Agree. I prefer the new rules over the old, but considering common use cases, 
> stripping the leading and trailing newline makes for a more pleasant 
> experience than not stripping either of them.
> 
> I think that is generally worth prioritizing over a simpler algorithm or even 
> accommodating more styles. Moreover, a user who wants a trailing or leading 
> newline merely types an extra one if there is newline stripping, so no use 
> cases are made difficult, only a very common one is made more ergonomic.

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

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

[Jarod Long via swift-evolution]

This is the most logical newline stripping behavior in my opinion. It's very 
easy to think about -- all the lines in-between the triple quotes are the 
contents of the string. Leading and trailing newlines are easily added if 
desired by adding extra lines.

To support that model, I also agree with the suggestion that we shouldn't allow 
multiline string contents on the same line as the opening or closing 
delimiters. They are multiline strings after all, so I don't see much value in 
supporting that.

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 very natural or 
intuitive, since I don't think there is any precedent in standard Swift styling 
to indent a closing delimiter to the same level as its content. Stripping the 
most common whitespace possible from each line seems to be a much more 
intuitive and flexible solution in terms of formatting, and it's still 
compatible with the proposed formatting if that's anyone's preference.

The only functional limitation that I see is that if you can't have leading 
whitespace in the interpreted string if you actually want that. That doesn't 
seem like a very important use case to me, but if we think it is important, it 
could be supported by something like having a backslash in the leading 
whitespace at the location where it should be preserved from.

If we're set on the proposed behavior, have we considered what happens if the 
closing delimiter goes beyond the non-whitespace content of the string?

let string = """
    aa
    bb
    cc
     """

Does it strip the non-whitespace characters? Does it strip up to the 
non-whitespace characters? Does it generate an error?

Jarod

On Apr 12, 2017, 10:41 -0700, Ricardo Parada via swift-evolution 
, wrote:
> 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.
>
> Borrowing Adrian's example, I could just have this:
>
>
> let myReallyLongXMLConstantName = """
>
>
>
>John Doe
>XML Developer's Guide
>Computer
>44.95
>
>
>"""
> If somebody wants the last line to include a newline at the end, they can 
> just add a \n at the end or an empty line.
>
> So if I do this:
>
> print(myReallyLongXMLConstantName)
> print("Text right below")
> It would output this:
>
>  
>  
>      
>          John Doe
>          XML Developer's Guide
>          Computer
>          44.95
>      
>  
> Test right below
>
> Without removing the trailing newline then it would print like this:
>
>  
>  
>      
>          John Doe
>          XML Developer's Guide
>          Computer
>          44.95
>      
>  
>
> Test right below
>
>
>
>
> > On Apr 12, 2017, at 12:48 PM, Xiaodi Wu via swift-evolution 
> >  wrote:
> >
> > Agree. I prefer the new rules over the old, but considering common use 
> > cases, stripping the leading and trailing newline makes for a more pleasant 
> > experience than not stripping either of them.
> >
> > I think that is generally worth prioritizing over a simpler algorithm or 
> > even accommodating more styles. Moreover, a user who wants a trailing or 
> > leading newline merely types an extra one if there is newline stripping, so 
> > no use cases are made difficult, only a very common one is made more 
> > ergonomic.
> > > On Wed, Apr 12, 2017 at 09:52 Thorsten Seitz via swift-evolution 
> > >  wrote:
> > > > > Am 12.04.2017 um 15:40 schrieb Brent Royal-Gordon via swift-evolution 
> > > > > :
> > > > >
> > > > > 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
> > > >
> > > > Hmm, not sure if I like these changes. I expect that almost all strings 
> > > > won't begin with a newline and a majority won’t end with a newline. The 
> > > > new design would require a leading backslash almost all the time and a 
> > > > trailing backslash often, which is ugly:
> > > >
> > > > let mystring = "““\
> > > >     text text
> > > >     text text\
> > > >     "““
> > > >
> > > > -Thorsten
> > > >
> > > >
> > > > > disagreed with this at first, but it made more sense as we thought 
> > > > > about it more. There are a few things we like about it:
> > > > >
> > > > >       1. The rules and algorithm are simpler.
> > > > >       2. It accommodates more coding styles.
> > > > 

Re: [swift-evolution] [Review] SE-0167: Swift Encoders

[Russ Bishop via swift-evolution]

Doug,

Would it be worth deferring this slightly since it relies on SE-0166? If 
changes are made to SE-0166 as a result of review it will necessarily impact 
this proposal.


Russ Bishop


> On Apr 6, 2017, at 11:10 AM, Douglas Gregor via swift-evolution 
>  wrote:
> 
> Hello Swift community,
> 
> The review of SE-0167 "Swift Encoders" begins now and runs through April 12, 
> 2017. The proposal is available here:
> 
> https://github.com/apple/swift-evolution/blob/master/proposals/0167-swift-encoders.md
>  
> 
> Note that this proposal is closely related to (and dependent on) SE-0166: 
> Swift Archival & Serialization 
> .
>  Please read and review that proposal as well!
> 
> Reviews are an important part of the Swift evolution process. All reviews 
> should be sent to the swift-evolution mailing list at
> 
> https://lists.swift.org/mailman/listinfo/swift-evolution 
> 
> or, if you would like to keep your feedback private, directly to the review 
> manager. When replying, please try to keep the proposal link at the top of 
> the message:
> 
> Proposal link:
> 
> https://github.com/apple/swift-evolution/blob/master/proposals/0167-swift-encoders.md
>  
> 
> Reply text
> Other replies
>  
> What
>  goes into a review?
> 
> The goal of the review process is to improve the proposal under review 
> through constructive criticism and, eventually, determine the direction of 
> Swift. When writing your review, here are some questions you might want to 
> answer in your review:
> 
> What is your evaluation of the proposal?
> Is the problem being addressed significant enough to warrant a change to 
> Swift?
> Does this proposal fit well with the feel and direction of Swift?
> If you have used other languages or libraries with a similar feature, how do 
> you feel that this proposal compares to those?
> How much effort did you put into your review? A glance, a quick reading, or 
> an in-depth study?
> More information about the Swift evolution process is available at
> 
> https://github.com/apple/swift-evolution/blob/master/process.md 
> 
> Thank you,
> 
> -Doug
> 
> Review Manager
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

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

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

[Martin Waitz via swift-evolution]

Hey Brent,

thanks a lot for working on multi-line strings!

You were also talking about """ heredocs.
I really liked that idea.
Have you abandoned this concept?

Given that triple-quotes in Swift are already quite different from the Python 
version,
we could as well go one step further and introduce quoted here-docs.

E.g.:
print(""")
Hello world.
""" 

Is there any interest in something like this?
Should I invest some time in drafting a specification/proposal?

— Martin

> Am 12.04.2017 um 15:40 schrieb Brent Royal-Gordon via swift-evolution 
> :
> 
> 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 first, but it made 
> more sense as we thought about it more. There are a few things we like about 
> it:
> 
>   1. The rules and algorithm are simpler.
>   2. It accommodates more coding styles.
>   3. Every non-escaped newline in the literal now creates a corresponding 
> newline in the resulting string.
>   4. it's easy to get the old behavior back by backslashing the leading 
> newline.
> 
> Unfortunately, I think this precludes stripping the trailing newline by 
> default, but I think this is ultimately a simpler and better approach than 
> the previous draft.
> 
> Other changes:
> 
>   * We realized we needed to make closing delimiter matching a little 
> more complicated if we wanted to allow one or two adjacent double-quote 
> characters that were part of the literal's contents. Oops.
>   * Tabs aren't actually allowed in ordinary string literals, so we now 
> explicitly mention that as a difference between the two types.
>   * We wrote some tests for the prototype (though they haven't been 
> updated for this new version yet). 
>   * There were some other wording changes, particularly in the 
> indentation stripping rationale, but nothing that affects the actual design.
> 
> I understand John is working on a new version of his toolchain so people can 
> play with the prototype. We hope to have that ready for you all soon.
> 
> Let us know what you think of the revisions!
> 
> -- 
> Brent Royal-Gordon
> Architechies
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

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

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

[Russ Bishop via swift-evolution]

> On Apr 6, 2017, at 11:10 AM, Douglas Gregor via swift-evolution 
>  wrote:
> 
> Hello Swift community,
> 
> The review of SE-0166 "Swift Archival & Serialization" begins now and runs 
> through April 12, 2017. The proposal is available here:
> 
> https://github.com/apple/swift-evolution/blob/master/proposals/0166-swift-archival-serialization.md
>  
> 
> Reviews are an important part of the Swift evolution process. All reviews 
> should be sent to the swift-evolution mailing list at
> 
> https://lists.swift.org/mailman/listinfo/swift-evolution 
> 
> or, if you would like to keep your feedback private, directly to the review 
> manager. When replying, please try to keep the proposal link at the top of 
> the message:
> 
> Proposal link:
> 
> https://github.com/apple/swift-evolution/blob/master/proposals/0166-swift-archival-serialization.md
>  
> 
> Reply text
> Other replies
>  
> What
>  goes into a review?
> 
> The goal of the review process is to improve the proposal under review 
> through constructive criticism and, eventually, determine the direction of 
> Swift. When writing your review, here are some questions you might want to 
> answer in your review:
> 
> What is your evaluation of the proposal?
It is a good first step but I feel like it tries to match NSSecureCoding design 
patterns too strongly and introduces a lot of potential for API misuse 
(convention rather than using the type system to our advantage). If we ask 
"what does a modern take on NSSecureCoding look like?", this proposal is the 
answer. If we ask "how can we do better than NSSecureCoding?" then this 
proposal needs a little bit of refinement.

Some examples:

* String and Int keys being optional, giving a CodingKey the opportunity to 
return nil for both at runtime.
* Encoder has three functions, but only one may ever be called. This API is the 
opposite of "pit of success".

There is also the problem of an implementation cliff: A type that has one 
non-Encodable property suddenly needs to provide a complete implementation. It 
is relatively common to have ephemeral data you don't even want to be encoded 
but again it seems like you need to jump immediately to a completely manual 
solution. There may not be a way to square this circle but it is worth thinking 
about. One improvement would be that a type can provide its own CodingKey but 
still get automatic conformance for all properties that match. At least then 
you would have a way to filter out the properties you don't want.


I don't understand why KeyedEncodingContainer needs all those overloads; 
automatic conformance to Encodable should be provided for the stdlib types in 
those overloads so why would they be necessary?


KeyedEncodingContainer.encodeWeak seems like it should be a protocol refinement 
so you can check for the capability (or potentially know at compile time).  The 
decoder begs a similar question: why not rely on the generic functions? (One 
minor bit of bike shedding: decode/decodeIfPresent could instead be 
decode(required:) and decode(optional:)).


I really strongly dislike mixing up the Unkeyed and Keyed concepts. A type 
should need to explicitly opt-in to supporting unkeyed and that should be 
enforced at compile time. Unkeyed encoding is a potential versioning nightmare 
and should be handled with care.


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

> Does this proposal fit well with the feel and direction of Swift?
See comments above

> If you have used other languages or libraries with a similar feature, how do 
> you feel that this proposal compares to those?
Yes; C#'s serialization attributes are a better and more comprehensive solution 
but we don't have custom attributes in Swift and property behaviors were 
deferred. This problem is too important to leave to the future though. If we 
did ever add custom attributes or if property behaviors get implemented then 
this design could adopt them incrementally without breaking compatibility (e.g. 
a serialization transformer behavior that turns a non-Encodable property into 
an Encodable one, or a behavior that ignores a property for serialization 
purposes).



I want to say thank-you to Itai, Michael, and Tony for their hard work on this 
and the related proposal; having done a proposal myself I know how much work it 
entails.


Russ Bishop



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

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

[Adrian Zubarev via swift-evolution]

You’re wrong there, Xcode does print this for me:

Line1

Line 2
The new line is there as expected.



-- 
Adrian Zubarev
Sent with Airmail

Am 12. April 2017 um 20:30:00, Ricardo Parada (rpar...@mac.com) schrieb:

print("Line1\n")
print("Line 2")
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Ricardo Parada via swift-evolution]

Okay, so maybe we should not strip the trailing newline.

The xml concatenation example in Brent's revised proposal assumes the literal 
includes a trailing newline.

Also, if you do this in Swift:

print("Line1\n")
print("Line 2")

It seems to strip trailing newlines.  So the above actually outputs this with 
no empty line in between them:

Line 1
Line 2

Conclusion: I think it is best to include the trailing newline.  :-)



> On Apr 12, 2017, at 1:52 PM, Adrian Zubarev  
> wrote:
> 
> Actually this would be inconsistent. The lines in between the delimiters 
> should always add an implicit new line if not told otherwise with a 
> backslash. If that wouldn’t be the case than you won’t have any precision in 
> the last line you have there.
> 
> Assume you want to concatenate this string:
> 
> foo
> bar   baz
> To do so you’d need extra spaces in your " baz" string, because of the 
> inconsistency. However the constant version I’m suggesting is more precise.
> 
> let myString = """
> foo
> bar   \
> """
>  
> print(myString + "baz")
> The last implicit new line which one would need to escape is a model 
> artifact, but it’s consistent that way.
> 
> The extra new line one would ever need to add manually would be only at the 
> top of a multi-line string.
> 
> // v1:
> 
> """
> 
> foo
> bar\
> """
> 
> // v2:
> """
> \n\
> foo
> bar\
> """
> 
> // v3:
> """
> \nfoo
> bar\
> """
> 
> 
> 
> -- 
> Adrian Zubarev
> Sent with Airmail
> 
> Am 12. April 2017 um 19:41:14, Ricardo Parada via swift-evolution 
> (swift-evolution@swift.org ) schrieb:
> 
>> 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. 
>> 
>> Borrowing Adrian's example, I could just have this:
>> 
>> let myReallyLongXMLConstantName = """
>> 
>> 
>> 
>> John Doe
>> XML Developer's Guide
>> Computer
>> 44.95
>> 
>> 
>> """
>> If somebody wants the last line to include a newline at the end, they can 
>> just add a \n at the end or an empty line.
>> 
>> So if I do this:
>> print(myReallyLongXMLConstantName)
>> print("Text right below")
>> It would output this:
>> 
>>  
>>  
>>  
>>  John Doe
>>  XML Developer's Guide
>>  Computer
>>  44.95
>>  
>>  
>> Test right below
>> 
>> Without removing the trailing newline then it would print like this:
>> 
>>  
>>  
>>  
>>  John Doe
>>  XML Developer's Guide
>>  Computer
>>  44.95
>>  
>>  
>> 
>> Test right below
>> 
>> 
>> 
>> 
>>> On Apr 12, 2017, at 12:48 PM, Xiaodi Wu via swift-evolution 
>>> > wrote:
>>> 
>>> Agree. I prefer the new rules over the old, but considering common use 
>>> cases, stripping the leading and trailing newline makes for a more pleasant 
>>> experience than not stripping either of them.
>>> 
>>> I think that is generally worth prioritizing over a simpler algorithm or 
>>> even accommodating more styles. Moreover, a user who wants a trailing or 
>>> leading newline merely types an extra one if there is newline stripping, so 
>>> no use cases are made difficult, only a very common one is made more 
>>> ergonomic.
>>> On Wed, Apr 12, 2017 at 09:52 Thorsten Seitz via swift-evolution 
>>> > wrote:
>>> > Am 12.04.2017 um 15:40 schrieb Brent Royal-Gordon via swift-evolution 
>>> > >:
>>> >
>>> > 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
>>> 
>>> Hmm, not sure if I like these changes. I expect that almost all strings 
>>> won't begin with a newline and a majority won’t end with a newline. The new 
>>> design would require a leading backslash almost all the time and a trailing 
>>> backslash often, which is ugly:
>>> 
>>> let mystring = "““\
>>> text text
>>> text text\
>>> "““
>>> 
>>> -Thorsten
>>> 
>>> 
>>> > disagreed with this at first, but it made more sense as we thought about 
>>> > it more. There are a few things we like about it:
>>> >
>>> >   1. The rules and algorithm are simpler.
>>> >   2. It accommodates more coding styles.
>>> >   3. Every non-escaped newline in the literal now creates a 
>>> > corresponding newline in the resulting string.
>>> >   4. it's easy to get the old behavior back by backslashing the 
>>> > 

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

[Martin Waitz via swift-evolution]

Well summarised Tino, I agree with all arguments.
Strong -1 from me, too.

> Am 11.04.2017 um 08:48 schrieb Tino Heth via swift-evolution 
> :
> 
> -1 (strong)
> 
> I think I've read all messages and haven't much to add — so just to sum up my 
> concerns in order:
> — It makes access control more complicated
> — It adds no power to the language
> — It diminishes the need for fileprivate without making it redundant
> — It is a mockery for SE-0025
> — It is a breaking change

If we want to encourage separating several aspects of one type into multiple 
extensions, then we should try a different approach.
When we allow to also introduce new member variables in extensions, then we 
could make them private while still keeping them local to the member functions 
which access them.

This approach has other downsides but I think we can cope with them.
Biggest disadvantage would be that the storage size is not immediately visible 
from the type definition.
We could require some marker (`partial class` / `extension class` / whatever) 
so that everybody can immediately see that there may be extensions with 
additional storage.

E.g.:

partial class Foo {}

extension Foo {
private var i = 0
func bar() {
print(i)
i += 1
}
}
extension Foo {
private var j = 1
func baz() {
print(j)
j -= 1
}
}

When we want any distinction between `private` and `fileprivate`, then these 
two extensions should not see each others private members.
Of course the other workaround would be to remove the distinction altogether 
and make private an alias for fileprivate.

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

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

[Nevin Brackett-Rozinsky via swift-evolution]

Strong +1, glad to see this happening!

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

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

[Adrian Zubarev via swift-evolution]

Actually this would be inconsistent. The lines in between the delimiters should 
always add an implicit new line if not told otherwise with a backslash. If that 
wouldn’t be the case than you won’t have any precision in the last line you 
have there.

Assume you want to concatenate this string:

foo
bar   baz
To do so you’d need extra spaces in your " baz" string, because of the 
inconsistency. However the constant version I’m suggesting is more precise.

let myString = """
foo
bar   \
"""
 
print(myString + "baz")
The last implicit new line which one would need to escape is a model artifact, 
but it’s consistent that way.

The extra new line one would ever need to add manually would be only at the top 
of a multi-line string.

// v1:

"""

foo
bar\
"""

// v2:
"""
\n\
foo
bar\
"""

// v3:
"""
\nfoo
bar\
"""


-- 
Adrian Zubarev
Sent with Airmail

Am 12. April 2017 um 19:41:14, Ricardo Parada via swift-evolution 
(swift-evolution@swift.org) schrieb:

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. 

Borrowing Adrian's example, I could just have this:

let myReallyLongXMLConstantName = """



John Doe
XML Developer's Guide
Computer
44.95


""" 
If somebody wants the last line to include a newline at the end, they can just 
add a \n at the end or an empty line.

So if I do this:
print(myReallyLongXMLConstantName)
print("Text right below")
It would output this:

 
 
     
         John Doe
         XML Developer's Guide
         Computer
         44.95
     
 
Test right below

Without removing the trailing newline then it would print like this:

 
 
     
         John Doe
         XML Developer's Guide
         Computer
         44.95
     
 

Test right below




On Apr 12, 2017, at 12:48 PM, Xiaodi Wu via swift-evolution 
 wrote:

Agree. I prefer the new rules over the old, but considering common use cases, 
stripping the leading and trailing newline makes for a more pleasant experience 
than not stripping either of them.

I think that is generally worth prioritizing over a simpler algorithm or even 
accommodating more styles. Moreover, a user who wants a trailing or leading 
newline merely types an extra one if there is newline stripping, so no use 
cases are made difficult, only a very common one is made more ergonomic.
On Wed, Apr 12, 2017 at 09:52 Thorsten Seitz via swift-evolution 
 wrote:
> Am 12.04.2017 um 15:40 schrieb Brent Royal-Gordon via swift-evolution 
> :
>
> 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

Hmm, not sure if I like these changes. I expect that almost all strings won't 
begin with a newline and a majority won’t end with a newline. The new design 
would require a leading backslash almost all the time and a trailing backslash 
often, which is ugly:

let mystring = "““\
    text text
    text text\
    "““

-Thorsten


> disagreed with this at first, but it made more sense as we thought about it 
> more. There are a few things we like about it:
>
>       1. The rules and algorithm are simpler.
>       2. It accommodates more coding styles.
>       3. Every non-escaped newline in the literal now creates a corresponding 
>newline in the resulting string.
>       4. it's easy to get the old behavior back by backslashing the leading 
>newline.
>
> Unfortunately, I think this precludes stripping the trailing newline by 
> default, but I think this is ultimately a simpler and better approach than 
> the previous draft.
>
> Other changes:
>
>       * We realized we needed to make closing delimiter matching a little 
>more complicated if we wanted to allow one or two adjacent double-quote 
>characters that were part of the literal's contents. Oops.
>       * Tabs aren't actually allowed in ordinary string literals, so we now 
>explicitly mention that as a difference between the two types.
>       * We wrote some tests for the prototype (though they haven't been 
>updated for this new version yet).
>       * There were some other wording changes, particularly in the 
>indentation stripping rationale, but nothing that affects the actual design.
>
> I understand John is working on a new version of his toolchain so people can 
> play with the prototype. We hope to have that ready for you all soon.
>
> Let us know what you think of the revisions!
>
> --
> Brent Royal-Gordon
> Architechies
>
> ___
> 

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

[Ricardo Parada via swift-evolution]

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. 

Borrowing Adrian's example, I could just have this:

let myReallyLongXMLConstantName = """



John Doe
XML Developer's Guide
Computer
44.95


"""
If somebody wants the last line to include a newline at the end, they can just 
add a \n at the end or an empty line.

So if I do this:
print(myReallyLongXMLConstantName)
print("Text right below")
It would output this:

 
 
 
 John Doe
 XML Developer's Guide
 Computer
 44.95
 
 
Test right below

Without removing the trailing newline then it would print like this:

 
 
 
 John Doe
 XML Developer's Guide
 Computer
 44.95
 
 

Test right below




> On Apr 12, 2017, at 12:48 PM, Xiaodi Wu via swift-evolution 
>  wrote:
> 
> Agree. I prefer the new rules over the old, but considering common use cases, 
> stripping the leading and trailing newline makes for a more pleasant 
> experience than not stripping either of them.
> 
> I think that is generally worth prioritizing over a simpler algorithm or even 
> accommodating more styles. Moreover, a user who wants a trailing or leading 
> newline merely types an extra one if there is newline stripping, so no use 
> cases are made difficult, only a very common one is made more ergonomic.
> On Wed, Apr 12, 2017 at 09:52 Thorsten Seitz via swift-evolution 
> > wrote:
> > Am 12.04.2017 um 15:40 schrieb Brent Royal-Gordon via swift-evolution 
> > >:
> >
> > 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
> 
> Hmm, not sure if I like these changes. I expect that almost all strings won't 
> begin with a newline and a majority won’t end with a newline. The new design 
> would require a leading backslash almost all the time and a trailing 
> backslash often, which is ugly:
> 
> let mystring = "““\
> text text
> text text\
> "““
> 
> -Thorsten
> 
> 
> > disagreed with this at first, but it made more sense as we thought about it 
> > more. There are a few things we like about it:
> >
> >   1. The rules and algorithm are simpler.
> >   2. It accommodates more coding styles.
> >   3. Every non-escaped newline in the literal now creates a 
> > corresponding newline in the resulting string.
> >   4. it's easy to get the old behavior back by backslashing the leading 
> > newline.
> >
> > Unfortunately, I think this precludes stripping the trailing newline by 
> > default, but I think this is ultimately a simpler and better approach than 
> > the previous draft.
> >
> > Other changes:
> >
> >   * We realized we needed to make closing delimiter matching a little 
> > more complicated if we wanted to allow one or two adjacent double-quote 
> > characters that were part of the literal's contents. Oops.
> >   * Tabs aren't actually allowed in ordinary string literals, so we now 
> > explicitly mention that as a difference between the two types.
> >   * We wrote some tests for the prototype (though they haven't been 
> > updated for this new version yet).
> >   * There were some other wording changes, particularly in the 
> > indentation stripping rationale, but nothing that affects the actual design.
> >
> > I understand John is working on a new version of his toolchain so people 
> > can play with the prototype. We hope to have that ready for you all soon.
> >
> > Let us know what you think of the revisions!
> >
> > --
> > Brent Royal-Gordon
> > Architechies
> >
> > ___
> > swift-evolution mailing list
> > swift-evolution@swift.org 
> > https://lists.swift.org/mailman/listinfo/swift-evolution 
> > 
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org 
> https://lists.swift.org/mailman/listinfo/swift-evolution 
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

___
swift-evolution mailing list
swift-evolution@swift.org

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

[Xiaodi Wu via swift-evolution]

Agree. I prefer the new rules over the old, but considering common use
cases, stripping the leading and trailing newline makes for a more pleasant
experience than not stripping either of them.

I think that is generally worth prioritizing over a simpler algorithm or
even accommodating more styles. Moreover, a user who wants a trailing or
leading newline merely types an extra one if there is newline stripping, so
no use cases are made difficult, only a very common one is made more
ergonomic.
On Wed, Apr 12, 2017 at 09:52 Thorsten Seitz via swift-evolution <
swift-evolution@swift.org> wrote:

> > Am 12.04.2017 um 15:40 schrieb Brent Royal-Gordon via swift-evolution <
> swift-evolution@swift.org>:
> >
> > 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
>
> Hmm, not sure if I like these changes. I expect that almost all strings
> won't begin with a newline and a majority won’t end with a newline. The new
> design would require a leading backslash almost all the time and a trailing
> backslash often, which is ugly:
>
> let mystring = "““\
> text text
> text text\
> "““
>
> -Thorsten
>
>
> > disagreed with this at first, but it made more sense as we thought about
> it more. There are a few things we like about it:
> >
> >   1. The rules and algorithm are simpler.
> >   2. It accommodates more coding styles.
> >   3. Every non-escaped newline in the literal now creates a
> corresponding newline in the resulting string.
> >   4. it's easy to get the old behavior back by backslashing the
> leading newline.
> >
> > Unfortunately, I think this precludes stripping the trailing newline by
> default, but I think this is ultimately a simpler and better approach than
> the previous draft.
> >
> > Other changes:
> >
> >   * We realized we needed to make closing delimiter matching a
> little more complicated if we wanted to allow one or two adjacent
> double-quote characters that were part of the literal's contents. Oops.
> >   * Tabs aren't actually allowed in ordinary string literals, so we
> now explicitly mention that as a difference between the two types.
> >   * We wrote some tests for the prototype (though they haven't been
> updated for this new version yet).
> >   * There were some other wording changes, particularly in the
> indentation stripping rationale, but nothing that affects the actual design.
> >
> > I understand John is working on a new version of his toolchain so people
> can play with the prototype. We hope to have that ready for you all soon.
> >
> > Let us know what you think of the revisions!
> >
> > --
> > Brent Royal-Gordon
> > Architechies
> >
> > ___
> > swift-evolution mailing list
> > swift-evolution@swift.org
> > https://lists.swift.org/mailman/listinfo/swift-evolution
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Ben Cohen via swift-evolution]

Hi Swift community,

Another proposal pitch. These operators were mentioned briefly in the String 
manifesto as prefixing/suffixing is very common with strings.

Online copy here: 
https://github.com/airspeedswift/swift-evolution/blob/71b819d30676c44234bac1aa61fc5c39bcf3/proposals/-OneSidedRanges.md
 

One-sided Ranges

Proposal: SE- 

Authors: Ben Cohen , Dave Abrahams 
, Brent Royal-Gordon 
Review Manager: TBD
Status: Awaiting review
Introduction

This proposal introduces the concept of a “one-sided” range, created via 
prefix/postfix versions of the existing range operators.

It also introduces a new protocol, RangeExpression, to simplify the creation of 
methods that take different kinds of ranges.

Motivation

It is common, given an index into a collection, to want a slice up to or from 
that index versus the start/end.

For example (assuming String is once more a Collection):

let s = "Hello, World!"
let i = s.index(where: ",")
let greeting = s[s.startIndex..)

NOTE: The following is subject to change depending on pending compiler 
features. Methods may actually be on underscored protocols, and then moved once 
recursive protocols are implemented. Types may be collapsed using conditional 
conformance. This should not matter from a usage perspective – users are not 
expected to use these types directly or override any of the behaviors in their 
own types. Any final implementation will follow the below in spirit if not in 
practice.

public protocol RangeExpression {
associatedtype Bound: Comparable

/// Returns `self` expressed as a range of indices within `collection`.
///
/// -Parameter collection: The collection `self` should be
///relative to.
///
/// -Returns: A `Range` suitable for slicing `collection`.
///   The return value is *not* guaranteed to be inside
///   its bounds. Callers should apply the same preconditions
///   to the return value as they would to a range provided
///   directly by the user.
func relative(to collection: C) -> Range where 
C.Index == Bound

func contains(_ element: Bound) -> Bool
}

extension RangeExpression {
  public static func ~= (pattern: Self, value: Bound) -> Bool
}

prefix operator ..<
public struct 

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

[Vladimir.S via swift-evolution]

On 12.04.2017 17:52, Thorsten Seitz via swift-evolution wrote:

Am 12.04.2017 um 15:40 schrieb Brent Royal-Gordon via swift-evolution 
:

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


Hmm, not sure if I like these changes. I expect that almost all strings won't 
begin with a newline and a majority won’t end with a newline. The new design 
would require a leading backslash almost all the time and a trailing backslash 
often, which is ugly:

let mystring = "““\
 text text
 text text\
 "““


Agree with Thorsten. This is just ugly syntax for commonly used case.
Why not simple rule that content of multi-line string is all lines *between* leading 
and trailing """ ? So, as was discussed, or you have single line """text""" or 
multiline, where opening and closing """ should be on separate lines with text, and 
text is lines strictly between.
Even more, I feel such solution will be more consistent, as trailing triple quotes 
does not inject \n symbol -> so leading """ also should not inject it. In this case 
""" is just a marker of start/end of multi-line string. Simple model, nice-looking 
code for common cases, can tune emitting of \n symbol as you wish. No?




-Thorsten



disagreed with this at first, but it made more sense as we thought about it 
more. There are a few things we like about it:

1. The rules and algorithm are simpler.
2. It accommodates more coding styles.
3. Every non-escaped newline in the literal now creates a corresponding 
newline in the resulting string.
4. it's easy to get the old behavior back by backslashing the leading 
newline.

Unfortunately, I think this precludes stripping the trailing newline by 
default, but I think this is ultimately a simpler and better approach than the 
previous draft.

Other changes:

* We realized we needed to make closing delimiter matching a little 
more complicated if we wanted to allow one or two adjacent double-quote 
characters that were part of the literal's contents. Oops.
* Tabs aren't actually allowed in ordinary string literals, so we now 
explicitly mention that as a difference between the two types.
* We wrote some tests for the prototype (though they haven't been 
updated for this new version yet).
* There were some other wording changes, particularly in the 
indentation stripping rationale, but nothing that affects the actual design.

I understand John is working on a new version of his toolchain so people can 
play with the prototype. We hope to have that ready for you all soon.

Let us know what you think of the revisions!

--
Brent Royal-Gordon
Architechies

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


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


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

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

[Thorsten Seitz via swift-evolution]

> Am 12.04.2017 um 15:40 schrieb Brent Royal-Gordon via swift-evolution 
> :
> 
> 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

Hmm, not sure if I like these changes. I expect that almost all strings won't 
begin with a newline and a majority won’t end with a newline. The new design 
would require a leading backslash almost all the time and a trailing backslash 
often, which is ugly:

let mystring = "““\
text text
text text\
"““

-Thorsten


> disagreed with this at first, but it made more sense as we thought about it 
> more. There are a few things we like about it:
> 
>   1. The rules and algorithm are simpler.
>   2. It accommodates more coding styles.
>   3. Every non-escaped newline in the literal now creates a corresponding 
> newline in the resulting string.
>   4. it's easy to get the old behavior back by backslashing the leading 
> newline.
> 
> Unfortunately, I think this precludes stripping the trailing newline by 
> default, but I think this is ultimately a simpler and better approach than 
> the previous draft.
> 
> Other changes:
> 
>   * We realized we needed to make closing delimiter matching a little 
> more complicated if we wanted to allow one or two adjacent double-quote 
> characters that were part of the literal's contents. Oops.
>   * Tabs aren't actually allowed in ordinary string literals, so we now 
> explicitly mention that as a difference between the two types.
>   * We wrote some tests for the prototype (though they haven't been 
> updated for this new version yet). 
>   * There were some other wording changes, particularly in the 
> indentation stripping rationale, but nothing that affects the actual design.
> 
> I understand John is working on a new version of his toolchain so people can 
> play with the prototype. We hope to have that ready for you all soon.
> 
> Let us know what you think of the revisions!
> 
> -- 
> Brent Royal-Gordon
> Architechies
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

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

[swift-evolution] Unify the way properties and methods work to make key-value coding more natural

[Andrey Volodin via swift-evolution]

Recently I’ve seen some upcoming changes for #keyPath, but the whole things 
look a bit messy to me. Today I came up with a simple idea of code generation, 
but I thought maybe it would be nice to make this a part of the language?

Look at this code:

public class Foo {
public var a: Int = 0
}

public final class Property {
public var `get`: (U) -> () -> V
public var `set`: (U) -> (V) -> Void

public init(getter: @escaping (U) -> () -> V, setter: @escaping (U) -> (V) 
-> Void) {
self.get = getter
self.set = setter
}
}

// Generated code
public extension Foo {
public static let a: Property = {
return Property(getter: { instance -> (Void) -> Int in
return { return instance.a} },
  setter: { instance -> (Int) -> Void in
return { value -> Void in 
instance.a = value } })
}()
}

let foo = Foo()
foo.a = 5

let _a = Foo.a.get(foo)()
print(_a)

Foo.a.set(foo)(10)
print(foo.a)

The idea is to make properties work the same way the methods work right now. 
That will allow things like tweening properties in the game engine, by simply 
passing the property to some sort of ActionManager.

Of course, this can be achieved by code-generator, but I bet this will be very 
ineffecient in terms of performance. 

The only draw back here from top of my head: It will be impossible to have 
instance- and static- variables with the same name. 

What do you think about this?___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Adrian Zubarev via swift-evolution]

I messed up the indent in the example, where is the corrected version:


let myReallyLongXMLConstantName = """



John Doe
XML Developer's Guide
Computer
44.95

\
"""


-- 
Adrian Zubarev
Sent with Airmail

Am 12. April 2017 um 16:05:59, Adrian Zubarev (adrian.zuba...@devandartist.com) 
schrieb:

Hi Brent, thank you for the hard work and the new revision. However I still 
would love to hear your opinion if we should drop the support for these kind of 
options:

"""Hello↵
world!"""

"""↵
Hello↵
world!"""

"""Hello↵
world!
"""
I tend to agree that it’s much simpler to only support a single line version 
and a version where the actual string is in between the delimiter lines but not 
directly after or before them. Personally I don’t think you would always want 
to indent your multi-line string that far to the right side.

let myReallyLongXMLConstantName = """
 

   John Doe
   XML Developer's Guide
   Computer
   44.95

 \
 """ 
Instead it’s easer and readable enough to write it like this:

let myReallyLongXMLConstantName = """



John Doe
XML Developer's Guide
Computer
44.95

\
""" 
The starting delimiter does not produce a new line, only each line in between 
does if not explicitly prevented with a backslash. If you’d wanted to add a new 
line at the top, you just simply add one or \n below the starting delimiter.



-- 
Adrian Zubarev
Sent with Airmail

Am 12. April 2017 um 15:40:26, Brent Royal-Gordon via swift-evolution 
(swift-evolution@swift.org) schrieb:

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 first, but it made more 
sense as we thought about it more. There are a few things we like about it:

1. The rules and algorithm are simpler.
2. It accommodates more coding styles.
3. Every non-escaped newline in the literal now creates a corresponding newline 
in the resulting string.
4. it's easy to get the old behavior back by backslashing the leading newline.

Unfortunately, I think this precludes stripping the trailing newline by 
default, but I think this is ultimately a simpler and better approach than the 
previous draft.

Other changes:

* We realized we needed to make closing delimiter matching a little more 
complicated if we wanted to allow one or two adjacent double-quote characters 
that were part of the literal's contents. Oops.
* Tabs aren't actually allowed in ordinary string literals, so we now 
explicitly mention that as a difference between the two types.
* We wrote some tests for the prototype (though they haven't been updated for 
this new version yet).
* There were some other wording changes, particularly in the indentation 
stripping rationale, but nothing that affects the actual design.

I understand John is working on a new version of his toolchain so people can 
play with the prototype. We hope to have that ready for you all soon.

Let us know what you think of the revisions!

--
Brent Royal-Gordon
Architechies

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

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

[Adrian Zubarev via swift-evolution]

It was simply a pitch ;) Adding comments it’s not important to me, but I 
thought it could simply work after the backlash.

And multi-line comments /**/ should work fine and are not ambiguous because 
they also have a clear single line purpose. Remember SE–0102 here public 
/*closed*/ enum Never { /*no values*/ }?

I wasn’t talking about escaping comments but allowing comments after the end of 
the current line of a multi-lined string which is explicitly annotated with a 
backslash.

If no one likes that pitch, fine I don’t I don’t want to pursue the idea then. 
;)



-- 
Adrian Zubarev
Sent with Airmail

Am 12. April 2017 um 15:43:04, Thorsten Seitz via swift-evolution 
(swift-evolution@swift.org) schrieb:


Am 12.04.2017 um 14:56 schrieb Xiaodi Wu :

Sure, but keep in mind you're ultimately presenting a long string to the user. 
Chances are if it needs commenting to the reader of the code, it needs 
commenting to the reader of the string (which could be code itself, whether a 
SQL query or something else).

Good point.


Can you give a use case where essentially you need two-tiered comments like 
this?

Nope, just thought that Adrian’s idea seemed useful and not detrimental.

Actually I’m fine with or without comments.

-Thorsten




On Wed, Apr 12, 2017 at 07:47 Thorsten Seitz via swift-evolution 
 wrote:
Am 12.04.2017 um 14:36 schrieb Ricardo Parada via swift-evolution 
:

I don't think I would use that. I don't find the aesthetics pleasant. 
I would rather comment above the string literal. 

It might be useful when many comments would be required where putting them in a 
bunch above the literal would make it difficult to properly correlate them with 
the respective pieces of the string.


Would the escape character cause the newline for the line to be ignored thereby 
continuing the string on the next line?

Yes. The semantics of the backslash should not change, its presence just opens 
the room for placing a comment.
To get a newline you would have to write \n\

let myString = "““
    text text\n\ // comment
    text text
    ““"

-Thorsten




On Apr 12, 2017, at 6:59 AM, Adrian Zubarev via swift-evolution 
 wrote:

One last pitch, can we allow comments in multi-line strings if the string is 
broken up by a backslash?


let myString = """
text text   
text text text \ // Comment allowed in the current line here, but not in 
the line above it
text text text \ /* this type of comment is fine too */
text text\// notice whitespace can be ignored
"""
You might have some interpolation and want to comment around it.

let foo = """
bar bar bar
bar \(x) bar\ // `x` does some magic
"""



-- 
Adrian Zubarev
Sent with Airmail

Am 12. April 2017 um 12:48:57, Adrian Zubarev (adrian.zuba...@devandartist.com) 
schrieb:

Actually I’m fine with such a compromise. Such a model has everything we’ve 
asked for, it’s easy, it has both leading and trailing precision and implicit 
new lines where needed.



-- 
Adrian Zubarev
Sent with Airmail

Am 12. April 2017 um 12:42:17, Vladimir.S via swift-evolution 
(swift-evolution@swift.org) schrieb:

On 12.04.2017 13:16, 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 convinced about the closing delimiter 
>> now. =)
>>
>> -
>>
>> If I understood correctly what Xiaodi Wu meant in his reply, then we could 
>> simplify
>> the whole multi-line string literal and also remove the need of disabling the
>> stripping algorithm.
>>
>> We should ban these examples completely:
>>
>> |"""Hello·world!"""|
>>
>
> Being able to use ""“ for single line strings containing lots of " is useful 
> in
> itself and explained in the motivational section of the proposal:
> "Tripled string literals can also do double duty as a syntax for handling 
> short
> string literals with many internal quotation marks“
>
> -Thorsten

Yes, I also think the single line string can be very useful and we should not
disallow it.

But I agree that we should disallow multi-line cases when we have text on the 
same
line with leading or trailing """ because this complicates the mental modal and 
adds
confusion points.

I.e. I suggest to allow only two forms:
1. Single line: """this is "just" text""" (no line end will be inserted)
2. Multiline, where leading and trailing """ has no text after/before them and 
*all*
the text is in lines *between* triple quotes:
"""
first line
second line
"""

One can use backslash at the line end to emulate all other needed cases. Like:

"""
first line \
second line\
"""

will produce "first line second line"

>
>> |"""Hello↵ world!""" |
>> |"""Hello↵ world!↵ """ |
>> |"""↵ Hello↵ world!""" |
>>
>> Instead 

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

[David Hart via swift-evolution]

I think I agree that the simplicity of the new rules outweigh the loss of the 
first newline’s automatic stripping. Good job!

> On 12 Apr 2017, at 15:40, Brent Royal-Gordon via swift-evolution 
>  wrote:
> 
> 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 first, but it made 
> more sense as we thought about it more. There are a few things we like about 
> it:
> 
>   1. The rules and algorithm are simpler.
>   2. It accommodates more coding styles.
>   3. Every non-escaped newline in the literal now creates a corresponding 
> newline in the resulting string.
>   4. it's easy to get the old behavior back by backslashing the leading 
> newline.
> 
> Unfortunately, I think this precludes stripping the trailing newline by 
> default, but I think this is ultimately a simpler and better approach than 
> the previous draft.
> 
> Other changes:
> 
>   * We realized we needed to make closing delimiter matching a little 
> more complicated if we wanted to allow one or two adjacent double-quote 
> characters that were part of the literal's contents. Oops.
>   * Tabs aren't actually allowed in ordinary string literals, so we now 
> explicitly mention that as a difference between the two types.
>   * We wrote some tests for the prototype (though they haven't been 
> updated for this new version yet). 
>   * There were some other wording changes, particularly in the 
> indentation stripping rationale, but nothing that affects the actual design.
> 
> I understand John is working on a new version of his toolchain so people can 
> play with the prototype. We hope to have that ready for you all soon.
> 
> Let us know what you think of the revisions!
> 
> -- 
> Brent Royal-Gordon
> Architechies
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

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

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

[Adrian Zubarev via swift-evolution]

Hi Brent, thank you for the hard work and the new revision. However I still 
would love to hear your opinion if we should drop the support for these kind of 
options:

"""Hello↵
world!"""

"""↵
Hello↵
world!"""

"""Hello↵
world!
"""
I tend to agree that it’s much simpler to only support a single line version 
and a version where the actual string is in between the delimiter lines but not 
directly after or before them. Personally I don’t think you would always want 
to indent your multi-line string that far to the right side.

let myReallyLongXMLConstantName = """
 

   John Doe
   XML Developer's Guide
   Computer
   44.95

 \
 """
Instead it’s easer and readable enough to write it like this:

let myReallyLongXMLConstantName = """



John Doe
XML Developer's Guide
Computer
44.95

\
"""
The starting delimiter does not produce a new line, only each line in between 
does if not explicitly prevented with a backslash. If you’d wanted to add a new 
line at the top, you just simply add one or \n below the starting delimiter.



-- 
Adrian Zubarev
Sent with Airmail

Am 12. April 2017 um 15:40:26, Brent Royal-Gordon via swift-evolution 
(swift-evolution@swift.org) schrieb:

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 first, but it made more 
sense as we thought about it more. There are a few things we like about it:

1. The rules and algorithm are simpler.
2. It accommodates more coding styles.
3. Every non-escaped newline in the literal now creates a corresponding newline 
in the resulting string.
4. it's easy to get the old behavior back by backslashing the leading newline.

Unfortunately, I think this precludes stripping the trailing newline by 
default, but I think this is ultimately a simpler and better approach than the 
previous draft.

Other changes:

* We realized we needed to make closing delimiter matching a little more 
complicated if we wanted to allow one or two adjacent double-quote characters 
that were part of the literal's contents. Oops.
* Tabs aren't actually allowed in ordinary string literals, so we now 
explicitly mention that as a difference between the two types.
* We wrote some tests for the prototype (though they haven't been updated for 
this new version yet).  
* There were some other wording changes, particularly in the indentation 
stripping rationale, but nothing that affects the actual design.

I understand John is working on a new version of his toolchain so people can 
play with the prototype. We hope to have that ready for you all soon.

Let us know what you think of the revisions!

--  
Brent Royal-Gordon
Architechies

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

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

[Brent Royal-Gordon via swift-evolution]

> 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 actually think embedded comments would be super-cool and really useful. We 
have them for regular expressions in Perl 5 (I actually obliquely referenced 
the "/x" modifier used to enable them in this proposal) and they're really 
handy there.

But I think they would need to be an opt-in feature, because you won't usually 
want them, and I think they would be much more complicated to add than the rest 
of what we're proposing. (Remember, we need to tell Xcode where our comments 
are--what will it do if it's told there's a comment in the middle of a string 
literal?) So I think we're better off leaving that feature for later.

-- 
Brent Royal-Gordon
Architechies

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

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

[Matthew Johnson via swift-evolution]

> On Apr 12, 2017, at 8:40 AM, Brent Royal-Gordon via swift-evolution 
>  wrote:
> 
> 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 first, but it made 
> more sense as we thought about it more. There are a few things we like about 
> it:
> 
>   1. The rules and algorithm are simpler.
>   2. It accommodates more coding styles.
>   3. Every non-escaped newline in the literal now creates a corresponding 
> newline in the resulting string.
>   4. it's easy to get the old behavior back by backslashing the leading 
> newline.
> 
> Unfortunately, I think this precludes stripping the trailing newline by 
> default, but I think this is ultimately a simpler and better approach than 
> the previous draft.
> 
> Other changes:
> 
>   * We realized we needed to make closing delimiter matching a little 
> more complicated if we wanted to allow one or two adjacent double-quote 
> characters that were part of the literal's contents. Oops.
>   * Tabs aren't actually allowed in ordinary string literals, so we now 
> explicitly mention that as a difference between the two types.
>   * We wrote some tests for the prototype (though they haven't been 
> updated for this new version yet). 
>   * There were some other wording changes, particularly in the 
> indentation stripping rationale, but nothing that affects the actual design.
> 
> I understand John is working on a new version of his toolchain so people can 
> play with the prototype. We hope to have that ready for you all soon.
> 
> Let us know what you think of the revisions!

I haven’t formally reviewed this proposal but have been following the thread.  
I generally like this proposal quite a bit.  I have used multi-line strings 
quite a bit in other languages and this proposal does a really nice job of 
avoiding the small annoyances I’ve encountered.  Thanks for your hard work!  +1 

> 
> -- 
> Brent Royal-Gordon
> Architechies
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

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

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

[Thorsten Seitz via swift-evolution]

> Am 12.04.2017 um 14:56 schrieb Xiaodi Wu :
> 
> Sure, but keep in mind you're ultimately presenting a long string to the 
> user. Chances are if it needs commenting to the reader of the code, it needs 
> commenting to the reader of the string (which could be code itself, whether a 
> SQL query or something else).

Good point.


> Can you give a use case where essentially you need two-tiered comments like 
> this?

Nope, just thought that Adrian’s idea seemed useful and not detrimental.

Actually I’m fine with or without comments.

-Thorsten


> 
> 
> On Wed, Apr 12, 2017 at 07:47 Thorsten Seitz via swift-evolution 
> > wrote:
>> Am 12.04.2017 um 14:36 schrieb Ricardo Parada via swift-evolution 
>> >:
>> 
>> I don't think I would use that. I don't find the aesthetics pleasant. 
>> I would rather comment above the string literal. 
> 
> It might be useful when many comments would be required where putting them in 
> a bunch above the literal would make it difficult to properly correlate them 
> with the respective pieces of the string.
> 
>> 
>> Would the escape character cause the newline for the line to be ignored 
>> thereby continuing the string on the next line?
> 
> Yes. The semantics of the backslash should not change, its presence just 
> opens the room for placing a comment.
> To get a newline you would have to write \n\
> 
> let myString = "““
> text text\n\ // comment
> text text
> ““"
> 
> -Thorsten
> 
>> 
>> 
>> 
>> On Apr 12, 2017, at 6:59 AM, Adrian Zubarev via swift-evolution 
>> > wrote:
>> 
>>> One last pitch, can we allow comments in multi-line strings if the string 
>>> is broken up by a backslash?
>>> 
>>> 
>>> let myString = """
>>> text text  
>>> text text text \ // Comment allowed in the current line here, but not 
>>> in the line above it
>>> text text text \ /* this type of comment is fine too */
>>> text text\// notice whitespace can be ignored
>>> """
>>> You might have some interpolation and want to comment around it.
>>> 
>>> let foo = """
>>> bar bar bar
>>> bar \(x) bar\ // `x` does some magic
>>> """
>>> 
>>> 
>>> 
>>> -- 
>>> Adrian Zubarev
>>> Sent with Airmail
>>> 
>>> Am 12. April 2017 um 12:48:57, Adrian Zubarev 
>>> (adrian.zuba...@devandartist.com ) 
>>> schrieb:
>>> 
 Actually I’m fine with such a compromise. Such a model has everything 
 we’ve asked for, it’s easy, it has both leading and trailing precision and 
 implicit new lines where needed.
 
 
 
 -- 
 Adrian Zubarev
 Sent with Airmail
 
 Am 12. April 2017 um 12:42:17, Vladimir.S via swift-evolution 
 (swift-evolution@swift.org ) schrieb:
 
> On 12.04.2017 13:16, 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 convinced about the closing 
> >> delimiter now. =)
> >>
> >> -
> >>
> >> If I understood correctly what Xiaodi Wu meant in his reply, then we 
> >> could simplify
> >> the whole multi-line string literal and also remove the need of 
> >> disabling the
> >> stripping algorithm.
> >>
> >> We should ban these examples completely:
> >>
> >> |"""Hello·world!"""|
> >>
> >
> > Being able to use ""“ for single line strings containing lots of " is 
> > useful in
> > itself and explained in the motivational section of the proposal:
> > "Tripled string literals can also do double duty as a syntax for 
> > handling short
> > string literals with many internal quotation marks“
> >
> > -Thorsten
> 
> Yes, I also think the single line string can be very useful and we should 
> not
> disallow it.
> 
> But I agree that we should disallow multi-line cases when we have text on 
> the same
> line with leading or trailing """ because this complicates the mental 
> modal and adds
> confusion points.
> 
> I.e. I suggest to allow only two forms:
> 1. Single line: """this is "just" text""" (no line end will be inserted)
> 2. Multiline, where leading and trailing """ has no text after/before 
> them and *all*
> the text is in lines *between* triple quotes:
> """
> first line
> second line
> """
> 
> One can use backslash at the line end to emulate all other needed cases. 
> Like:
> 
> """
> first line \

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

[Vladimir.S via swift-evolution]

On 12.04.2017 15:59, 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.


Let's not over-engineer this and end up with feature creep. A simple multi-line 
string that takes its contents more or less verbatim (with the exception of necessary 
escapes, interpolation, and dedenting) is fine.


Agree. Even more, we can have comments on separate lines:

var s = """
text
text

// value will be inserted here
+ """
value : \(value)

// other comment
+ """
text
text
"""

On Wed, Apr 12, 2017 at 5:50 AM Xiaodi Wu via swift-evolution 
> wrote:


Right, I think it might be too much.

Consider that the multi-line literal could be code with comments in it, but 
that
you could also escape and embed an actual multi-line comment with \ /* */ 
that
isn't part of the multi-line literal code with multi-line comments! How 
confusing!
On Wed, Apr 12, 2017 at 07:36 Ricardo Parada via swift-evolution
> wrote:

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 swift-evolution
> wrote:


One last pitch, can we allow comments in multi-line strings if the 
string
is broken up by a backslash?

|let myString = """ text text text text text \ // Comment allowed in the
current line here, but not in the line above it text text text \ /* this
type of comment is fine too */ text text\// notice whitespace can be
ignored """ |

You might have some interpolation and want to comment around it.

|let foo = """ bar bar bar bar \(x) bar\ // `x` does some magic """ |



-- 
Adrian Zubarev

Sent with Airmail

Am 12. April 2017 um 12:48:57, Adrian Zubarev
(adrian.zuba...@devandartist.com 
)
schrieb:


Actually I’m fine with such a compromise. Such a model has everything
we’ve asked for, it’s easy, it has both leading and trailing precision 
and
implicit new lines where needed.



-- 
Adrian Zubarev

Sent with Airmail

Am 12. April 2017 um 12:42:17, Vladimir.S via swift-evolution
(swift-evolution@swift.org ) schrieb:


On 12.04.2017 13:16, 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 convinced about the closing 
delimiter now. =)
>>
>> 
-
>>
>> If I understood correctly what Xiaodi Wu meant in his reply, then we 
could simplify
>> the whole multi-line string literal and also remove the need of 
disabling the
>> stripping algorithm.
>>
>> We should ban these examples completely:
>>
>> |"""Hello·world!"""|
>>
>
> Being able to use ""“ for single line strings containing lots of " is 
useful in
> itself and explained in the motivational section of the proposal:
> "Tripled string literals can also do double duty as a syntax for 
handling short
> string literals with many internal quotation marks“
>
> -Thorsten

Yes, I also think the single line string can be very useful and we 
should not
disallow it.

But I agree that we should disallow multi-line cases when we have text 
on
the same
line with leading or trailing """ because this complicates the mental
modal and adds
confusion points.

I.e. I suggest to allow only two forms:
1. Single line: """this is "just" text""" (no line end will be inserted)
2. Multiline, where leading and trailing """ has no text after/before
them and *all*
the text is in lines *between* triple quotes:
"""
first line
second line
"""

One can use backslash at the line end to emulate all other needed cases.
Like:

"""
first line \
second line\
"""

  

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

[Brent Royal-Gordon via swift-evolution]

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 first, but it made more 
sense as we thought about it more. There are a few things we like about it:

1. The rules and algorithm are simpler.
2. It accommodates more coding styles.
3. Every non-escaped newline in the literal now creates a corresponding 
newline in the resulting string.
4. it's easy to get the old behavior back by backslashing the leading 
newline.

Unfortunately, I think this precludes stripping the trailing newline by 
default, but I think this is ultimately a simpler and better approach than the 
previous draft.

Other changes:

* We realized we needed to make closing delimiter matching a little 
more complicated if we wanted to allow one or two adjacent double-quote 
characters that were part of the literal's contents. Oops.
* Tabs aren't actually allowed in ordinary string literals, so we now 
explicitly mention that as a difference between the two types.
* We wrote some tests for the prototype (though they haven't been 
updated for this new version yet). 
* There were some other wording changes, particularly in the 
indentation stripping rationale, but nothing that affects the actual design.

I understand John is working on a new version of his toolchain so people can 
play with the prototype. We hope to have that ready for you all soon.

Let us know what you think of the revisions!

-- 
Brent Royal-Gordon
Architechies

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

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

[Vladimir.S via swift-evolution]

On 12.04.2017 15:35, Xiaodi Wu wrote:
As I explained on Twitter, the behavior is initially counterintuitive but in many 
ways the least surprising result.


(First, you are incorrect about P requiring a mutable property. That is not what var 
means in a protocol.)


Yes, sorry, my mistake. But actually this does not change anything for this 
example:

protocol P {
var value : Int32 {get set} // get+set
}

extension P {
var value : Int32 {get{return 10} set{}}
}

class C : P {
let value : Int = 4_000_000_000 // let constant
}




However, you are right that two properties named value are being allowed. It seems 
strange at first but consider:


Given: a protocol P with only one requirement, but with a default implementation for 
that requirement. One would expect that any type T could retroactively conform to P. 
After all, either T has its own implementation of the requirement or it does not.


If the requirement is a property and not a method, and T has an identically named but 
not identically typed property, we allow this sort of "overloading" which is very 
much like overloading on the return type. This fulfills the expectation above that T 
can conform to P. Even requiring a warning in this scenario would break retroactive 
conformance.


The behavior at the call site is not harmful. A user of T may or may not see that it 
conforms to P. This is because conformance can be retroactive. Thus, when using an 
instance of T, references to the property are to T's own implementation. However, if 
the user can see P and the conformance T : P, they can always explicitly request P's 
differently typed implementation explicitly by using "as" (just like selecting an 
overloaded method with a different return type).


The behavior that is unexpected and potentially harmful is for the author of a type T 
trying to conform to P. It falls into the category of near-misses that includes 
unintentional typos in method names, etc. It is no more surprising than any of those 
cases where you, say, get the argument label spelled slightly wrong and end up 
without an intended override of a default implementation but two methods instead.


Not agree here. We *can* have methods with the same name but different 
argument/result type defined in the *same* type.

But we can't have property with the same name but different type in the same 
type.



As mentioned earlier on this list, the user experience of writing a conforming type 
is suboptimal, and there are likely to be clever ways for the compiler or other tools 
to help. However, ripping out type inference or breaking retroactive conformance is 
not the way forward to solving this issue.


I agree that retroactive conformance is important feature, but in this particular 
case, the situation IMO is not the same as with near-miss for methods.


And actually I still believe that such near-miss(even for methods) will be usually an 
hidden/delayed error, when user do expect that type's methods/props will conform the 
type to protocol, not protocol's default method. And I do believe that be able to 
prevent such error is more important than no-worry retroactive conformance. (and then 
spent a number of hours to debug such hard-to-find bug)


Plus, if we *want* we can suggest a way to silence such warning even for retroactive 
conformance. The question if the problem worth to be solved.


On Wed, Apr 12, 2017 at 05:15 Vladimir.S via swift-evolution 
> wrote:


On 12.04.2017 7:19, Jaden Geller wrote:
 >
 >> On Apr 7, 2017, at 4:07 AM, Vladimir.S via swift-evolution
 >> 
>> 
wrote:
 >>
 >> On 07.04.2017 10:21, Daniel Duan via swift-evolution wrote:
 >>> Hi all,
 >>>
 >>> In a discussion about inferring parameter types from default value,
 >>> Slava brought up some performance problems caused by type inference for
 >>> stored properties in side types:
 >>>
 >>>

https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170313/033882.html
 >>>
 >>> Towards the end, the post mentioned that some Swift team members
 >>> contemplated requiring types for stored properties in type 
declarations.
 >>> I think this idea deserves some more attention. Hence this last minute
 >>> idea-floating.
 >>>
 >>> In addition to solving a performance headache in implementation,
 >>> there're always the general benefit of making type declartion more
 >>> explicit and readable (clarity for reader should out-weigh pleasure of
 >>> the author). Making the language slightly more consistent (we are not
 >>> inferring types for default parameter values in function anyways).
 >>>
 >>> The cons for doing this are obvious too: the inference makes the
 >>> language feels more friendly 

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

[Ricardo Parada via swift-evolution]

> 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, and the need to define some 
>>> boundary (for symbol visibility reasons).  Saying that extensions to a type 
>>> have access to private members if they are in the same module is just as 
>>> arbitrary as limiting it to a single file, and a whole lot less useful from 
>>> the “reasoning about a type” perspective.
>> 
>> I think you misunderstand. We were talking about two extensions of a type, 
>> in a different file from the type, to share private members between 
>> themselves.
>> 
>> Doug Gregor mentioned it during the PR process and we added an example to 
>> disallow it, but in hindsight, I think it should be allowed.
> 
> Ah, you’re saying:
> 
> a.swift:
> struct X {}
> 
> b.swift:
> extension X {
>   private func f() {}
> }
> 
> extension X {
>   func g() { f() }
> }
> 
> If so, then yes, I agree we should accept that.
> 
> -Chris

That would remove the objection I had. It would make the first half and the 
second half of the proposal consistent. ___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Tony Allevato via swift-evolution]

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.

Let's not over-engineer this and end up with feature creep. A simple
multi-line string that takes its contents more or less verbatim (with the
exception of necessary escapes, interpolation, and dedenting) is fine.
On Wed, Apr 12, 2017 at 5:50 AM Xiaodi Wu via swift-evolution <
swift-evolution@swift.org> wrote:

> Right, I think it might be too much.
>
> Consider that the multi-line literal could be code with comments in it,
> but that you could also escape and embed an actual multi-line comment with
> \ /* */ that isn't part of the multi-line literal code with multi-line
> comments! How confusing!
> On Wed, Apr 12, 2017 at 07:36 Ricardo Parada via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> 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 swift-evolution <
> swift-evolution@swift.org> wrote:
>
> One last pitch, can we allow comments in multi-line strings if the string
> is broken up by a backslash?
>
>
> let myString = """
> text text
> text text text \ // Comment allowed in the current line here, but not in 
> the line above it
> text text text \ /* this type of comment is fine too */
> text text\// notice whitespace can be ignored
> """
>
> You might have some interpolation and want to comment around it.
>
> let foo = """
> bar bar bar
> bar \(x) bar\ // `x` does some magic
> """
>
>
>
> --
> Adrian Zubarev
> Sent with Airmail
>
> Am 12. April 2017 um 12:48:57, Adrian Zubarev (
> adrian.zuba...@devandartist.com) schrieb:
>
> Actually I’m fine with such a compromise. Such a model has everything
> we’ve asked for, it’s easy, it has both leading and trailing precision and
> implicit new lines where needed.
>
>
> --
> Adrian Zubarev
> Sent with Airmail
>
> Am 12. April 2017 um 12:42:17, Vladimir.S via swift-evolution (
> swift-evolution@swift.org) schrieb:
>
> On 12.04.2017 13:16, 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 convinced about the closing
> delimiter now. =)
> >>
> >>
> -
> >>
> >> If I understood correctly what Xiaodi Wu meant in his reply, then we
> could simplify
> >> the whole multi-line string literal and also remove the need of
> disabling the
> >> stripping algorithm.
> >>
> >> We should ban these examples completely:
> >>
> >> |"""Hello·world!"""|
> >>
> >
> > Being able to use ""“ for single line strings containing lots of " is
> useful in
> > itself and explained in the motivational section of the proposal:
> > "Tripled string literals can also do double duty as a syntax for
> handling short
> > string literals with many internal quotation marks“
> >
> > -Thorsten
>
> Yes, I also think the single line string can be very useful and we should
> not
> disallow it.
>
> But I agree that we should disallow multi-line cases when we have text on
> the same
> line with leading or trailing """ because this complicates the mental
> modal and adds
> confusion points.
>
> I.e. I suggest to allow only two forms:
> 1. Single line: """this is "just" text""" (no line end will be inserted)
> 2. Multiline, where leading and trailing """ has no text after/before them
> and *all*
> the text is in lines *between* triple quotes:
> """
> first line
> second line
> """
>
> One can use backslash at the line end to emulate all other needed cases.
> Like:
>
> """
> first line \
> second line\
> """
>
> will produce "first line second line"
>
> >
> >> |"""Hello↵ world!""" |
> >> |"""Hello↵ world!↵ """ |
> >> |"""↵ Hello↵ world!""" |
> >>
> >> Instead an empty multi-line string literal would look like this:
> >>
> >> |"""↵ """ |
> >>
> >> To fix the above example you’d need to write it like this:
> >>
> >> |"""↵ Hello·world!\↵ """ |
> >> |"""↵ Hello↵ world!\↵ """ |
> >>
> >> * Each line in between the delimiters would add implicit new lines if
> not
> >> disabled by a backslash.
> >> * The trailing precision is also handled by the backslash.
> >> * The indent is handled by the closing delimiter.
> >> * It’s easier to learn/teach.
> >> * It’s easier to read, because most of the time the line where the
> starting
> >> delimiter is, is filled with some other code.
> >>
> >> |let myString = """↵ ⇥ ⇥ Hello↵ ⇥ ⇥ world!\↵ ⇥ ⇥ """ |
> >>
> >> Now that would be a true multi-line string literal which needs at least
> two lines
> >> 

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

[Xiaodi Wu via swift-evolution]

Sure, but keep in mind you're ultimately presenting a long string to the
user. Chances are if it needs commenting to the reader of the code, it
needs commenting to the reader of the string (which could be code itself,
whether a SQL query or something else). Can you give a use case where
essentially you need two-tiered comments like this?


On Wed, Apr 12, 2017 at 07:47 Thorsten Seitz via swift-evolution <
swift-evolution@swift.org> wrote:

> Am 12.04.2017 um 14:36 schrieb Ricardo Parada via swift-evolution <
> swift-evolution@swift.org>:
>
> I don't think I would use that. I don't find the aesthetics pleasant.
> I would rather comment above the string literal.
>
>
> It might be useful when many comments would be required where putting them
> in a bunch above the literal would make it difficult to properly correlate
> them with the respective pieces of the string.
>
>
> Would the escape character cause the newline for the line to be ignored
> thereby continuing the string on the next line?
>
>
> Yes. The semantics of the backslash should not change, its presence just
> opens the room for placing a comment.
> To get a newline you would have to write \n\
>
> let myString = "““
> text text\n\ // comment
> text text
> ““"
>
> -Thorsten
>
>
>
>
> On Apr 12, 2017, at 6:59 AM, Adrian Zubarev via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> One last pitch, can we allow comments in multi-line strings if the string
> is broken up by a backslash?
>
>
> let myString = """
> text text
> text text text \ // Comment allowed in the current line here, but not in 
> the line above it
> text text text \ /* this type of comment is fine too */
> text text\// notice whitespace can be ignored
> """
>
> You might have some interpolation and want to comment around it.
>
> let foo = """
> bar bar bar
> bar \(x) bar\ // `x` does some magic
> """
>
>
>
>
> --
> Adrian Zubarev
> Sent with Airmail
>
> Am 12. April 2017 um 12:48:57, Adrian Zubarev (
> adrian.zuba...@devandartist.com) schrieb:
>
> Actually I’m fine with such a compromise. Such a model has everything
> we’ve asked for, it’s easy, it has both leading and trailing precision and
> implicit new lines where needed.
>
>
> --
> Adrian Zubarev
> Sent with Airmail
>
> Am 12. April 2017 um 12:42:17, Vladimir.S via swift-evolution (
> swift-evolution@swift.org) schrieb:
>
> On 12.04.2017 13:16, 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 convinced about the closing
> delimiter now. =)
> >>
> >>
> -
> >>
> >> If I understood correctly what Xiaodi Wu meant in his reply, then we
> could simplify
> >> the whole multi-line string literal and also remove the need of
> disabling the
> >> stripping algorithm.
> >>
> >> We should ban these examples completely:
> >>
> >> |"""Hello·world!"""|
> >>
> >
> > Being able to use ""“ for single line strings containing lots of " is
> useful in
> > itself and explained in the motivational section of the proposal:
> > "Tripled string literals can also do double duty as a syntax for
> handling short
> > string literals with many internal quotation marks“
> >
> > -Thorsten
>
> Yes, I also think the single line string can be very useful and we should
> not
> disallow it.
>
> But I agree that we should disallow multi-line cases when we have text on
> the same
> line with leading or trailing """ because this complicates the mental
> modal and adds
> confusion points.
>
> I.e. I suggest to allow only two forms:
> 1. Single line: """this is "just" text""" (no line end will be inserted)
> 2. Multiline, where leading and trailing """ has no text after/before them
> and *all*
> the text is in lines *between* triple quotes:
> """
> first line
> second line
> """
>
> One can use backslash at the line end to emulate all other needed cases.
> Like:
>
> """
> first line \
> second line\
> """
>
> will produce "first line second line"
>
> >
> >> |"""Hello↵ world!""" |
> >> |"""Hello↵ world!↵ """ |
> >> |"""↵ Hello↵ world!""" |
> >>
> >> Instead an empty multi-line string literal would look like this:
> >>
> >> |"""↵ """ |
> >>
> >> To fix the above example you’d need to write it like this:
> >>
> >> |"""↵ Hello·world!\↵ """ |
> >> |"""↵ Hello↵ world!\↵ """ |
> >>
> >> * Each line in between the delimiters would add implicit new lines if
> not
> >> disabled by a backslash.
> >> * The trailing precision is also handled by the backslash.
> >> * The indent is handled by the closing delimiter.
> >> * It’s easier to learn/teach.
> >> * It’s easier to read, because most of the time the line where the
> starting
> >> delimiter is, is filled with some other code.
> >>
> >> |let myString = """↵ ⇥ ⇥ Hello↵ ⇥ ⇥ world!\↵ ⇥ ⇥ """ |

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

[Xiaodi Wu via swift-evolution]

Right, I think it might be too much.

Consider that the multi-line literal could be code with comments in it, but
that you could also escape and embed an actual multi-line comment with \ /*
*/ that isn't part of the multi-line literal code with multi-line comments!
How confusing!
On Wed, Apr 12, 2017 at 07:36 Ricardo Parada via swift-evolution <
swift-evolution@swift.org> wrote:

> 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 swift-evolution <
> swift-evolution@swift.org> wrote:
>
> One last pitch, can we allow comments in multi-line strings if the string
> is broken up by a backslash?
>
>
> let myString = """
> text text
> text text text \ // Comment allowed in the current line here, but not in 
> the line above it
> text text text \ /* this type of comment is fine too */
> text text\// notice whitespace can be ignored
> """
>
> You might have some interpolation and want to comment around it.
>
> let foo = """
> bar bar bar
> bar \(x) bar\ // `x` does some magic
> """
>
>
>
> --
> Adrian Zubarev
> Sent with Airmail
>
> Am 12. April 2017 um 12:48:57, Adrian Zubarev (
> adrian.zuba...@devandartist.com) schrieb:
>
> Actually I’m fine with such a compromise. Such a model has everything
> we’ve asked for, it’s easy, it has both leading and trailing precision and
> implicit new lines where needed.
>
>
> --
> Adrian Zubarev
> Sent with Airmail
>
> Am 12. April 2017 um 12:42:17, Vladimir.S via swift-evolution (
> swift-evolution@swift.org) schrieb:
>
> On 12.04.2017 13:16, 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 convinced about the closing
> delimiter now. =)
> >>
> >>
> -
> >>
> >> If I understood correctly what Xiaodi Wu meant in his reply, then we
> could simplify
> >> the whole multi-line string literal and also remove the need of
> disabling the
> >> stripping algorithm.
> >>
> >> We should ban these examples completely:
> >>
> >> |"""Hello·world!"""|
> >>
> >
> > Being able to use ""“ for single line strings containing lots of " is
> useful in
> > itself and explained in the motivational section of the proposal:
> > "Tripled string literals can also do double duty as a syntax for
> handling short
> > string literals with many internal quotation marks“
> >
> > -Thorsten
>
> Yes, I also think the single line string can be very useful and we should
> not
> disallow it.
>
> But I agree that we should disallow multi-line cases when we have text on
> the same
> line with leading or trailing """ because this complicates the mental
> modal and adds
> confusion points.
>
> I.e. I suggest to allow only two forms:
> 1. Single line: """this is "just" text""" (no line end will be inserted)
> 2. Multiline, where leading and trailing """ has no text after/before them
> and *all*
> the text is in lines *between* triple quotes:
> """
> first line
> second line
> """
>
> One can use backslash at the line end to emulate all other needed cases.
> Like:
>
> """
> first line \
> second line\
> """
>
> will produce "first line second line"
>
> >
> >> |"""Hello↵ world!""" |
> >> |"""Hello↵ world!↵ """ |
> >> |"""↵ Hello↵ world!""" |
> >>
> >> Instead an empty multi-line string literal would look like this:
> >>
> >> |"""↵ """ |
> >>
> >> To fix the above example you’d need to write it like this:
> >>
> >> |"""↵ Hello·world!\↵ """ |
> >> |"""↵ Hello↵ world!\↵ """ |
> >>
> >> * Each line in between the delimiters would add implicit new lines if
> not
> >> disabled by a backslash.
> >> * The trailing precision is also handled by the backslash.
> >> * The indent is handled by the closing delimiter.
> >> * It’s easier to learn/teach.
> >> * It’s easier to read, because most of the time the line where the
> starting
> >> delimiter is, is filled with some other code.
> >>
> >> |let myString = """↵ ⇥ ⇥ Hello↵ ⇥ ⇥ world!\↵ ⇥ ⇥ """ |
> >>
> >> Now that would be a true multi-line string literal which needs at least
> two lines
> >> of code. If you’d need a single line literal,|""|is the obvious pick.
> >>
> >>
> >>
> >>
> >> --
> >> Adrian Zubarev
> >> Sent with Airmail
> >>
> >> Am 12. April 2017 um 02:32:33, Brent Royal-Gordon (
> br...@architechies.com
> >> >) schrieb:
> >>
> >>>
>  On Apr 11, 2017, at 8:08 AM, Adrian Zubarev via swift-evolution
>   >> wrote:
> 
>  That’s also the example that 

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

[Lucas Neiva via swift-evolution]

I think it’s worth thinking about, clarifying, and possibly documenting where 
inference happens and where it doesn’t.

As mentioned, there are limits to inference. Some of those limits are imposed 
by design, as in functions (check out F# to have your mind blown by how far 
type inference goes there).

- Type inference of function-local variable declarations is not the topic here. 
Everybody loves that :-D.

- For properties there are some levels to it, depending on the initial value:
  - [inferred] Literals (String, Int, ...)
  - [inferred] Constructor call, e.g. `Foo(a, b)`
  - [inferred] Function call without generics, e.g. `someFunc()`
  - [inferred] Function call with generics, e.g. 
`someArray.map(someGenericFunc)` (I believe this triggered the discussion, as 
it can cause performance issues)
  - [NOT inferred] Function call with AMBIGUOUS types (impossible to infer)
  - [NOT inferred] Closure, e.g. `{ /* do some stuff */ return /* some initial 
value */ }()`

- Computed properties, where currently the type is NOT inferred


- I’m unsure about how global properties are implemented, but I think the 
inference behaviour is the same there.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Thorsten Seitz via swift-evolution]

> Am 12.04.2017 um 14:36 schrieb Ricardo Parada via swift-evolution 
> :
> 
> I don't think I would use that. I don't find the aesthetics pleasant. 
> I would rather comment above the string literal. 

It might be useful when many comments would be required where putting them in a 
bunch above the literal would make it difficult to properly correlate them with 
the respective pieces of the string.

> 
> Would the escape character cause the newline for the line to be ignored 
> thereby continuing the string on the next line?

Yes. The semantics of the backslash should not change, its presence just opens 
the room for placing a comment.
To get a newline you would have to write \n\

let myString = "““
text text\n\ // comment
text text
““"

-Thorsten

> 
> 
> 
> On Apr 12, 2017, at 6:59 AM, Adrian Zubarev via swift-evolution 
> > wrote:
> 
>> One last pitch, can we allow comments in multi-line strings if the string is 
>> broken up by a backslash?
>> 
>> 
>> let myString = """
>> text text  
>> text text text \ // Comment allowed in the current line here, but not in 
>> the line above it
>> text text text \ /* this type of comment is fine too */
>> text text\// notice whitespace can be ignored
>> """
>> You might have some interpolation and want to comment around it.
>> 
>> let foo = """
>> bar bar bar
>> bar \(x) bar\ // `x` does some magic
>> """
>> 
>> 
>> 
>> -- 
>> Adrian Zubarev
>> Sent with Airmail
>> 
>> Am 12. April 2017 um 12:48:57, Adrian Zubarev 
>> (adrian.zuba...@devandartist.com ) 
>> schrieb:
>> 
>>> Actually I’m fine with such a compromise. Such a model has everything we’ve 
>>> asked for, it’s easy, it has both leading and trailing precision and 
>>> implicit new lines where needed.
>>> 
>>> 
>>> 
>>> -- 
>>> Adrian Zubarev
>>> Sent with Airmail
>>> 
>>> Am 12. April 2017 um 12:42:17, Vladimir.S via swift-evolution 
>>> (swift-evolution@swift.org ) schrieb:
>>> 
 On 12.04.2017 13:16, 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 convinced about the closing 
 >> delimiter now. =)
 >>
 >> -
 >>
 >> If I understood correctly what Xiaodi Wu meant in his reply, then we 
 >> could simplify
 >> the whole multi-line string literal and also remove the need of 
 >> disabling the
 >> stripping algorithm.
 >>
 >> We should ban these examples completely:
 >>
 >> |"""Hello·world!"""|
 >>
 >
 > Being able to use ""“ for single line strings containing lots of " is 
 > useful in
 > itself and explained in the motivational section of the proposal:
 > "Tripled string literals can also do double duty as a syntax for 
 > handling short
 > string literals with many internal quotation marks“
 >
 > -Thorsten
 
 Yes, I also think the single line string can be very useful and we should 
 not
 disallow it.
 
 But I agree that we should disallow multi-line cases when we have text on 
 the same
 line with leading or trailing """ because this complicates the mental 
 modal and adds
 confusion points.
 
 I.e. I suggest to allow only two forms:
 1. Single line: """this is "just" text""" (no line end will be inserted)
 2. Multiline, where leading and trailing """ has no text after/before them 
 and *all*
 the text is in lines *between* triple quotes:
 """
 first line
 second line
 """
 
 One can use backslash at the line end to emulate all other needed cases. 
 Like:
 
 """
 first line \
 second line\
 """
 
 will produce "first line second line"
 
 >
 >> |"""Hello↵ world!""" |
 >> |"""Hello↵ world!↵ """ |
 >> |"""↵ Hello↵ world!""" |
 >>
 >> Instead an empty multi-line string literal would look like this:
 >>
 >> |"""↵ """ |
 >>
 >> To fix the above example you’d need to write it like this:
 >>
 >> |"""↵ Hello·world!\↵ """ |
 >> |"""↵ Hello↵ world!\↵ """ |
 >>
 >> * Each line in between the delimiters would add implicit new lines if 
 >> not
 >> disabled by a backslash.
 >> * The trailing precision is also handled by the backslash.
 >> * The indent is handled by the closing delimiter.
 >> * It’s easier to learn/teach.
 >> * It’s easier to read, because most of the time the line where the 
 >> starting
 >> delimiter is, is filled with some other code.
 >>

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

[Ricardo Parada via swift-evolution]

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 swift-evolution 
>  wrote:
> 
> One last pitch, can we allow comments in multi-line strings if the string is 
> broken up by a backslash?
> 
> 
> let myString = """
> text text  
> text text text \ // Comment allowed in the current line here, but not in 
> the line above it
> text text text \ /* this type of comment is fine too */
> text text\// notice whitespace can be ignored
> """
> You might have some interpolation and want to comment around it.
> 
> let foo = """
> bar bar bar
> bar \(x) bar\ // `x` does some magic
> """
> 
> 
> -- 
> Adrian Zubarev
> Sent with Airmail
> 
> Am 12. April 2017 um 12:48:57, Adrian Zubarev 
> (adrian.zuba...@devandartist.com) schrieb:
> 
>> Actually I’m fine with such a compromise. Such a model has everything we’ve 
>> asked for, it’s easy, it has both leading and trailing precision and 
>> implicit new lines where needed.
>> 
>> 
>> 
>> -- 
>> Adrian Zubarev
>> Sent with Airmail
>> 
>> Am 12. April 2017 um 12:42:17, Vladimir.S via swift-evolution 
>> (swift-evolution@swift.org) schrieb:
>> 
>>> On 12.04.2017 13:16, 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 convinced about the closing 
>>> >> delimiter now. =)
>>> >>
>>> >> -
>>> >>
>>> >> If I understood correctly what Xiaodi Wu meant in his reply, then we 
>>> >> could simplify
>>> >> the whole multi-line string literal and also remove the need of 
>>> >> disabling the
>>> >> stripping algorithm.
>>> >>
>>> >> We should ban these examples completely:
>>> >>
>>> >> |"""Hello·world!"""|
>>> >>
>>> >
>>> > Being able to use ""“ for single line strings containing lots of " is 
>>> > useful in
>>> > itself and explained in the motivational section of the proposal:
>>> > "Tripled string literals can also do double duty as a syntax for handling 
>>> > short
>>> > string literals with many internal quotation marks“
>>> >
>>> > -Thorsten
>>> 
>>> Yes, I also think the single line string can be very useful and we should 
>>> not
>>> disallow it.
>>> 
>>> But I agree that we should disallow multi-line cases when we have text on 
>>> the same
>>> line with leading or trailing """ because this complicates the mental modal 
>>> and adds
>>> confusion points.
>>> 
>>> I.e. I suggest to allow only two forms:
>>> 1. Single line: """this is "just" text""" (no line end will be inserted)
>>> 2. Multiline, where leading and trailing """ has no text after/before them 
>>> and *all*
>>> the text is in lines *between* triple quotes:
>>> """
>>> first line
>>> second line
>>> """
>>> 
>>> One can use backslash at the line end to emulate all other needed cases. 
>>> Like:
>>> 
>>> """
>>> first line \
>>> second line\
>>> """
>>> 
>>> will produce "first line second line"
>>> 
>>> >
>>> >> |"""Hello↵ world!""" |
>>> >> |"""Hello↵ world!↵ """ |
>>> >> |"""↵ Hello↵ world!""" |
>>> >>
>>> >> Instead an empty multi-line string literal would look like this:
>>> >>
>>> >> |"""↵ """ |
>>> >>
>>> >> To fix the above example you’d need to write it like this:
>>> >>
>>> >> |"""↵ Hello·world!\↵ """ |
>>> >> |"""↵ Hello↵ world!\↵ """ |
>>> >>
>>> >> * Each line in between the delimiters would add implicit new lines if not
>>> >> disabled by a backslash.
>>> >> * The trailing precision is also handled by the backslash.
>>> >> * The indent is handled by the closing delimiter.
>>> >> * It’s easier to learn/teach.
>>> >> * It’s easier to read, because most of the time the line where the 
>>> >> starting
>>> >> delimiter is, is filled with some other code.
>>> >>
>>> >> |let myString = """↵ ⇥ ⇥ Hello↵ ⇥ ⇥ world!\↵ ⇥ ⇥ """ |
>>> >>
>>> >> Now that would be a true multi-line string literal which needs at least 
>>> >> two lines
>>> >> of code. If you’d need a single line literal,|""|is the obvious pick.
>>> >>
>>> >>
>>> >>
>>> >>
>>> >> --
>>> >> Adrian Zubarev
>>> >> Sent with Airmail
>>> >>
>>> >> Am 12. April 2017 um 02:32:33, Brent Royal-Gordon (br...@architechies.com
>>> >> ) schrieb:
>>> >>
>>> >>>
>>>  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 

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

[Xiaodi Wu via swift-evolution]

As I explained on Twitter, the behavior is initially counterintuitive but
in many ways the least surprising result.

(First, you are incorrect about P requiring a mutable property. That is not
what var means in a protocol.)

However, you are right that two properties named value are being allowed.
It seems strange at first but consider:

Given: a protocol P with only one requirement, but with a default
implementation for that requirement. One would expect that any type T could
retroactively conform to P. After all, either T has its own implementation
of the requirement or it does not.

If the requirement is a property and not a method, and T has an identically
named but not identically typed property, we allow this sort of
"overloading" which is very much like overloading on the return type. This
fulfills the expectation above that T can conform to P. Even requiring a
warning in this scenario would break retroactive conformance.

The behavior at the call site is not harmful. A user of T may or may not
see that it conforms to P. This is because conformance can be retroactive.
Thus, when using an instance of T, references to the property are to T's
own implementation. However, if the user can see P and the conformance T :
P, they can always explicitly request P's differently typed implementation
explicitly by using "as" (just like selecting an overloaded method with a
different return type).

The behavior that is unexpected and potentially harmful is for the author
of a type T trying to conform to P. It falls into the category of
near-misses that includes unintentional typos in method names, etc. It is
no more surprising than any of those cases where you, say, get the argument
label spelled slightly wrong and end up without an intended override of a
default implementation but two methods instead.

As mentioned earlier on this list, the user experience of writing a
conforming type is suboptimal, and there are likely to be clever ways for
the compiler or other tools to help. However, ripping out type inference or
breaking retroactive conformance is not the way forward to solving this
issue.
On Wed, Apr 12, 2017 at 05:15 Vladimir.S via swift-evolution <
swift-evolution@swift.org> wrote:

> On 12.04.2017 7:19, Jaden Geller wrote:
> >
> >> On Apr 7, 2017, at 4:07 AM, Vladimir.S via swift-evolution
> >> > wrote:
> >>
> >> On 07.04.2017 10:21, Daniel Duan via swift-evolution wrote:
> >>> Hi all,
> >>>
> >>> In a discussion about inferring parameter types from default value,
> >>> Slava brought up some performance problems caused by type inference for
> >>> stored properties in side types:
> >>>
> >>>
> https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170313/033882.html
> >>>
> >>> Towards the end, the post mentioned that some Swift team members
> >>> contemplated requiring types for stored properties in type
> declarations.
> >>> I think this idea deserves some more attention. Hence this last minute
> >>> idea-floating.
> >>>
> >>> In addition to solving a performance headache in implementation,
> >>> there're always the general benefit of making type declartion more
> >>> explicit and readable (clarity for reader should out-weigh pleasure of
> >>> the author). Making the language slightly more consistent (we are not
> >>> inferring types for default parameter values in function anyways).
> >>>
> >>> 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.
> >>>
> >>> Just thought I'd float the idea to gather some quick reaction. What do
> >>> y'all think?
> >>
> >> Although it seems like only an implementation-side problem(i.e. "let's
> just improve
> >> implementation"), I see a benefits to require type for stored property
> *if* it is
> >> not obvious what the type is for *reader*. I.e. if we have something
> like this, I
> >> don't think we should require a type:
> >> struct S {
> >>  var x = 0
> >> }
> >
> > I think there is value in requiring a type annotation there. For
> example, this bug
> > would be avoided:
> https://twitter.com/benjaminencz/status/851892622213783552
>
> I believe the pointed problem is much wider, than type-inference and I
> even think
> this is bug(in design?) that should be fixed at least with warning.
>
> Please consider this example:
>
> protocol P {
> var value : Int32 {get}
> }
>
> extension P {
> var value : Int32 {return 20}
> }
>
> class C : P {
> let value = 4_000_000_000
>
> /// or even this:
> // let value : Int = 4_000_000_000
> }
>
> First, as class C conforms to P protocol, it must have *mutable* 'value'
> property
> Second, currently it seems like class C has two 'value' properties with
> different
> type. It is very strange(the principle of less surprise, yes?) and as we
> can see
> dangerous behavior. Was bug to 

Re: [swift-evolution] [Review] SE-0167: Swift Encoders

[Matthew Johnson via swift-evolution]

Sent from my iPad

> On Apr 12, 2017, at 2:53 AM, piotr gorzelany via swift-evolution 
>  wrote:
> 
> For me it boils down to a question if Data is the best type to represent 
> JSON. Data is really generic, you could serialize an UIImage into data and 
> pass it to the decoding function.

Data is what you read from and write to disk and network and therefore the 
appropriate choice for these APIs.

> 
> Yes, JSON is not a very strong type but that is the nature of JSON, it is a 
> dynamic data structure like a dictionary. But giving it a type gives us 
> future flexibility to extend it if needed. 
> 
> Also, raw JSON manipulation is common practice since the server does not 
> always give you the perfect JSON to deserialize into a model object.
> 
> Say you have a model object with some nested objects in it. To initialize 
> them from JSON you will need to full JSON for all the objects. But the common 
> practice is that the server will return only the full top level object and 
> IDs for the nest d objects so you fetch them separately.  
> 
> W dniu pon., 10.04.2017 o 22:47 Jordan Rose  
> napisał(a):
>> 
 On Apr 10, 2017, at 02:52, David Hart via swift-evolution 
  wrote:
 
 
 On 10 Apr 2017, at 11:36, piotr gorzelany via swift-evolution 
  wrote:
 
 This is a really great proposal. As an iOS developer I work with JSON 
 almost every day since most mobile apps communicate with a backend through 
 JSON messages. It's good to see that better JSON support is coming to 
 Foundation so we don't have to rely on third party libraries.
 
 That being said, there is one thing I don't like which is that the JSON 
 encoding function returns Data and the decoding function takes Data.
 
 It would be really great if the Foundation team could introduce a 
 dedicated type of JSON.
 There are several advantages of working with a dedicated type.
 - The underlying data is always valid JSON
 - You can extend this type in the future with helper methods for 
 manipulating JSON
 - It makes it explicit what you are dealing with
 
 A good analogy is the URL type. You could represent an URL with a String 
 or Data type, but by introducing a dedicated type you have the full 
 advantages mentioned above. Data on the other hand is like a generic 
 container which you cannot easily extend with URL or JSON specific methods.
 
 Having a dedicated JSON type is also one of the reasons third party 
 libraries like SwiftyJSON are so popular. It makes it super easy to 
 manipulate JSON structures. And sometimes developers like would like to 
 manipulate JSON directly.
>>> 
>>> I don’t think it would be a good thing to have this in Foundation. 
>>> Foundation needs to push developers towards adopting best practices, and 
>>> manipulating JSON directly instead of going through Codable’s strong-typing 
>>> is not necessarily recommended. I’m not saying it doesn’t have its uses. 
>>> But it’s usefulness is definitely narrow now once we have Codable. I think 
>>> this is something that should stay in a third-party library.
>> 
>> I haven't thought heavily about this, but the thoughts that I have say that 
>> JSON just isn't a good type in Swift. It's not an efficient in-memory 
>> representation and it's not a convenient structural representation (because 
>> of the use of either 'Any' or 'JSON' in the recursive position). I'll admit 
>> that sometimes you're handed some JSON and you want to extract a little bit 
>> of information out of it without building a typed representation of the 
>> whole thing, but that still seems like something that doesn't need to be the 
>> common path.
>> 
>> Jordan
>> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Ricardo Parada via swift-evolution]

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 convinced about the closing delimiter 
>> now. =)
>> 
>> If I understood correctly what Xiaodi Wu meant in his reply, then we could 
>> simplify the whole multi-line string literal and also remove the need of 
>> disabling the stripping algorithm.
>> 
>> We should ban these examples completely:
>> 
>> """Hello·world!"""
>> 
> 
> Being able to use ""“ for single line strings containing lots of " is useful 
> in itself and explained in the motivational section of the proposal:
> 
> "Tripled string literals can also do double duty as a syntax for handling 
> short string literals with many internal quotation marks“
> 
> -Thorsten
> 
>> """Hello↵
>> world!"""
>> """Hello↵
>> world!↵
>> """
>> """↵
>> Hello↵
>> world!"""
>> Instead an empty multi-line string literal would look like this:
>> 
>> """↵
>> """
>> To fix the above example you’d need to write it like this:
>> 
>> """↵
>> Hello·world!\↵
>> """
>> """↵
>> Hello↵
>> world!\↵
>> """
>> Each line in between the delimiters would add implicit new lines if not 
>> disabled by a backslash.
>> The trailing precision is also handled by the backslash.
>> The indent is handled by the closing delimiter.
>> It’s easier to learn/teach.
>> It’s easier to read, because most of the time the line where the starting 
>> delimiter is, is filled with some other code.
>> let myString = """↵
>> ⇥  ⇥  Hello↵
>> ⇥  ⇥  world!\↵
>> ⇥  ⇥  """
>> Now that would be a true multi-line string literal which needs at least two 
>> lines of code. If you’d need a single line literal, "" is the obvious pick.
>> 
>> 
>> 
>> 
>> -- 
>> Adrian Zubarev
>> Sent with Airmail
>> 
>> Am 12. April 2017 um 02:32:33, Brent Royal-Gordon (br...@architechies.com) 
>> schrieb:
>> 
>>> 
 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 it consistent and let the compiler add a new line after 
 the starting delimiter.
 
 let string = """↵
 Swift↵
 """
 
 // result
 ↵Swift↵
 If one would would the behavior from the proposal it’s really easy to add 
 a backslash after the starting delimiter.
 
 
 let string = """\↵
 Swift\↵
 """
 
 // result
 Swift
 This would be consistent and less confusing to learn.
 
>>> That would mean that code like this:
>>> 
>>> print("""
>>> A whole bunch of 
>>> multiline text
>>> """)
>>> print("""
>>> A whole bunch more 
>>> multiline text
>>> """)
>>> 
>>> Will print (with - to indicate blank lines):
>>> 
>>> -
>>> A whole bunch of
>>> multiline text
>>> -
>>> -
>>> A whole bunch more
>>> multiline text
>>> -
>>> 
>>> This is, to a first approximation, never what you actually want the 
>>> computer to do.
 Can’t we make the indent algorithm work like this instead?
 let string = """\↵
 ↵
 ··content text↵
 """ // Indent starts with the first non space character
 
 // result
 
 ↵
 ··content text↵
 
 The line where the closing delimiter is trims all space chapters and the 
 indent for the whole multi-line string is starting at the point where the 
 first non-space chapters is in that line.
 
>>> We could; I discuss that briefly in the very last section, on alternatives 
>>> to the indentation stripping we specify:
>>> 
>>> • Stripping indentation to match the depth of the least indented line: 
>>> Instead of removing indentation to match the end delimiter, you remove 
>>> indentation to match the least indented line of the string itself. The 
>>> issue here is that, if all lines in a string should be indented, you can't 
>>> use indentation stripping. Ruby 2.3 does this with its heredocs, and 
>>> Python's dedent function also implements this behavior.
>>> 
>>> That doesn't quite capture the entire breadth of the problem with this 
>>> algorithm, though. What you'd like to do is say, "all of these lines are 
>>> indented four columns, so we should remove four columns of indentation from 
>>> each line". But you don't have columns; you have tabs and spaces, and 
>>> they're incomparable because the compiler can't know what tab stops you 
>>> set. So we'd end up calculating a common prefix of whitespace for all lines 
>>> and removing that. But that means, when someone mixes tabs and spaces 
>>> accidentally, you end up stripping an amount of indentation that is 
>>> unrelated to anything visible in your code. We could perhaps emit a 

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

[Thorsten Seitz via swift-evolution]

I’d be fine with that.

-Thorsten


> Am 12.04.2017 um 12:59 schrieb Adrian Zubarev via swift-evolution 
> :
> 
> One last pitch, can we allow comments in multi-line strings if the string is 
> broken up by a backslash?
> 
> 
> let myString = """
> text text  
> text text text \ // Comment allowed in the current line here, but not in 
> the line above it
> text text text \ /* this type of comment is fine too */
> text text\// notice whitespace can be ignored
> """
> You might have some interpolation and want to comment around it.
> 
> let foo = """
> bar bar bar
> bar \(x) bar\ // `x` does some magic
> """
> 
> 
> 
> -- 
> Adrian Zubarev
> Sent with Airmail
> 
> Am 12. April 2017 um 12:48:57, Adrian Zubarev 
> (adrian.zuba...@devandartist.com ) 
> schrieb:
> 
>> Actually I’m fine with such a compromise. Such a model has everything we’ve 
>> asked for, it’s easy, it has both leading and trailing precision and 
>> implicit new lines where needed.
>> 
>> 
>> 
>> -- 
>> Adrian Zubarev
>> Sent with Airmail
>> 
>> Am 12. April 2017 um 12:42:17, Vladimir.S via swift-evolution 
>> (swift-evolution@swift.org ) schrieb:
>> 
>>> On 12.04.2017 13:16, 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 convinced about the closing 
>>> >> delimiter now. =)
>>> >>
>>> >> -
>>> >>
>>> >> If I understood correctly what Xiaodi Wu meant in his reply, then we 
>>> >> could simplify
>>> >> the whole multi-line string literal and also remove the need of 
>>> >> disabling the
>>> >> stripping algorithm.
>>> >>
>>> >> We should ban these examples completely:
>>> >>
>>> >> |"""Hello·world!"""|
>>> >>
>>> >
>>> > Being able to use ""“ for single line strings containing lots of " is 
>>> > useful in
>>> > itself and explained in the motivational section of the proposal:
>>> > "Tripled string literals can also do double duty as a syntax for handling 
>>> > short
>>> > string literals with many internal quotation marks“
>>> >
>>> > -Thorsten
>>> 
>>> Yes, I also think the single line string can be very useful and we should 
>>> not
>>> disallow it.
>>> 
>>> But I agree that we should disallow multi-line cases when we have text on 
>>> the same
>>> line with leading or trailing """ because this complicates the mental modal 
>>> and adds
>>> confusion points.
>>> 
>>> I.e. I suggest to allow only two forms:
>>> 1. Single line: """this is "just" text""" (no line end will be inserted)
>>> 2. Multiline, where leading and trailing """ has no text after/before them 
>>> and *all*
>>> the text is in lines *between* triple quotes:
>>> """
>>> first line
>>> second line
>>> """
>>> 
>>> One can use backslash at the line end to emulate all other needed cases. 
>>> Like:
>>> 
>>> """
>>> first line \
>>> second line\
>>> """
>>> 
>>> will produce "first line second line"
>>> 
>>> >
>>> >> |"""Hello↵ world!""" |
>>> >> |"""Hello↵ world!↵ """ |
>>> >> |"""↵ Hello↵ world!""" |
>>> >>
>>> >> Instead an empty multi-line string literal would look like this:
>>> >>
>>> >> |"""↵ """ |
>>> >>
>>> >> To fix the above example you’d need to write it like this:
>>> >>
>>> >> |"""↵ Hello·world!\↵ """ |
>>> >> |"""↵ Hello↵ world!\↵ """ |
>>> >>
>>> >> * Each line in between the delimiters would add implicit new lines if not
>>> >> disabled by a backslash.
>>> >> * The trailing precision is also handled by the backslash.
>>> >> * The indent is handled by the closing delimiter.
>>> >> * It’s easier to learn/teach.
>>> >> * It’s easier to read, because most of the time the line where the 
>>> >> starting
>>> >> delimiter is, is filled with some other code.
>>> >>
>>> >> |let myString = """↵ ⇥ ⇥ Hello↵ ⇥ ⇥ world!\↵ ⇥ ⇥ """ |
>>> >>
>>> >> Now that would be a true multi-line string literal which needs at least 
>>> >> two lines
>>> >> of code. If you’d need a single line literal,|""|is the obvious pick.
>>> >>
>>> >>
>>> >>
>>> >>
>>> >> --
>>> >> Adrian Zubarev
>>> >> Sent with Airmail
>>> >>
>>> >> Am 12. April 2017 um 02:32:33, Brent Royal-Gordon 
>>> >> (br...@architechies.com 
>>> >> >) schrieb:
>>> >>
>>> >>>
>>>  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.
>>> 
>>>  

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

[Thorsten Seitz via swift-evolution]

That’s a great revision, Brent! Thanks a lot!

I like it as written but would also be totally fine with Xiaodi’s proposition 
of stripping the trailing newline by default (requiring an empty line for a 
trailing newline).

-Thorsten

> Am 11.04.2017 um 15:35 schrieb John Holdsworth :
> 
> I feel discussion on this proposal is nearing general agreement that while 
> the gist of it
> it seems reasonable to many there is also not enough detail in it as 
> submitted.
> 
> Brent has person-fully stepped in and rewritten the draft to translate it 
> into a detailed
> specification which I’ve updated here:
> 
> https://github.com/johnno1962a/swift-evolution/blob/master/proposals/0168-multi-line-string-literals.md
>  
> 
> 
> Perhaps we could use the remaining time on the review to pre-evaluate this 
> draft should
> we get the chance to resubmit with modifications to maximise its chances. Key 
> questions:
> 
> 1) Does Swift need multi-line string literals?
> 2 ) Is “””long strings””” the way to go subject to a discussion about the 
> precise delimiter
> 3) Is the “magic" leading whitespace removal a good idea to support 
> indentation.
> 
> The main change on the revised proposal from the the original submitted is 
> Thorsten’s
> suggestion that Windows line endings in a source file be normalised to \n in 
> the literal.
> 
> John
> 
>> On 10 Apr 2017, at 12:09, Thorsten Seitz > > wrote:
>> 
>> 
>>> Am 09.04.2017 um 18:29 schrieb John Holdsworth >> >:
>>> 
>>> 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 last year. That was my mistake.
>>> 
>>> Second up, apologies if the proposal is rather vague on details. In some 
>>> sense this was intentional as I didn’t want to get too bogged down in 
>>> specifics (and not at all to do with my limitations as a technical writer!)
>>> 
>>> I guess we need to build up consensus more slowly by asking the following 
>>> questions separately so it can be resubmitted rather than giving a binary 
>>> +/-1 on the proposal as it stands.
>>> 
>>> 1) Does Swift need multi-line string literals?
>> 
>> Yes.
>> 
>>> 2 ) Is “””long strings””” the way to go subject to a discussion about the 
>>> precise delimiter
>> 
>> Yes.
>> 
>>> 3) Is the “magic" leading whitespace removal a good idea to support 
>>> indentation.
>> 
>> Yes.
>> 
>>> 4) Does the proposal contain sufficient detail to be discussed/implemented
>> 
>> Thanks for the update! I only have the following issues left:
>> 
>> > All other escapes would be processed as before including interpolation, \n 
>> > and "
>> You probably meant \“ instead of " here.
>> 
>> The proposal should state what kind of newline will be used within a 
>> multiline string literal. I already proposed that it should be exactly the 
>> same as for \n and not the newline character(s) actually used in the file 
>> (e.g. LF+CR or LF or CR), to avoid issues when working on different 
>> platforms (Windows, Mac, Linux) and/or using Git’s autocrlf feature.
>> 
>> The proposal should give an example how to create a multiline string literal 
>> which ends with a newline (AFAIU there should be an empty line before the 
>> closing ""“).
>> 
>> -Thorsten
>> 
>>> 
>>> My answer to 1) is obviously yes and I think the discussion has come out 
>>> about 50/50 so far so lets persevere...
>>> 
>>> Trying to fie down 2), a “””long string””” or @“long string”@ or _”long 
>>> string”_ or #”long string”# is a string literal inside a new delimiter. It 
>>> would be processed exactly as it would a normal string including escapes 
>>> and interpolation except the string can include unescaped “ or  “" and 
>>> newlines. Also, a \ at the end of the line would mean that particular 
>>> newline is not included in the string.
>>> 
>>> For me, the goals of a long string are that it should be able to pasted in 
>>> (almost) without modification from a text source and that syntax 
>>> highlighting would work for the widest possible range of text editors and 
>>> github. “””long string””” is just a trick Python uses to satisfy the second 
>>> goal (for example this gist 
>>> )
>>>  but highlighting also works for asymmetric delimiters such as @“long 
>>> string”@ which avoid potential problems with “inversion”. Heredoc or a 
>>> Swifty #equivalent does not satisfy this second goal at all well and IMHO 
>>> it should be excluded. It would also be significantly more difficult to 
>>> integrate into the Swift compiler.
>>> 
>>> Looking at 3) which is underspecified in the proposal perhaps, I’d consider 
>>> it a “feature" but I can see it would 

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

[Adrian Zubarev via swift-evolution]

One last pitch, can we allow comments in multi-line strings if the string is 
broken up by a backslash?


let myString = """
text text  
text text text \ // Comment allowed in the current line here, but not in 
the line above it
text text text \ /* this type of comment is fine too */
text text\// notice whitespace can be ignored
"""
You might have some interpolation and want to comment around it.

let foo = """
bar bar bar
bar \(x) bar\ // `x` does some magic
"""


-- 
Adrian Zubarev
Sent with Airmail

Am 12. April 2017 um 12:48:57, Adrian Zubarev (adrian.zuba...@devandartist.com) 
schrieb:

Actually I’m fine with such a compromise. Such a model has everything we’ve 
asked for, it’s easy, it has both leading and trailing precision and implicit 
new lines where needed.



-- 
Adrian Zubarev
Sent with Airmail

Am 12. April 2017 um 12:42:17, Vladimir.S via swift-evolution 
(swift-evolution@swift.org) schrieb:

On 12.04.2017 13:16, 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 convinced about the closing delimiter 
>> now. =)
>>
>> -
>>
>> If I understood correctly what Xiaodi Wu meant in his reply, then we could 
>> simplify
>> the whole multi-line string literal and also remove the need of disabling the
>> stripping algorithm.
>>
>> We should ban these examples completely:
>>
>> |"""Hello·world!"""|
>>
>
> Being able to use ""“ for single line strings containing lots of " is useful 
> in
> itself and explained in the motivational section of the proposal:
> "Tripled string literals can also do double duty as a syntax for handling 
> short
> string literals with many internal quotation marks“
>
> -Thorsten

Yes, I also think the single line string can be very useful and we should not
disallow it.

But I agree that we should disallow multi-line cases when we have text on the 
same
line with leading or trailing """ because this complicates the mental modal and 
adds
confusion points.

I.e. I suggest to allow only two forms:
1. Single line: """this is "just" text""" (no line end will be inserted)
2. Multiline, where leading and trailing """ has no text after/before them and 
*all*
the text is in lines *between* triple quotes:
"""
first line
second line
"""

One can use backslash at the line end to emulate all other needed cases. Like:

"""
first line \
second line\
"""

will produce "first line second line"

>
>> |"""Hello↵ world!""" |
>> |"""Hello↵ world!↵ """ |
>> |"""↵ Hello↵ world!""" |
>>
>> Instead an empty multi-line string literal would look like this:
>>
>> |"""↵ """ |
>>
>> To fix the above example you’d need to write it like this:
>>
>> |"""↵ Hello·world!\↵ """ |
>> |"""↵ Hello↵ world!\↵ """ |
>>
>> * Each line in between the delimiters would add implicit new lines if not
>> disabled by a backslash.
>> * The trailing precision is also handled by the backslash.
>> * The indent is handled by the closing delimiter.
>> * It’s easier to learn/teach.
>> * It’s easier to read, because most of the time the line where the starting
>> delimiter is, is filled with some other code.
>>
>> |let myString = """↵ ⇥ ⇥ Hello↵ ⇥ ⇥ world!\↵ ⇥ ⇥ """ |
>>
>> Now that would be a true multi-line string literal which needs at least two 
>> lines
>> of code. If you’d need a single line literal,|""|is the obvious pick.
>>
>>
>>
>>
>> --
>> Adrian Zubarev
>> Sent with Airmail
>>
>> Am 12. April 2017 um 02:32:33, Brent Royal-Gordon (br...@architechies.com
>> ) schrieb:
>>
>>>
 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 it consistent and let the compiler add a new line 
 after the
 starting delimiter.

 |
let string = """↵ Swift↵ """ // result ↵Swift↵ |

 If one would would the behavior from the proposal it’s really easy to add a
 backslash after the starting delimiter.

 |
let string = """\↵ Swift\↵ """ // result Swift |

 This would be consistent and less confusing to learn.

>>> That would mean that code like this:
>>>
>>> print("""
>>> A whole bunch of
>>> multiline text
>>> """)
>>> print("""
>>> A whole bunch more
>>> multiline text
>>> """)
>>>
>>> Will print (with - to indicate blank lines):
>>>
>>> -
>>> A whole bunch of
>>> multiline text
>>> -
>>> -
>>> A whole bunch more
>>> multiline text
>>> -
>>>
>>> This is, to a first 

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

[Adrian Zubarev via swift-evolution]

Actually I’m fine with such a compromise. Such a model has everything we’ve 
asked for, it’s easy, it has both leading and trailing precision and implicit 
new lines where needed.



-- 
Adrian Zubarev
Sent with Airmail

Am 12. April 2017 um 12:42:17, Vladimir.S via swift-evolution 
(swift-evolution@swift.org) schrieb:

On 12.04.2017 13:16, 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 convinced about the closing delimiter 
>> now. =)
>>
>> -
>>
>> If I understood correctly what Xiaodi Wu meant in his reply, then we could 
>> simplify  
>> the whole multi-line string literal and also remove the need of disabling 
>> the  
>> stripping algorithm.
>>
>> We should ban these examples completely:
>>
>> |"""Hello·world!"""|
>>
>  
> Being able to use ""“ for single line strings containing lots of " is useful 
> in  
> itself and explained in the motivational section of the proposal:
> "Tripled string literals can also do double duty as a syntax for handling 
> short  
> string literals with many internal quotation marks“
>  
> -Thorsten

Yes, I also think the single line string can be very useful and we should not  
disallow it.

But I agree that we should disallow multi-line cases when we have text on the 
same  
line with leading or trailing """ because this complicates the mental modal and 
adds  
confusion points.

I.e. I suggest to allow only two forms:
1. Single line: """this is "just" text""" (no line end will be inserted)
2. Multiline, where leading and trailing """ has no text after/before them and 
*all*  
the text is in lines *between* triple quotes:
"""
first line
second line
"""

One can use backslash at the line end to emulate all other needed cases. Like:

"""
first line \
second line\
"""

will produce "first line second line"

>  
>> |"""Hello↵ world!""" |
>> |"""Hello↵ world!↵ """ |
>> |"""↵ Hello↵ world!""" |
>>
>> Instead an empty multi-line string literal would look like this:
>>
>> |"""↵ """ |
>>
>> To fix the above example you’d need to write it like this:
>>
>> |"""↵ Hello·world!\↵ """ |
>> |"""↵ Hello↵ world!\↵ """ |
>>
>> * Each line in between the delimiters would add implicit new lines if not
>> disabled by a backslash.
>> * The trailing precision is also handled by the backslash.
>> * The indent is handled by the closing delimiter.
>> * It’s easier to learn/teach.
>> * It’s easier to read, because most of the time the line where the starting
>> delimiter is, is filled with some other code.
>>
>> |let myString = """↵ ⇥ ⇥ Hello↵ ⇥ ⇥ world!\↵ ⇥ ⇥ """ |
>>
>> Now that would be a true multi-line string literal which needs at least two 
>> lines  
>> of code. If you’d need a single line literal,|""|is the obvious pick.
>>
>>
>>
>>
>> --  
>> Adrian Zubarev
>> Sent with Airmail
>>
>> Am 12. April 2017 um 02:32:33, Brent Royal-Gordon (br...@architechies.com  
>> ) schrieb:
>>
>>>
 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 it consistent and let the compiler add a new line 
 after the
 starting delimiter.

 |
let string = """↵ Swift↵ """ // result ↵Swift↵ |

 If one would would the behavior from the proposal it’s really easy to add 
 a  
 backslash after the starting delimiter.

 |
let string = """\↵ Swift\↵ """ // result Swift |

 This would be consistent and less confusing to learn.

>>> That would mean that code like this:
>>>
>>> print("""
>>> A whole bunch of
>>> multiline text
>>> """)
>>> print("""
>>> A whole bunch more
>>> multiline text
>>> """)
>>>
>>> Will print (with - to indicate blank lines):
>>>
>>> -
>>> A whole bunch of
>>> multiline text
>>> -
>>> -
>>> A whole bunch more
>>> multiline text
>>> -
>>>
>>> This is, to a first approximation, never what you actually want the 
>>> computer to do.

 * Can’t we make the indent algorithm work like this instead?

 |let string = """\↵ ↵ ··content text↵ """ // Indent 
 starts  
 with the first non space character // result ↵ ··content text↵  
 |

 The line where the closing delimiter is trims all space chapters and the 
 indent  
 for the whole multi-line string is starting at the point where the first  
 non-space chapters is in that line.

>>> We could; I discuss that briefly in the very last 

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

[Vladimir.S via swift-evolution]

On 12.04.2017 13:16, 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 convinced about the closing delimiter 
now. =)

-

If I understood correctly what Xiaodi Wu meant in his reply, then we could simplify 
the whole multi-line string literal and also remove the need of disabling the 
stripping algorithm.


We should ban these examples completely:

|"""Hello·world!"""|



Being able to use ""“ for single line strings containing lots of " is useful in 
itself and explained in the motivational section of the proposal:
"Tripled string literals can also do double duty as a syntax for handling short 
string literals with many internal quotation marks“


-Thorsten


Yes, I also think the single line string can be very useful and we should not 
disallow it.


But I agree that we should disallow multi-line cases when we have text on the same 
line with leading or trailing """ because this complicates the mental modal and adds 
confusion points.


I.e. I suggest to allow only two forms:
1. Single line:  """this is "just" text""" (no line end will be inserted)
2. Multiline, where leading and trailing """ has no text after/before them and *all* 
the text is in lines *between* triple quotes:

"""
  first line
  second line
"""

One can use backslash at the line end to emulate all other needed cases. Like:

"""
  first line \
  second line\
"""

will produce "first line second line"




|"""Hello↵ world!""" |
|"""Hello↵ world!↵ """ |
|"""↵ Hello↵ world!""" |

Instead an empty multi-line string literal would look like this:

|"""↵ """ |

To fix the above example you’d need to write it like this:

|"""↵ Hello·world!\↵ """ |
|"""↵ Hello↵ world!\↵ """ |

  * Each line in between the delimiters would add implicit new lines if not
disabled by a backslash.
  * The trailing precision is also handled by the backslash.
  * The indent is handled by the closing delimiter.
  * It’s easier to learn/teach.
  * It’s easier to read, because most of the time the line where the starting
delimiter is, is filled with some other code.

|let myString = """↵ ⇥ ⇥ Hello↵ ⇥ ⇥ world!\↵ ⇥ ⇥ """ |

Now that would be a true multi-line string literal which needs at least two lines 
of code. If you’d need a single line literal,|""|is the obvious pick.





--
Adrian Zubarev
Sent with Airmail

Am 12. April 2017 um 02:32:33, Brent Royal-Gordon (br...@architechies.com 
) schrieb:




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 it consistent and let the compiler add a new line after 
the
starting delimiter.

|
let string = """↵ Swift↵ """ // result ↵Swift↵ |

If one would would the behavior from the proposal it’s really easy to add a 
backslash after the starting delimiter.


|
let string = """\↵ Swift\↵ """ // result Swift |

This would be consistent and less confusing to learn.


That would mean that code like this:

print("""
A whole bunch of
multiline text
""")
print("""
A whole bunch more
multiline text
""")

Will print (with - to indicate blank lines):

-
A whole bunch of
multiline text
-
-
A whole bunch more
multiline text
-

This is, to a first approximation, never what you actually want the computer to 
do.


  * Can’t we make the indent algorithm work like this instead?

|let string = """\↵ ↵ ··content text↵ """ // Indent starts 
with the first non space character // result ↵ ··content text↵  |


The line where the closing delimiter is trims all space chapters and the indent 
for the whole multi-line string is starting at the point where the first 
non-space chapters is in that line.


We could; I discuss that briefly in the very last section, on alternatives to the 
indentation stripping we specify:


• Stripping indentation to match the depth of the least indented line: Instead of 
removing indentation to match the end delimiter, you remove indentation to match 
the least indented line of the string itself. The issue here is that, if all lines 
in a string should be indented, you can't use indentation stripping. Ruby 2.3 does 
this with its heredocs, and Python's dedent function also implements this behavior.


That doesn't quite capture the entire breadth of the problem with this algorithm, 
though. What you'd like to do is say, "all of these lines are indented four 
columns, so we should remove four columns of indentation from each line". But you 
don't have 

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

[Thorsten Seitz via swift-evolution]

> Am 12.04.2017 um 10:11 schrieb Adrian Zubarev via swift-evolution 
> :
> 
> Great explanation thank you Brent. I’m convinced about the closing delimiter 
> now. =)
> 
> If I understood correctly what Xiaodi Wu meant in his reply, then we could 
> simplify the whole multi-line string literal and also remove the need of 
> disabling the stripping algorithm.
> 
> We should ban these examples completely:
> 
> """Hello·world!"""
> 

Being able to use ""“ for single line strings containing lots of " is useful in 
itself and explained in the motivational section of the proposal:

"Tripled string literals can also do double duty as a syntax for handling short 
string literals with many internal quotation marks“

-Thorsten

> """Hello↵
> world!"""
> """Hello↵
> world!↵
> """
> """↵
> Hello↵
> world!"""
> Instead an empty multi-line string literal would look like this:
> 
> """↵
> """
> To fix the above example you’d need to write it like this:
> 
> """↵
> Hello·world!\↵
> """
> """↵
> Hello↵
> world!\↵
> """
> Each line in between the delimiters would add implicit new lines if not 
> disabled by a backslash.
> The trailing precision is also handled by the backslash.
> The indent is handled by the closing delimiter.
> It’s easier to learn/teach.
> It’s easier to read, because most of the time the line where the starting 
> delimiter is, is filled with some other code.
> let myString = """↵
> ⇥  ⇥  Hello↵
> ⇥  ⇥  world!\↵
> ⇥  ⇥  """
> Now that would be a true multi-line string literal which needs at least two 
> lines of code. If you’d need a single line literal, "" is the obvious pick.
> 
> 
> 
> 
> -- 
> Adrian Zubarev
> Sent with Airmail
> 
> Am 12. April 2017 um 02:32:33, Brent Royal-Gordon (br...@architechies.com 
> ) schrieb:
> 
>> 
>>> 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 it consistent and let the compiler add a new line after 
>>> the starting delimiter.
>>> 
>>> let string = """↵
>>> Swift↵
>>> """
>>> 
>>> // result
>>> ↵Swift↵
>>> If one would would the behavior from the proposal it’s really easy to add a 
>>> backslash after the starting delimiter.
>>> 
>>> 
>>> let string = """\↵
>>> Swift\↵
>>> """
>>> 
>>> // result
>>> Swift
>>> This would be consistent and less confusing to learn.
>>> 
>> That would mean that code like this:
>> 
>> print("""
>> A whole bunch of 
>> multiline text
>> """)
>> print("""
>> A whole bunch more 
>> multiline text
>> """)
>> 
>> Will print (with - to indicate blank lines):
>> 
>> -
>> A whole bunch of
>> multiline text
>> -
>> -
>> A whole bunch more
>> multiline text
>> -
>> 
>> This is, to a first approximation, never what you actually want the computer 
>> to do.
>>> Can’t we make the indent algorithm work like this instead?
>>> let string = """\↵
>>> ↵
>>> ··content text↵
>>> """ // Indent starts with the first non space character
>>> 
>>> // result
>>> 
>>> ↵
>>> ··content text↵
>>> 
>>> The line where the closing delimiter is trims all space chapters and the 
>>> indent for the whole multi-line string is starting at the point where the 
>>> first non-space chapters is in that line.
>>> 
>> We could; I discuss that briefly in the very last section, on alternatives 
>> to the indentation stripping we specify:
>> 
>> • Stripping indentation to match the depth of the least indented line: 
>> Instead of removing indentation to match the end delimiter, you remove 
>> indentation to match the least indented line of the string itself. The issue 
>> here is that, if all lines in a string should be indented, you can't use 
>> indentation stripping. Ruby 2.3 does this with its heredocs, and Python's 
>> dedent function also implements this behavior.
>> 
>> That doesn't quite capture the entire breadth of the problem with this 
>> algorithm, though. What you'd like to do is say, "all of these lines are 
>> indented four columns, so we should remove four columns of indentation from 
>> each line". But you don't have columns; you have tabs and spaces, and 
>> they're incomparable because the compiler can't know what tab stops you set. 
>> So we'd end up calculating a common prefix of whitespace for all lines and 
>> removing that. But that means, when someone mixes tabs and spaces 
>> accidentally, you end up stripping an amount of indentation that is 
>> unrelated to anything visible in your code. We could perhaps emit a warning 
>> in some suspicious circumstances (like "every line has whitespace just past 
>> the end of indentation, but some use tabs and others use spaces"), but if we 
>> do, we can't know which one is supposed to be correct. With the proposed 

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

[Vladimir.S via swift-evolution]

On 12.04.2017 7:19, Jaden Geller wrote:


On Apr 7, 2017, at 4:07 AM, Vladimir.S via swift-evolution 
> wrote:


On 07.04.2017 10:21, Daniel Duan via swift-evolution wrote:

Hi all,

In a discussion about inferring parameter types from default value,
Slava brought up some performance problems caused by type inference for
stored properties in side types:

https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170313/033882.html

Towards the end, the post mentioned that some Swift team members
contemplated requiring types for stored properties in type declarations.
I think this idea deserves some more attention. Hence this last minute
idea-floating.

In addition to solving a performance headache in implementation,
there're always the general benefit of making type declartion more
explicit and readable (clarity for reader should out-weigh pleasure of
the author). Making the language slightly more consistent (we are not
inferring types for default parameter values in function anyways).

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.

Just thought I'd float the idea to gather some quick reaction. What do
y'all think?


Although it seems like only an implementation-side problem(i.e. "let's just improve 
implementation"), I see a benefits to require type for stored property *if* it is 
not obvious what the type is for *reader*. I.e. if we have something like this, I 
don't think we should require a type:

struct S {
 var x = 0
}


I think there is value in requiring a type annotation there. For example, this bug 
would be avoided: https://twitter.com/benjaminencz/status/851892622213783552


I believe the pointed problem is much wider, than type-inference and I even think 
this is bug(in design?) that should be fixed at least with warning.


Please consider this example:

protocol P {
var value : Int32 {get}
}

extension P {
var value : Int32 {return 20}
}

class C : P {
let value = 4_000_000_000

/// or even this:
// let value : Int = 4_000_000_000
}

First, as class C conforms to P protocol, it must have *mutable* 'value' 
property
Second, currently it seems like class C has two 'value' properties with different 
type. It is very strange(the principle of less surprise, yes?) and as we can see 
dangerous behavior. Was bug to bugs.swift.org submitted? If so, what was the reply of 
the core team?






but I do think it will be better to require a type in such cases :

struct S{
 var x = something(SomeType(), 123, "123") // can be generic func
}





Daniel Duan ___
swift-evolution mailing listswift-evolut...@swift.org 


https://lists.swift.org/mailman/listinfo/swift-evolution


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



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

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

[Adrian Zubarev via swift-evolution]

I didn’t think about vertical line. I think the guys from JetBrains who develop 
AppCode would be faster to adopt this feature. Great suggestion.



-- 
Adrian Zubarev
Sent with Airmail

Am 12. April 2017 um 03:12:55, Ricardo Parada via swift-evolution 
(swift-evolution@swift.org) schrieb:


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-evolution 
>  wrote:
>  
>  
>  
>  
>> 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. :-)
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Adrian Zubarev via swift-evolution]

Great explanation thank you Brent. I’m convinced about the closing delimiter 
now. =)

If I understood correctly what Xiaodi Wu meant in his reply, then we could 
simplify the whole multi-line string literal and also remove the need of 
disabling the stripping algorithm.

We should ban these examples completely:

"""Hello·world!"""

"""Hello↵
world!"""
"""Hello↵
world!↵
"""
"""↵
Hello↵
world!"""
Instead an empty multi-line string literal would look like this:

"""↵
"""
To fix the above example you’d need to write it like this:

"""↵
Hello·world!\↵
"""
"""↵
Hello↵
world!\↵
"""
Each line in between the delimiters would add implicit new lines if not 
disabled by a backslash.
The trailing precision is also handled by the backslash.
The indent is handled by the closing delimiter.
It’s easier to learn/teach.
It’s easier to read, because most of the time the line where the starting 
delimiter is, is filled with some other code.
let myString = """↵
⇥  ⇥  Hello↵
⇥  ⇥  world!\↵
⇥  ⇥  """
Now that would be a true multi-line string literal which needs at least two 
lines of code. If you’d need a single line literal, "" is the obvious pick.



-- 
Adrian Zubarev
Sent with Airmail

Am 12. April 2017 um 02:32:33, Brent Royal-Gordon (br...@architechies.com) 
schrieb:


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 it consistent and let the compiler add a new line after the 
starting delimiter.

let string = """↵
Swift↵
"""

// result
↵Swift↵
If one would would the behavior from the proposal it’s really easy to add a 
backslash after the starting delimiter.


let string = """\↵
Swift\↵
"""

// result
Swift
This would be consistent and less confusing to learn.

That would mean that code like this:

print("""
A whole bunch of 
multiline text
""")
print("""
A whole bunch more 
multiline text
""")

Will print (with - to indicate blank lines):

-
A whole bunch of
multiline text
-
-
A whole bunch more
multiline text
-

This is, to a first approximation, never what you actually want the computer to 
do.
Can’t we make the indent algorithm work like this instead?
let string = """\↵
↵
··content text↵
""" // Indent starts with the first non space character

// result

↵
··content text↵

The line where the closing delimiter is trims all space chapters and the indent 
for the whole multi-line string is starting at the point where the first 
non-space chapters is in that line.

We could; I discuss that briefly in the very last section, on alternatives to 
the indentation stripping we specify:

• Stripping indentation to match the depth of the least indented line: Instead 
of removing indentation to match the end delimiter, you remove indentation to 
match the least indented line of the string itself. The issue here is that, if 
all lines in a string should be indented, you can't use indentation stripping. 
Ruby 2.3 does this with its heredocs, and Python's dedent function also 
implements this behavior.

That doesn't quite capture the entire breadth of the problem with this 
algorithm, though. What you'd like to do is say, "all of these lines are 
indented four columns, so we should remove four columns of indentation from 
each line". But you don't have columns; you have tabs and spaces, and they're 
incomparable because the compiler can't know what tab stops you set. So we'd 
end up calculating a common prefix of whitespace for all lines and removing 
that. But that means, when someone mixes tabs and spaces accidentally, you end 
up stripping an amount of indentation that is unrelated to anything visible in 
your code. We could perhaps emit a warning in some suspicious circumstances 
(like "every line has whitespace just past the end of indentation, but some use 
tabs and others use spaces"), but if we do, we can't know which one is supposed 
to be correct. With the proposed design, we know what's correct—the last 
line—and any deviation from it can be flagged *at the particular line which 
doesn't match our expectation*.

Even without the tabs and spaces issue, consider the case where you 
accidentally don't indent a line far enough. With your algorithm, that's 
indistinguishable from wanting the other lines to be indented more than that 
one, so we generate a result you don't want and we don't (can't!) emit a 
warning to point out the mistake. With the proposed algorithm, we can notice 
there's an error and point to the line at fault.

Having the closing delimiter always be on its own line and using it to decide 
how much whitespace to strip is better because it gives the compiler a firm 
baseline to work from. That means it can tell you what's wrong and where, 
instead of doing the dumb computer thing and computing a result that's 
technically 

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

[Víctor Pimentel Rodríguez via swift-evolution]

On Friday, April 7, 2017, Daniel Duan via swift-evolution <
swift-evolution@swift.org> wrote:

> Hi all,
>
> In a discussion about inferring parameter types from default value, Slava
> brought up some performance problems caused by type inference for stored
> properties in side types:
>
> https://lists.swift.org/pipermail/swift-evolution/
> Week-of-Mon-20170313/033882.html
>
> Towards the end, the post mentioned that some Swift team members
> contemplated requiring types for stored properties in type declarations. I
> think this idea deserves some more attention. Hence this last minute
> idea-floating.
>
> In addition to solving a performance headache in implementation, there're
> always the general benefit of making type declartion more explicit and
> readable (clarity for reader should out-weigh pleasure of the author).
> Making the
> language slightly more consistent (we are not inferring types for default
> parameter values in function anyways).
>
> 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.
>
> Just thought I'd float the idea to gather some quick reaction. What do
> y'all think?
>

I think this chabge would be too source breaking for Swift 4. Just for that
reason I would not implement it.

Also, I think the Core team talked about having specific themes for the
upcoming releases. I would very much like Swift 5 to have improving compile
times as a major theme.

Under such theme, maybe it makes sense to forbid complex expressions
in stored properties definitions with no explicit type. Forbidding literals
or direct function calls would remove a useful feature and the gains would
not be much, IMHO.

--
Víctor Pimentel

-- 

INNOVATION IN PERSONAL COMMS


*[image: Imágenes integradas 5]*

*Víctor Pimentel Rodríguez · *Principal iOS Engineer
vpimen...@tuenti.com

+34 914 294 039 <+34914294039> — +34 687 840 886 <+34687840886>
C/ Gran Vía, nº 28, 6ª planta — 28013 Madrid
Tuenti Technologies, S.L.

www.tu.com
www.tuenti.com
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Review] SE-0167: Swift Encoders

[piotr gorzelany via swift-evolution]

For me it boils down to a question if Data is the best type to represent
JSON. Data is really generic, you could serialize an UIImage into data and
pass it to the decoding function.

Yes, JSON is not a very strong type but that is the nature of JSON, it is a
dynamic data structure like a dictionary. But giving it a type gives us
future flexibility to extend it if needed.

Also, raw JSON manipulation is common practice since the server does not
always give you the perfect JSON to deserialize into a model object.

Say you have a model object with some nested objects in it. To initialize
them from JSON you will need to full JSON for all the objects. But the
common practice is that the server will return only the full top level
object and IDs for the nest d objects so you fetch them separately.

W dniu pon., 10.04.2017 o 22:47 Jordan Rose 
napisał(a):

>
> On Apr 10, 2017, at 02:52, David Hart via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>
> On 10 Apr 2017, at 11:36, piotr gorzelany via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> This is a really great proposal. As an iOS developer I work with JSON
> almost every day since most mobile apps communicate with a backend through
> JSON messages. It's good to see that better JSON support is coming to
> Foundation so we don't have to rely on third party libraries.
>
> That being said, there is one thing I don't like which is that the JSON
> encoding function returns Data and the decoding function takes Data.
>
> It would be really great if the Foundation team could introduce a
> dedicated type of JSON.
> There are several advantages of working with a dedicated type.
> - The underlying data is always valid JSON
> - You can extend this type in the future with helper methods for
> manipulating JSON
> - It makes it explicit what you are dealing with
>
> A good analogy is the URL type. You could represent an URL with a String
> or Data type, but by introducing a dedicated type you have the full
> advantages mentioned above. Data on the other hand is like a generic
> container which you cannot easily extend with URL or JSON specific methods.
>
> Having a dedicated JSON type is also one of the reasons third party
> libraries like SwiftyJSON are so popular. It makes it super easy to
> manipulate JSON structures. And sometimes developers like would like to
> manipulate JSON directly.
>
>
> I don’t think it would be a good thing to have this in Foundation.
> Foundation needs to push developers towards adopting best practices, and
> manipulating JSON directly instead of going through Codable’s strong-typing
> is not necessarily recommended. I’m not saying it doesn’t have its uses.
> But it’s usefulness is definitely narrow now once we have Codable. I think
> this is something that should stay in a third-party library.
>
>
> I haven't thought *heavily* about this, but the thoughts that I have say
> that JSON just isn't a good type in Swift. It's not an efficient in-memory
> representation and it's not a convenient structural representation (because
> of the use of either 'Any' or 'JSON' in the recursive position). I'll admit
> that sometimes you're handed some JSON and you want to extract a little bit
> of information out of it without building a typed representation of the
> whole thing, but that still seems like something that doesn't need to be
> the common path.
>
> Jordan
>
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Slava Pestov via swift-evolution]

> On Apr 9, 2017, at 3:01 PM, Jon Shier via swift-evolution 
>  wrote:
> 
>   I generally dislike any language change desired because it makes the 
> compiler implementation easier. We saw a few such changes for Swift 3 and all 
> of them were net negatives for the actual users of the language (to a minor 
> extent for most, to be fair).

I’m going to have to call shenanigans on this claim :-) At least I can’t 
_think_ of any Swift 3 features that were designed with the goal of making the 
implementation simpler. Even the feature removals, such as nuking the ‘function 
currying’ syntax, took time to implement (and this is not even fully removed 
yet).

>  I would hope that, as the compiler matures, these types of inference 
> performance issues will become less of a problem. Removing a rather nice 
> language feature, especially one that plays such a big role in the “feel” of 
> the language, for short term gain seems rather shortsighted to me.

I agree. The type checker might have pathological behavior in some cases now, 
but we hope to fix those over time, and none of it is specific to the 
expressions people usually write in stored property initializers.

Slava

> 
> 
> 
> Jon Shier
> 
> 
>> On Apr 9, 2017, at 11:23 AM, Lucas Neiva via swift-evolution 
>> > wrote:
>> 
>> If inference only works in simple cases, I think it would seem like it works 
>> unpredictability to anyone unfamiliar with the implementation details.
>> 
>> I image the question of "why do I have to declare a type here, but not in 
>> this case?" coming up.
>> 
>> Declaring types is one of the first things you have to learn anyway. Just 
>> declaring a function already requires some understanding of types. 
>> Properties are not much different IMO.
>> 
>> On 8 Apr 2017, at 08:34, Brent Royal-Gordon via swift-evolution 
>> > wrote:
>> 
 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 friendly, I think it could be considered a teaching 
>>> issue. A great way to introduce beginners to custom types would be 
>>> something like:
>>> 
>>> struct Point {
>>> var x = 0.0
>>> var y = 0.0
>>> }
>>> 
>>> Or:
>>> 
>>> struct Person {
>>> var name = ""
>>> var age = 18
>>> }
>>> 
>>> If you have to explicitly specify types for the properties, that's another 
>>> thing you need to introduce to people before you can do this.
>>> 
>>> On the other hand, a very limited form of inference might be fine here. 
>>> Imagine if we did a sort of limited, single-pass, top-down inference which 
>>> only understood a few things (literals, tuple syntax, initializer calls), 
>>> stopped once it had seen enough to infer a complete type, and rejected an 
>>> expression if it encountered something it didn't understand before 
>>> finishing. That would probably cover most simple cases, and it would 
>>> probably only allow expressions whose types were obvious enough that we 
>>> could use it for arguments, too. (But of course it would mean more code in 
>>> the compiler, so it might not be worth it.)
>>> 
>>> -- 
>>> Brent Royal-Gordon
>>> Architechies
>>> 
>>> ___
>>> swift-evolution mailing list
>>> swift-evolution@swift.org 
>>> https://lists.swift.org/mailman/listinfo/swift-evolution 
>>> 
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org 
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

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

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

[Goffredo Marocchi via swift-evolution]

Sent from my iPhone

> On 12 Apr 2017, at 01:18, Jakub Suder via swift-evolution 
>  wrote:
> 
> I'm honestly having trouble believing that this is being seriously 
> proposed... I always saw type inference as one of the most important 
> advantages of Swift over some older languages, the Swift ebook mentions many 
> times how smart Swift is that it can infer types for you so that you don't 
> have to type too much boilerplate.

I think Swift and its compiler have. A lot of other strong points beyond type 
inference and emphasis on static typing too, but type inference has a very very 
real cost and sooner or later the language and its community will have to deal 
with compile times that are a lot slower (some people were reporting about 2+ 
times slower) than a similar project in Objective-C... that is a very real 
productivity cost.

> And here we're talking about removing this feature that was advertised from 
> the beginning as Swift's strong point, in order to make the compilation 
> faster? The compiler speeds will be improved, the syntax will stay with us.
> 
> Yes, specifying the type is often clearer, I do it myself, e.g. "var enabled: 
> Bool = true". But that's my choice, not something I should be forced to do. 
> It's something to put in style guides, not to enforce with the compiler.
> 
> 
>> On 8 April 2017 at 07:40, Pranshu Goyal via swift-evolution 
>>  wrote:
>> I agree with the sentiment of the proposal, it does add value to overall 
>> efficiency of swift and make things simpler for the swift team, but as 
>> Matthew said a blanket ban will add noise to the code. Also this particular 
>> feature is one of those niceties about swift which makes it very welcoming 
>> to new adopters.
>> 
>> If some middle ground can be proposed to this problem then I think we will 
>> be making a lot of people happy.
>> 
>>> On 7 April 2017 at 18:31, Matthew Johnson via swift-evolution 
>>>  wrote:
>>> 
>>> > On Apr 7, 2017, at 2:21 AM, Daniel Duan via swift-evolution 
>>> >  wrote:
>>> >
>>> > Hi all,
>>> >
>>> > In a discussion about inferring parameter types from default value, Slava 
>>> > brought up some performance problems caused by type inference for stored 
>>> > properties in side types:
>>> >
>>> > https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170313/033882.html
>>> >
>>> > Towards the end, the post mentioned that some Swift team members 
>>> > contemplated requiring types for stored properties in type declarations. 
>>> > I think this idea deserves some more attention. Hence this last minute 
>>> > idea-floating.
>>> >
>>> > In addition to solving a performance headache in implementation, there're 
>>> > always the general benefit of making type declartion more explicit and 
>>> > readable (clarity for reader should out-weigh pleasure of the author). 
>>> > Making the
>>> > language slightly more consistent (we are not inferring types for default 
>>> > parameter values in function anyways).
>>> >
>>> > 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.
>>> >
>>> > Just thought I'd float the idea to gather some quick reaction. What do 
>>> > y'all think?
>>> 
>>> I’m willing to keep an open mind on this topic but I don’t think wholesale 
>>> banning of inference is the right thing to do.  Here is an example of a 
>>> case where I do not want to give up inference.  When a property is 
>>> initialized inline by calling an initializer of a non-generic type (very 
>>> common) any annotation is strictly redundant.
>>> 
>>> struct {
>>> let foo = Foo()
>>> }
>>> 
>>> Requiring a type annotation here feels very unnecessary and boilerplate-y.  
>>> I adds no additional clarity to a reader of the code, only noise.  Noise 
>>> reduces clarity.  Small amounts of unnecessary or redundant information 
>>> such as in an individual stored property declaration are not that big a 
>>> deal.  But on balance they add up quickly and have an undesirable impact on 
>>> the overall clarity of code.
>>> 
>>> >
>>> > Daniel Duan
>>> > ___
>>> > swift-evolution mailing list
>>> > swift-evolution@swift.org
>>> > https://lists.swift.org/mailman/listinfo/swift-evolution
>>> 
>>> ___
>>> swift-evolution mailing list
>>> swift-evolution@swift.org
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>> 
>> 
>> 
>> -- 
>> Pranshu Goyal
>> iOS Developer
>> tlkn
>> 
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>> 
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> 

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

[David Hart via swift-evolution]

> On 12 Apr 2017, at 07:42, Chris Lattner  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, and the need to define some 
>>> boundary (for symbol visibility reasons).  Saying that extensions to a type 
>>> have access to private members if they are in the same module is just as 
>>> arbitrary as limiting it to a single file, and a whole lot less useful from 
>>> the “reasoning about a type” perspective.
>> 
>> I think you misunderstand. We were talking about two extensions of a type, 
>> in a different file from the type, to share private members between 
>> themselves.
>> 
>> Doug Gregor mentioned it during the PR process and we added an example to 
>> disallow it, but in hindsight, I think it should be allowed.
> 
> Ah, you’re saying:
> 
> a.swift:
> struct X {}
> 
> b.swift:
> extension X {
>   private func f() {}
> }
> 
> extension X {
>   func g() { f() }
> }
> 
> If so, then yes, I agree we should accept that.
> 
> -Chris

Should we edit the proposal or let the Core Team fix it during review as John 
suggests?

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