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

On 13.04.2017 15:41, Brent Royal-Gordon via swift-evolution wrote: On Apr 13, 2017, at 5:35 AM, Ricardo Parada via swift-evolution > wrote: Take a look at Brent's revised proposal.I personally thin it is perfect. Take a look:

Re: [swift-evolution] [Pitch] Cross-platform Swift TLS library

Hi Gelareh, Overall I think this pitch is a great move forward. I've found that this is already resulting in some incompatibilities trying to combine rather complex Swift projects. I recently worked on integrating Kitura-Net, which uses BlueCryptor as a wrapper over both CommonCrypto /

Re: [swift-evolution] [pitch] Comparison Reform

Online copy here: https://github.com/airspeedswift/swift-evolution/blob/fa007138a54895e94d22e053122ca24ffa0b2eeb/proposals/-ComparisonReform.md > On Apr 13, 2017, at 1:17 PM, Ben Cohen via swift-evolution > wrote: > > > Hi swift evolution, > > Here’s another

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

> On Apr 13, 2017, at 10:52, Adrian Zubarev > wrote: > > I don’t think it’s a good idea to add optionally character before the closing > delimiter, because it could confuse the reader of the code on how exactly the > actual string lines above will be

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

Sure thing, everyones opinion is welcome and helps fine tuning the model. Here is a quick illustration of the model I’m pushing. --  Adrian Zubarev Sent with Airmail Am 13. April 2017 um 20:02:44, David Sweeris (daveswee...@mac.com) schrieb: On Apr 13, 2017, at 10:52, Adrian Zubarev

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

> On Apr 13, 2017, at 10:41, Adrian Zubarev > wrote: > > Was the / intended or did you meant to write \? > > Personally I don’t think we’d need that behavior and can fallback to the > natural way using a blank lines or explicit way using the \n character to

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

> On Apr 12, 2017, at 20:31, Félix Cloutier via swift-evolution > wrote: > > 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. I don't think

Re: [swift-evolution] struct finalization constraint for protocols

Honestly I read your post twice and I still having issues to understand what exactly you’re proposing. Now about final on protocols. IMO this is a bad choice, because I would think that you cannot conform to that protocol, not could you refine it with another protocol, because it’s final after

[swift-evolution] struct finalization constraint for protocols

Hello everyone! First of all, I know swift goes into a bit different direction for super type safety, but the problem that is going to describe is kind of common to anybody who use general purpose library (that are not bound to any big UI/non-UI framework). I’m a game-engine and deep learning

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

Assuming the multi-line string literal to behave like I summarized it in my last post and that the for loop runs two times, we’d have to alter your example a little, which will then feel natural for concatenation. I use tabs for ident. // Notice the blank line at the end, which does // not

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

> 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. Glad to hear that — I hope the core team will keep the courage to break syntax from time to time if the change improves the consistency of Swift.

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

+1 Sent from my iPhone > On 13 Apr 2017, at 08:15, Tino Heth via swift-evolution > wrote: > >> No change >> Benefit: No change to the language. >> Drawback: Must use “fileprivate” to build up a type through extensions. >> >> SE–0159 >> Benefit: Simplifies the

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

> 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

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

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

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

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

Re: [swift-evolution] [pitch] Comparison Reform

I still like the ordering of floats defined in this proposal best (and think we should use it), but I imagine that there are other types which are almost (but not quite) comparable as well. Would there be any utility in having a ‘PartialComparable’ protocol that defined a single method:

Re: [swift-evolution] [pitch] Comparison Reform

On Thu, Apr 13, 2017 at 7:02 PM, Jonathan Hull via swift-evolution < swift-evolution@swift.org> wrote: > This is a sugar request, but if we are rearranging these things anyway, > can we *please* add the ‘≤’, ‘≥’, and ‘≠’ operators to comparable. I know > they would do the same thing as ‘<=‘,

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

I think the subscript index should not be optional - you want 2nd array element, 3rd, etc., not a "nil" element - this makes no sense to me. Also it feels like some strange optional behavior compared to the normal usage, so -1 from me on this idea. I think that there can be situations where

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

On Thu, Apr 13, 2017 at 7:55 PM, Brent Royal-Gordon wrote: > On Apr 13, 2017, at 4:48 PM, Xiaodi Wu wrote: > > You say "this is the example set by `print`", but I don't think anything >> else actually *follows* that example. No other I/O operation in

Re: [swift-evolution] [pitch] Comparison Reform

Oh, I definitely overlooked that part. Thanks for that clarification! I had assumed the compiler changes were only necessary for allowing circular default implementations while still requiring at least one requirement be implemented. That said, it’s possible to implement something very, very

Re: [swift-evolution] [pitch] Comparison Reform

Looking good. A few comments inline: > On 13 Apr 2017, at 22:17, Ben Cohen via swift-evolution > wrote: > > > Hi swift evolution, > > Here’s another pitch, for The Propoosal Formerly Known As Spaceship. > Comparison Reform > > Proposal: SE- > > Authors:

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

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

Re: [swift-evolution] [pitch] Comparison Reform

> On Apr 13, 2017, at 5:18 PM, Xiaodi Wu via swift-evolution > wrote: > > Actually, the fact that this behavior cannot even be achieved without > currently non-existent compiler features means that it is not possible to > understand what's truly going on without

Re: [swift-evolution] [pitch] Comparison Reform

> On Apr 13, 2017, at 17:51, Jonathan Hull via swift-evolution > wrote: > > I think “vastly” is vastly overstating it, especially since they are not > customization points… merely aliases. There is nothing else those operators > could do without causing confusion.

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

On Thu, Apr 13, 2017 at 2:55 PM Brent Royal-Gordon via swift-evolution < swift-evolution@swift.org> wrote: > On Apr 13, 2017, at 9:18 AM, David Sweeris via swift-evolution < > swift-evolution@swift.org> wrote: > > In any case, given that we're discussing a "safe subscript", we need a way > to

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

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

Re: [swift-evolution] [pitch] Comparison Reform

> On Apr 13, 2017, at 5:18 PM, Remy Demarest (Psy) via swift-evolution > wrote: > > > Remy Demarest > remy.demar...@gmail.com > > > >> Le 13 avr. 2017 à 13:17, Ben Cohen via swift-evolution >>

Re: [swift-evolution] [pitch] Comparison Reform

> On Apr 13, 2017, at 4:17 PM, Ben Cohen via swift-evolution > wrote: > ComparisonResult Conveniences > > There are a few conveniences we could consider providing to make > ComparisonResult more ergonomic to manipulate. Such as: > > // A way to combine orderings >

Re: [swift-evolution] [pitch] Comparison Reform

Getting this sorted out is definitely a worthwhile effort. I do have thoughts about this proposal: I continue to have reservations about an identical spelling (e.g. `==`) giving two different answers with the same values of the same type, depending on the generic context. It is a very *clever*

Re: [swift-evolution] [pitch] Comparison Reform

> > On Apr 13, 2017, at 3:23 PM, John McCall via swift-evolution > wrote: > >> On Apr 13, 2017, at 4:17 PM, Ben Cohen via swift-evolution >> > wrote: >> ComparisonResult Conveniences >> >> There are a few

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

I don't see that retroactive conformance needs to be exportable. If it is exported then you cannot prevent clashes from two modules, this is a known problem in C#. Because of this and other problems with C# extensions, this style of extension were rejected by other language communities (notably

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

A proposal for lenient subscripts has already been written, and a PR has been created on the swift-evolution repo and it has been closed for not being in scope. When it is in scope, it can be considered again. But in the meantime, the topic has been visited so many times that it's extremely

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

On Thu, Apr 13, 2017 at 4:03 AM, Brent Royal-Gordon wrote: > On Apr 12, 2017, at 5:39 PM, Xiaodi Wu wrote: > > On Wed, Apr 12, 2017 at 5:20 PM, Brent Royal-Gordon < > br...@architechies.com> wrote: > >> Wow, maybe I shouldn't have slept. >> >> Okay,

Re: [swift-evolution] [pitch] Comparison Reform

This is a sugar request, but if we are rearranging these things anyway, can we *please* add the ‘≤’, ‘≥’, and ‘≠’ operators to comparable. I know they would do the same thing as ‘<=‘, ‘>=‘, and ‘!=‘, but they can’t really be used for anything else without being confusing (because they

Re: [swift-evolution] [pitch] Comparison Reform

I think “vastly” is vastly overstating it, especially since they are not customization points… merely aliases. There is nothing else those operators could do without causing confusion. Swift favors clarity, and these operators are much more clear (which I count as a benefit). Also ‘<=‘ looks

Re: [swift-evolution] [pitch] Comparison Reform

> On Apr 13, 2017, at 2:42 PM, David Hart via swift-evolution > wrote: > > It feels weird to me to jump through all these hoops just for backwards > compatibility. Seeing how even big projects might only have several > Comparable conformances, wouldn’t it be worth

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

> On Apr 13, 2017, at 15:01, Tony Allevato wrote: > > My 2 cents: Giving users checked subscripts for arrays will do more harm than > good for novice programmers—they're going to do the wrong thing with them. I'm torn... On the one hand, I see the logic in this. On

Re: [swift-evolution] [pitch] Comparison Reform

> On Apr 13, 2017, at 18:18, Xiaodi Wu via swift-evolution > wrote: > > `compare(_:)` does not merit a term-of-art exception when the Swift name is > clearly `compared(to:)`. No; in full grammatical pedanticity it should be compared(with:). “compare to” is for

Re: [swift-evolution] [pitch] Comparison Reform

Jaden, the proposal literally says that a compiler feature named "@_implements" is necessary for the proposed design to work. You can see WIP for that feature in the apple/swift repo. On Thu, Apr 13, 2017 at 19:55 Jaden Geller wrote: > > On Apr 13, 2017, at 5:18 PM,

Re: [swift-evolution] [pitch] Comparison Reform

Right; clearly, the difference between the proposed @_implements design and yours will be subtle (but, when it strikes, a totally different function is invoked) and it will be difficult for even advanced Swift users to understand. On Thu, Apr 13, 2017 at 20:29 Jaden Geller

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

Was the / intended or did you meant to write \? Personally I don’t think we’d need that behavior and can fallback to the natural way using a blank lines or explicit way using the \n character to solve that issue at the top or bottom of the multi-line string. The model I’m pushing already would

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

> 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

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

I don’t think it’s a good idea to add optionally character before the closing delimiter, because it could confuse the reader of the code on how exactly the actual string lines above will be stripped. My personal vision remains as the following example: // 1) """ Line_1 Line_2 """ // result

[swift-evolution] [pitch] Comparison Reform

Hi swift evolution, Here’s another pitch, for The Propoosal Formerly Known As Spaceship. Comparison Reform Proposal: SE- Authors: Robert Widmann , Jaden Geller , Harlan Haskins , Alexis

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

That would be so wrong, because it’s not obvious to anyone how long your string will be. """ foo """ I could tell you, that the string from above could have 10k characters, even if you wouldn’t believe me, as it was proposed (and included in yesterday’s toolchain) my claim can be true. The

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

This is not an assumptions but a fact that the trailing spaces cannot and should not exist without an explicit annotation for precision, otherwise the backslash looses one of its main and significant functionality. --  Adrian Zubarev Sent with Airmail Am 13. April 2017 um 15:13:50, Ricardo

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

Theoretically that would be enough and lightweight solution to that problem, I could live with that. Optimally stripping them automatically would be ideal, however I cannot tell how complicated this might be to implement. A warning that will popup when you included any trailing spaces in a

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

The result is not surprisingly to me, at least not if I follow the simplicity of my gist. "Line 1Line2" Notice I put quotes around the string to better showcase the result here in the mailing list. The backslash serves two jobs in lines s0 to s(n - 1): Disable new line injection.

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

Apologies if this has been suggested before, but going off of Andrew’s message, a simple syntax could be to use our existing Optional syntax: let array = ["foo", "bar", "baz"] let first = array[0] // type is `String` let third = array[2?] // type is `String?`, value is .some("baz") let fourth =

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

As already mentioned I revised my opinion about the last content line, because the model I summarized mimics perfectly how you’d write text paragraphs. I’d say most of the time string concatenation is used to combine strings on the same line. A string literal however should only represent the

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

I don't care much for trailing whitespace but I thought we should respect the trailing whitespace in the event that it is significant. If I'm worried about precision in a string, I turn on the display of whitespace characters and make sure everything is as expected. I also think it would

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

Now that I had some sleep I actually revise my opinion about the last line. I took a few hours to sum my thoughts together in a gist, here is a formatted version of it: https://gist.github.com/DevAndArtist/dae76d4e3d4e49b1fab22ef7e86a87a9 Simple ‘multi-line string literal’ model Core

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

Hi Adrian, My conclusion that we should leave it alone is based on the assumption that someone may consider the trailing whitespace significant and correct. > On Apr 13, 2017, at 9:05 AM, Adrian Zubarev > wrote: > > That would be so wrong, because it’s not

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

Doesn't the principle of least surprise applies here? In most other languages, the final \n is implicit in multi-line strings and heredocs: I think """↵foo↵foo↵" should be equal to "foo\nfoo\n", because this is what most developers will assume. Yes it will not play well with the standard

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

That would be good, I think because it would force everyone to be precise in regards to trailing whitespace. And I don't see that as a bad thing. > On Apr 13, 2017, at 9:54 AM, Adrian Zubarev via swift-evolution > wrote: > > I was really confused by your last

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

I was really confused by your last reply. Actually I’ve got a better idea for a fix-it. :-) let str_8 = """↵ foo··↵ """ warning: line # includes trailing space characters in multi-line string literal foo·· ~~ Fix-it: Insert "\n\" (after these

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

template void foo(T... args) { return bar(args...); } In this bad but simple example, bar is called with the same* parameters as foo. Parameter unpacking uses the postfix … operator. * To some extent. Doing the right thing adds a lot of noise. > Le 13 avr. 2017 à 11:18, David Sweeris

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

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

Re: [swift-evolution] [pitch] Comparison Reform

On Thu, Apr 13, 2017 at 7:51 PM, Jonathan Hull wrote: > I think “vastly” is vastly overstating it, especially since they are not > customization points… merely aliases. > It increases the number of methods on Comparable from 5 to 8, and it increases the number of standard

Re: [swift-evolution] [pitch] Comparison Reform

On Thu, Apr 13, 2017 at 11:00 PM, Jonathan Hull wrote: > Oh come on. You are exaggerating the issue here. As I said, there isn’t > really any extra maintenance needed and people are already familiar with > their meaning. It isn’t like they have to learn new archaic symbols.

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

We definitely should not alter the default subscript behavior of Array. Perhaps, it might be worthwhile to add a method `element(atIndex: Index) -> Element?` or some such method. It's hard to say whether it would be worth it; the desired behavior can be achieved with

Re: [swift-evolution] [pitch] Comparison Reform

On Thu, Apr 13, 2017 at 7:46 PM, Guillaume Lessard < gless...@tffenterprises.com> wrote: > > > On Apr 13, 2017, at 18:18, Xiaodi Wu via swift-evolution < > swift-evolution@swift.org> wrote: > > > > `compare(_:)` does not merit a term-of-art exception when the Swift name > is clearly

Re: [swift-evolution] [pitch] Comparison Reform

One more thought. I am generally in favor of this proposal, but since it is in the pitch stage, I wanted to offer an alternative approach that I didn’t see mentioned. Food for thought/discussion. What if, instead of repurposing comparable (and adding new functions for options like case

Re: [swift-evolution] [pitch] Comparison Reform

Oh come on. You are exaggerating the issue here. As I said, there isn’t really any extra maintenance needed and people are already familiar with their meaning. It isn’t like they have to learn new archaic symbols. Even HTML defines a special code for them because their use is common. There

Re: [swift-evolution] [pitch] Comparison Reform

> On Apr 13, 2017, at 2:42 PM, David Hart via swift-evolution > wrote: > > Looking good. A few comments inline: > >> On 13 Apr 2017, at 22:17, Ben Cohen via swift-evolution >> > wrote: >> Comparable >>

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

> On Apr 13, 2017, at 3:56 AM, Andrew Hart via swift-evolution > wrote: > > Recently I’ve been considering the lack of safety around array indexes. Swift > is designed with safety in mind, so this example would not compile: > > var myString: String? = “hello” >

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

> Am 13.04.2017 um 00:20 schrieb Brent Royal-Gordon : > > 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

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

Recently I’ve been considering the lack of safety around array indexes. Swift is designed with safety in mind, so this example would not compile: var myString: String? = “hello” myString.append(“ world!”) The string is optional, not guaranteed to exist, so the last line requires a “!” to

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

Oops, my apologies for misspelling your name. It was a typo. > On Apr 13, 2017, at 8:35 AM, Ricardo Parada via swift-evolution > wrote: > > Adriam > > Take a look at Brent's revised proposal.I personally thin it is perfect. > Take a look: > >

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

I think it's solid and thorough. I think it's winner. > On Apr 13, 2017, at 8:41 AM, Brent Royal-Gordon > wrote: > >> On Apr 13, 2017, at 5:35 AM, Ricardo Parada via swift-evolution >> > wrote: >> >> Take

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

I like the principle in general, but I have some concerns about the range syntax. Firstly my concern is that allowing either end of the range to be omitted feels like a possible bug to me, so I'm not sure if we should encourage that? I'm wondering if a slightly better alternative might to be

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

The retroactive conformance needs to be exportable. If one cannot vend a library that conforms standard library types to new protocols, then that is a non-starter. On Thu, Apr 13, 2017 at 06:07 Howard Lovatt wrote: > @Xiaodi, > > You can safely post-hoc add protocols

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

> On Apr 13, 2017, at 5:35 AM, Ricardo Parada via swift-evolution > wrote: > > Take a look at Brent's revised proposal.I personally thin it is perfect. > Take a look: > >

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

@Xiaodi, You can safely post-hoc add protocols and methods provided that they are final, do not override, and are not exported from the module. See version 2 of the proposal below. -- Howard. # Proposal: Split extension usage up into implementing methods and adding methods and protocols

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

 Thanks again Brent. This version looks great! I think we’re really getting there. > On 13 Apr 2017, at 13:41, Brent Royal-Gordon via swift-evolution > wrote: > >> On Apr 13, 2017, at 5:35 AM, Ricardo Parada via swift-evolution >>

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

Question: What is the benefit of disabling the indent stripping? I’m not even sure what I should imagine when I read “if the indent stripping is enabled”. My mental model is simple, the compiler looks for line where the closing tripled delimiter is. Takes all space characters in between the

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

Adriam Take a look at Brent's revised proposal.I personally thin it is perfect. Take a look: https://github.com/johnno1962a/swift-evolution/blob/master/proposals/0168-multi-line-string-literals.md Regarding what you are proposing: Trailing newline We need consensus on whether the trailing

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

I think most people would agree with “its a Not a Great Idea (™)”. The root argument is “out-of-bounds array access is a logic error”. > On 13.04.2017, at 16:54, David Sweeris via swift-evolution > wrote: > > > > > Sent from my iPhone > On Apr 13, 2017, at 07:34,

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

This might be too late, but anyway: > What is your evaluation of the proposal? Unsure. For archival purposes/NSCoding replacement this seems great. As the best way to do decode JSON from external APIs I find it at least to be very unconvincing. But then, I’m not sure if this is a goal of the

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

This has been proposed before. The current implementation is intentional, as seen on the swift-evolution repo: https://github.com/apple/swift-evolution/blob/master/commonly_proposed.md#strings-characters-and-collection-types

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

This seems inconsistent to me. 2 is 2... 2 itself is not optional. You wouldn't expect 2 to be unwrapped. Best Josh Sent from my iPhone On Apr 13, 2017, at 08:48, Jeff Kelley via swift-evolution > wrote: Apologies if this has been

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

> And all of this is only an issue if you write the conformance by hand in the > first place. Usually, you won't. Brent, given that this API is designed not just for NSKeyedArchiver-like usage, but to form the basis of serialization to and from JSON, among other network types, I really don’t

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

AFAIK arrays use the same “subscripts” [1] feature as other collections. So this feature would have to be tagged onto subscripts in general. I see a few problems with you suggestion: - How do you differentiate between an out-of-bounds subscript access in an array with optional elements, e.g.

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

Sent from my iPhone > On Apr 13, 2017, at 07:34, Jeff Kelley wrote: > > Apologies if this has been suggested before, but going off of Andrew’s > message, a simple syntax could be to use our existing Optional syntax: > > let array = ["foo", "bar", "baz"] > > let first

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

Yes, the idea was to key off of an optional index. something like this: > extension Array { > public subscript(_ index: Int?) -> Element? { > guard let i = index, i < endIndex else { return nil } > > return self[i] > } > } > > let array = ["foo", "bar", "baz"] >

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

I’ve update my gist to reflect that now: https://gist.github.com/DevAndArtist/dae76d4e3d4e49b1fab22ef7e86a87a9 Simple ‘multi-line string literal’ model Core features: Omitting of (most) backslashes for ". Altering the string with implicit new line injection at the end of the line. Sting

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

Btw. shouldn’t we let the core return the current proposal officially for revision, or otherwise it will need to stay ‘long enough’ in it’s revisioned pitch state before we can kick off a second review process! Just saying. --  Adrian Zubarev Sent with Airmail Am 13. April 2017 um 18:21:29,

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

> On Apr 13, 2017, at 08:53, Josh Parmenter wrote: > > This seems inconsistent to me. 2 is 2... 2 itself is not optional. You > wouldn't expect 2 to be unwrapped. Correct. I think the idea was that "2?" would get converted to an `Optional`, which would then call a

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

On Apr 12, 2017, at 07: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