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

[Lucas Neiva via swift-evolution]

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, 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 = array[0] // type is `String`
>> let third = array[2?] // type is `String?`, value is .some("baz")
>> let fourth = array[3?] // type is `String?`, value is .none
> 
> That was my thought, too, but it's not valid Swift. I tried it in a 
> playground before I sent my reply. At least in Xcode 8.3.1, it gives an error 
> about ambiguous calls (it can't decide if you're trying to call the stdlib 
> subscript or the `(_: Index?) -> Element?` one from the extension), and if 
> you fix that by adding an argument label, the real issue is revealed which is 
> that saying "x?" doesn't return "x wrapped in an optional"; it thinks you're 
> trying to do Optional chaining on a non-optional value, which isn't allowed.
> 
> I wouldn't object to adding that "trailing '?' wraps the value" behavior (or 
> maybe "¿", since they really would have the opposite result), in which case 
> this should work fine (although the choice of argument label, or lack 
> thereof, will likely still be bikeshedded)
> 
> Anyway, unless someone who knows more about this than I do (probably most of 
> you) says this functionality is a Bad Idea (™), I'm in favor of it.
> 
> - Dave Sweeris
> ___
> 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] Adding safety to arrays

[Lucas Neiva via swift-evolution]

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. `[String?]`, `[Int: String?]`
- Isn’t it conflating two different things, to use the same `?` operator here
- You’d probably have to add a new construct similar to the existing subscripts 
feature


[1] 
https://developer.apple.com/library/content/documentation/Swift/Conceptual/Swift_Programming_Language/Subscripts.html


> On 13.04.2017, at 16:34, Jeff Kelley via swift-evolution 
>  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 = array[0] // type is `String`
> let third = array[2?] // type is `String?`, value is .some("baz")
> let fourth = array[3?] // type is `String?`, value is .none
> 
> Jeff Kelley
> 
> slauncha...@gmail.com | @SlaunchaMan | jeffkelley.org
> 
>> On Apr 13, 2017, at 8:19 AM, David Sweeris via swift-evolution 
>>  wrote:
>> 
>>> 
>>> 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”
>>> myString.append(“ world!”)
>>> 
>>> The string is optional, not guaranteed to exist, so the last line requires 
>>> a “!” to force-unwrap it.
>>> 
>>> 
>>> 
>>> public func tableView(_ tableView: UITableView, numberOfRowsInSection 
>>> section: Int) -> Int {
>>> let section = self.sections[section]
>>> 
>>> return section.items.count
>>> }
>>> 
>>> In this example, we could provide a section number that goes beyond the 
>>> bounds of the self.sections array, without any warning.
>>> 
>>> My suggestion is perhaps arrays should by default return an optional when 
>>> given an index, and of course they’d support forced-unwrapping too. So you 
>>> could then do this:
>>> 
>>> let section = self.sections[section]
>>> if section == nil {
>>> return 0
>>> } else {
>>> return section!.items.count
>>> }
>>> 
>>> Or you could do this:
>>> 
>>> let section = self.sections[section]!
>>> 
>>> return section.items.count
>>> 
>>> Of course this would be less convenient in a lot of cases, but this is the 
>>> 1 place where apps seem to encounter a crash, crashing for the same reason 
>>> that’s especially avoided across most of the rest of Swift.
>> 
>> My understanding is that we need the current behavior to meet performance 
>> goals. We’ve discussed adding a “safe” subscript before, but the discussion 
>> usually fizzles out when no clear winner for the argument label emerges.
>> 
>> - Dave Sweeris
>> ___
>> 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

[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] [Pitch] Remove type-inference for stored property

[Lucas Neiva via swift-evolution]

(Forgot CC. How's that Discord coming along? )

> On 7 Apr 2017, at 13:07, Lucas Neiva  wrote:
> 
> +1
> 
> I think declaring property types is beneficial to readability.
> 
> It seems to me like properties are on the same level as functions, where 
> types are also not inferred. I see them both as “members”, if you like.
> 
> Another thing is that computed properties also require an explicit type, 
> which sometimes trips me up a bit when mixing computed and normal properties.
> 
>> On Apr 07, 2017, at 09: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?
>> 
>> 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

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

[Lucas Neiva via swift-evolution]

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

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

[Lucas Neiva via swift-evolution]

I think it's worth simplifying the access levels by removing `fileprivate`. 
Changing `private` to cover the common file-level cases brings no disadvantages 
IMO, since there's always the option of moving a declaration to a separate 
file. (I seem to disagree with a lot of opinions on here, that seem to want 
more fine grained access level control. I just don't see much tangible 
benefits, as composing protocols with the current access control levels is 
enough.)



I wouldn't do the compatibility mode since source conversion seems to work well 
enough. But I guess source compatibility is a hard goal.



---



My main question with all of this: Why is `private` a "soft default"? What's the point of a 
"soft default"? I think it should be _the_ default. `private` as default would promote 
encapsulation. It also just seems to make more sense than defining `internal` as the default, which is the 
"middle one".


On Mar 21, 2017, at 12:55 AM, Douglas Gregor via swift-evolution 
 wrote:



Hello Swift community,

The review of SE-0159 "Fix Private Access Levels" begins now and runs through 
March 27, 2017. The proposal is available here:

https://github.com/apple/swift-evolution/blob/master/proposals/0159-fix-private-access-levels.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/0159-fix-private-access-levels.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] Why doesn't Swift allow a variable and a function with the same name?

[Lucas Neiva via swift-evolution]

> On 31 Jan 2017, at 01:59, Joe Groff via swift-evolution 
>  wrote:
> 
> To be honest, I would say that there's no "reason" for this, except as 
> lingering effects of our early "functions have simple names, and arguments 
> have labeled tuple type" model. If we had originally implemented the language 
> with its current (at least aspirational) Smalltalk-ish compound-names model, 
> we probably would have ended up allowing this, since the var and func do 
> formally have different names. The ability to reference a function by only 
> the first segment of its name is likewise legacy of the original model, 
> though it happens to be useful since good naming hygiene encourages different 
> base names for different things to begin with.

It seams like there is discussion to be had, comparing these models:

[A] functions have simple names, and arguments have labeled tuple type 
model
[B] model where we strictly require the labels for referring to n-ary 
functions (e.g. "insert(cell:, into:)" instead of "insert")

---

> Example that does not compile:
> 
>let randomArray = randomArray(withCapacity: 4096)

I like [B] because it does solve cases of ambiguity, where only using the 
base-name of the func causes the "Variable used within its own initial value” 
described by Michael.

What are some advantages of [A]? I assume that tuple splatting (i.e. passing a 
tuple of args when calling a n-ary function) is one of them, or is that not 
related?
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Move placement of 'throws' statement

[Lucas Neiva via swift-evolution]

I like "throwing" as a prefix. It's reads well and fits very nicely with 
"mutating".

Remembering where to put the keyword for is also easier if it's at the 
beginning, where it fits grammatically as "throwing func".

> On 26 Dec 2016, at 19:53, Micah Hainline via swift-evolution 
>  wrote:
> 
> I'd prefer the placement at the very end, I do think it would improve 
> readability, especially when taking closures as parameters and returning 
> closures. However, I don't think the value would be worth the cost of 
> breaking existing code. At the least if this were to go forward I would think 
> we'd want both styles to work even if one was preferred or the other was 
> deprecated. 
> 
> 
> 
>> On Dec 26, 2016, at 12:41 PM, Derrick Ho via swift-evolution 
>>  wrote:
>> 
>> I personally do not see anything wrong with its current placement.
>> 
>> It may be there because it was based on an existing cocoa pattern from 
>> objective-c
>> 
>> - (NSString *)bazWithError:(NSError **)error { ... }
>> 
>> Because objective c could only return one thing, using pointer-to-pointer 
>> was needed to deliver more than one.
>> 
>> When swift came along it became this...
>> 
>> func baz(error: NSErrorPointer) -> String
>> 
>> The style felt old-fashioned and was replaced with throw.
>> 
>> func baz() throws -> String
>> 
>> 
>> The evolution is consistent.  The pattern is familiar.  I think we should 
>> keep the placement of throw as it is.
>> 
>> On Mon, Dec 26, 2016 at 9:38 AM thislooksfun via swift-evolution 
>>  wrote:
>> Hello Swifters,
>> 
>> I've been writing a lot more Swift code recently, and I have found that the 
>> default placement of the 'throws' declaration is often confusing, especially 
>> to those of us switching from languages where the type of errors thrown is 
>> explicitly defined (like Java)
>> 
>> For example,
>> // This is pretty clear, this can throw an error
>> 
>> func foo() throws
>> 
>> { ... }
>> 
>> 
>> 
>> // Also pretty clear, this returns a String
>> 
>> func bar() -> String
>> 
>> { ... }
>> 
>> 
>> 
>> // Confusing. Does this throw a String? Does it return a String? Does it do 
>> both?
>> 
>> // I personally keep reading this as 'this can throw a String'
>> 
>> func baz() throws -> String
>> 
>> 
>> 
>> // Equivalent code in Java (not a model, just for clarification of why the 
>> above is confusing)
>> 
>> String baz() throws StringFormatException
>> I therefore suggest either tweaking the syntax around, or moving, the 
>> `throws` keyword to avoid this confusion.
>> 
>> Some ideas I've had:
>> // Add a comma to separate them
>> 
>> func baz() throws, -> String
>> 
>> 
>> 
>> // Move `throws` to the end
>> 
>> func baz() -> String throws
>> 
>> 
>> 
>> // Change it to a prefix modifier (like `mutating`)
>> 
>> throwing func baz() -> String
>> 
>> I'm still not sold on any of the above syntaxes, but I would love to hear 
>> your feedback.
>> 
>> This would affect existing code, but it would be a fairly small change that 
>> would result in very large readability improvements, especially for 
>> newcomers, and especially for those coming for a language such as Java.
>> 
>> -thislooksfun (tlf)
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> ___
>> 
>> 
>> 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] Move placement of 'throws' statement

[Lucas Neiva via swift-evolution]

> On 26 Dec 2016, at 19:53, Micah Hainline via swift-evolution 
>  wrote:
> 
> I'd prefer the placement at the very end, I do think it would improve 
> readability, especially when taking closures as parameters and returning 
> closures. However, I don't think the value would be worth the cost of 
> breaking existing code. At the least if this were to go forward I would think 
> we'd want both styles to work even if one was preferred or the other was 
> deprecated. 
> 
> 
> 
>> On Dec 26, 2016, at 12:41 PM, Derrick Ho via swift-evolution 
>>  wrote:
>> 
>> I personally do not see anything wrong with its current placement.
>> 
>> It may be there because it was based on an existing cocoa pattern from 
>> objective-c
>> 
>> - (NSString *)bazWithError:(NSError **)error { ... }
>> 
>> Because objective c could only return one thing, using pointer-to-pointer 
>> was needed to deliver more than one.
>> 
>> When swift came along it became this...
>> 
>> func baz(error: NSErrorPointer) -> String
>> 
>> The style felt old-fashioned and was replaced with throw.
>> 
>> func baz() throws -> String
>> 
>> 
>> The evolution is consistent.  The pattern is familiar.  I think we should 
>> keep the placement of throw as it is.
>> 
>> On Mon, Dec 26, 2016 at 9:38 AM thislooksfun via swift-evolution 
>>  wrote:
>> Hello Swifters,
>> 
>> I've been writing a lot more Swift code recently, and I have found that the 
>> default placement of the 'throws' declaration is often confusing, especially 
>> to those of us switching from languages where the type of errors thrown is 
>> explicitly defined (like Java)
>> 
>> For example,
>> // This is pretty clear, this can throw an error
>> 
>> func foo() throws
>> 
>> { ... }
>> 
>> 
>> 
>> // Also pretty clear, this returns a String
>> 
>> func bar() -> String
>> 
>> { ... }
>> 
>> 
>> 
>> // Confusing. Does this throw a String? Does it return a String? Does it do 
>> both?
>> 
>> // I personally keep reading this as 'this can throw a String'
>> 
>> func baz() throws -> String
>> 
>> 
>> 
>> // Equivalent code in Java (not a model, just for clarification of why the 
>> above is confusing)
>> 
>> String baz() throws StringFormatException
>> I therefore suggest either tweaking the syntax around, or moving, the 
>> `throws` keyword to avoid this confusion.
>> 
>> Some ideas I've had:
>> // Add a comma to separate them
>> 
>> func baz() throws, -> String
>> 
>> 
>> 
>> // Move `throws` to the end
>> 
>> func baz() -> String throws
>> 
>> 
>> 
>> // Change it to a prefix modifier (like `mutating`)
>> 
>> throwing func baz() -> String
>> 
>> I'm still not sold on any of the above syntaxes, but I would love to hear 
>> your feedback.
>> 
>> This would affect existing code, but it would be a fairly small change that 
>> would result in very large readability improvements, especially for 
>> newcomers, and especially for those coming for a language such as Java.
>> 
>> -thislooksfun (tlf)
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> ___
>> 
>> 
>> 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] Pattern matching with Arrays

[Lucas Neiva via swift-evolution]

As a fellow functional programming aficionado, I'd like this very much, too. 
From lurking here, I think something like this is of low priority at the moment 
since it is and additive feature.

Especially head/tail matching looks very interesting. I also like the syntax 
you suggest here:
> case let [first, next...]:


> case let [first, last]:

The binding should be more like "[let first, let last]" though, to be more like 
the tuple matching. For the above also: "case [let head, let tail...]".


> On 18 Dec 2016, at 06:43, Mathew Sanders via swift-evolution 
>  wrote:
> 
> I've just joined the list (hi!) so not sure if this has been discussed in the 
> past.
> 
> Curious to hear if a future version of Swift might ever include some sort of 
> pattern-matching extended to Arrays. Maybe something like the following:
> 
> let numbers: [Int]
> 
> switch numbers {
> case []:
> // to match an empty array
> 
> case [1, 2, 3]:
> // to match array with specific values
> 
> case [_, _, _]:
> // to match array with 3 Ints
> 
> case let [first, last]:
> // match a 2 element array and bind first and last elements
> 
> case let [first, next...]:
> // to match array with at least one element
> // bind first element, and bind other elements (could be empty)
> // first: Int, next: [Int]
> }
> 
> I love the pattern matching on tuples, and would love to see if extend to 
> Arrays as well, but not sure if it fits with future goals for the language.
> 
> 
> ___
> 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