My favorite proposal so far is one that was posted a while ago, [Int * 4]. I
think that this syntax looks pretty Swifty. There isn't an oddball subscript
operator like with Int[4], and there isn't a need to allow generics to support
values as parameters. It's clear that [Int * 4] will be array-l
Comments inline.
> On Jun 1, 2017, at 10:49 PM, Daryle Walker via swift-evolution
> wrote:
>
> Current array literal syntax (i.e. “[a, b, c]”) works for dense and/or linear
> arrays, but isn’t so great later on when we add fixed-size arrays and the
> defined (non-zero) elements are sparse and
Current array literal syntax (i.e. “[a, b, c]”) works for dense and/or linear
arrays, but isn’t so great later on when we add fixed-size arrays and the
defined (non-zero) elements are sparse and/or the array is multi-dimensional
(not nested). In these cases I’m thinking of leading each element w
On Fri, Jun 2, 2017 at 12:06 AM, John McCall wrote:
>
> You're misunderstanding me. I have explicitly said, several times, that I
> agree that the impact on tuple destructuring in closures is a serious
> regression. There have *also* been objections to losing argument-splat
> behavior, and whil
I vote to revert it to current behavior. Then we can take time to come up with
the correct answer for future Swift.
If we don’t revert and then end up changing it again later, we will break
everybody’s code twice...
Thanks,
Jon
> On Jun 1, 2017, at 2:39 PM, Pavol Vaskovic via swift-evolution
Is the version you suggest to add to my list for the Swift syntax currently
valid as of SE-0110 in Swift 4?
On Thursday, June 1, 2017 9:32 PM, Vladimir.S wrote:
On 01.06.2017 19:31, Tommaso Piazza wrote:
> Dear all,
>
> I made a comparison of Swift's 4 lack of tuple unsplatting, here i
> On Jun 1, 2017, at 2:39 PM, Pavol Vaskovic wrote:
>
> On Thu, Jun 1, 2017 at 8:52 PM, John McCall via swift-evolution
> mailto:swift-evolution@swift.org>> wrote:
>
> I understand that there are developers who dislike SE-0110's impact on
> certain kinds of functional programming, but that is
On Thu, Jun 1, 2017 at 8:52 PM, John McCall via swift-evolution <
swift-evolution@swift.org> wrote:
>
> I understand that there are developers who dislike SE-0110's impact on
> certain kinds of functional programming, but that is a very broad complaint
> that is unlikely to reach consensus or acce
To add more real-world project data to this discussion, I just did a test
migration of Siesta to Swift 4 using the 2017-05-30 snapshot.
Nothing earth-shattering follows — just more practical evidence that the
problem needs attention.
Here’s what I found:
(1) The lack of tuple destructing under
On 01.06.2017 21:52, John McCall wrote:
On Jun 1, 2017, at 3:25 AM, Vladimir.S wrote:
On 01.06.2017 0:42, John McCall wrote:
On May 31, 2017, at 2:02 PM, Stephen Celis wrote:
On May 28, 2017, at 7:04 PM, John McCall via swift-evolution
wrote: Yes, I agree. We need to add back
tuple dest
On 01.06.2017 22:46, T.J. Usiyan wrote:
I, for one, would be willing to accept Xiaodi's suggestion involving `let`–especially
if (pipe dream follows) we could use the same syntax in functions/methods to
destructure parameters.
Yes, Xiaodi's suggestion also was very attractive. Just to remind:
I, for one, would be willing to accept Xiaodi's suggestion involving
`let`–especially if (pipe dream follows) we could use the same syntax in
functions/methods to destructure parameters.
On Thu, Jun 1, 2017 at 3:32 PM, Vladimir.S via swift-evolution <
swift-evolution@swift.org> wrote:
> On 01.06.
On 01.06.2017 19:31, Tommaso Piazza wrote:
Dear all,
I made a comparison of Swift's 4 lack of tuple unsplatting, here is how it stands in
comparison with other languages
https://gist.github.com/blender/53f9568617654c38a219dd4a8353d935
Thank you! Very useful information. And also I really l
> On Jun 1, 2017, at 3:25 AM, Vladimir.S wrote:
>
> On 01.06.2017 0:42, John McCall wrote:
>>> On May 31, 2017, at 2:02 PM, Stephen Celis wrote:
On May 28, 2017, at 7:04 PM, John McCall via swift-evolution
wrote:
Yes, I agree. We need to add back tuple destructuring in closure
> On 1 Jun 2017, at 17:31, Tommaso Piazza via swift-evolution
> wrote:
>
> >>> On May 28, 2017, at 7:04 PM, John McCall via swift-evolution
> >>> mailto:swift-evolution@swift.org>> wrote:
> >>>
> >>> Yes, I agree. We need to add back tuple destructuring in closure
> >>> parameter
> >>> lists
These are inherently cross-platform concepts that can be represented both as
literals (like the current color, file, and image) or as Swift-specific types,
allowing the realization details to be pushed to platforms (macOS, iOS, common
linux libraries).
Some ideas about literals here:
https://g
I would like to emphasize how much I would appreciate a standard type such
as this
```
public enum OriginLocation {
case lowerLeft
case upperLeft
#if os(OSX)
public static let defaultPlatformLocation: OriginLocation = .lowerLeft
#endif
#if os(iOS)
public static let def
Dear all,
I made a comparison of Swift's 4 lack of tuple unsplatting, here is how it
stands in comparison with other languages
https://gist.github.com/blender/53f9568617654c38a219dd4a8353d935
On Thursday, June 1, 2017 12:25 PM, Vladimir.S via swift-evolution
wrote:
On 01.06.2017 0:4
Just wanted to add my two-cents to this discussion, but in terms of syntax I
think that the basic method for specifying size should be with some kind of
type variables, like so:
struct MyFixedArray { … }
The idea being that we can then use size as a variable anywhere within the code
fo
I am not suggesting open sourcing UIKit or Cocoa (or any platform specific UI
code). I am suggesting creating a very small open source swift-corelib that
sits on top of foundation, and adds basic visual concepts like Color, Image,
AttributedText, and (hat tip to T.J.) BezierPaths. Things where
On 01.06.2017 0:42, John McCall wrote:
On May 31, 2017, at 2:02 PM, Stephen Celis wrote:
On May 28, 2017, at 7:04 PM, John McCall via swift-evolution
wrote:
Yes, I agree. We need to add back tuple destructuring in closure parameter
lists because this is a serious usability regression. If we
> On 1 Jun 2017, at 09:57, Jonathan Hull wrote:
>
> I could be wrong, but my understanding is that Foundation is being open
> sourced as well, and distributed with Swift across various platforms.
It is already open source; the source code for the Swift/Linux port is here:
https://github.com/ap
I could be wrong, but my understanding is that Foundation is being open sourced
as well, and distributed with Swift across various platforms.
I can make my own framework, but it wouldn’t be portable in the same way. You
couldn’t use my code on Linux, Windows, or even the Watch/TV unless I direc
> On 1 Jun 2017, at 03:48, Jonathan Hull via swift-evolution
> wrote:
>
> Hi Everyone,
>
> I am not sure whether Swift Evolution’s charter extends to the common
> foundation framework which will be distributed with Swift (If not, then I
> hope this request reaches the right people).
>
> I w
24 matches
Mail list logo
