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

> On Apr 12, 2017, at 6:18 PM, Russ Bishop wrote: > >> >> On Apr 12, 2017, at 5:44 PM, Brent Royal-Gordon > > wrote: >> >>> On Apr 12, 2017, at 11:44 AM, Russ Bishop via swift-evolution >>>

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

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

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

> 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

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

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

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

> 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

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

+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

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

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

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

> 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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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)

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

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.

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

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

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

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

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

> 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

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

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

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

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

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

> 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

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

> 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

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

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?

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

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

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

> 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

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

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

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

> 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

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

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

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

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)

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

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

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

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

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

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

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

-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

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

-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

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

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

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

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

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

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

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

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

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

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

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

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

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

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") ___

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

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

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

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

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

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

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:

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

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

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

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.

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

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:

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

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

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

> 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

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

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 }

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

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.

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

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 {

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

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

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

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

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

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

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

> 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

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

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

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

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

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

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

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

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

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

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

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

I 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

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

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

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

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,

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

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

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

> 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

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

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

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

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.

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

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

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

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

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

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 >

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

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

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

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

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

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

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

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

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

> 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

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

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

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

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

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

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

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

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

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

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

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

> 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

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

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

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

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