Re: [swift-evolution] [Pitch] Support for pure functions. Part n + 1.

Exactly, there is none. What I was trying to describe is that -> would become the conditional operator that could swallow purity and impurity. However if one would want to be explicit about purity, you’d have to use ~> instead. --  Adrian Zubarev Sent with Airmail Am 17. Februar 2017 um

Re: [swift-evolution] Swift 4: Support for static libs / modular development.

Sure, thank you. If SwiftPM gets a working integration in Xcode 9, that could do it. Raphael On Fri, Feb 17, 2017 at 1:50 PM Ole Begemann wrote: > > > On 17 Feb 2017, at 10:28, Raphael Sebbe via swift-evolution < > swift-evolution@swift.org> wrote: > > > > I'm not fully aware of

Re: [swift-evolution] Basic element-wise operator set for Arrays, Arrays of Arrays, etc.

If you're simply looking for elementwise multiply without performance requirements, map(*) is a very succinct spelling. Performant implementations for these operations like you have in Matlab rely on special math libraries. Apple platforms have Accelerate that makes this possible, and other

Re: [swift-evolution] [Pitch] Support for pure functions. Part n + 1.

I do not see the rationale behind marking impure functions explicitly. The useful property is to be pure, in case a function is impure or it's status is unknown you just have to assume the worse, i.e. that it is impure. The arrow proposals -> vs. ~> vs. => are not really much shorter than the 4

Re: [swift-evolution] [Pitch] Support for pure functions. Part n + 1.

On 17.02.2017 20:18, Matthew Johnson via swift-evolution wrote: If we do go with the => means pure one option for closures without a signature would be something like this: {= $0.pureMethod() } I feel this will be more clear: {=> in $0.pureMethod() } i.e. "in" is required to highlight that

Re: [swift-evolution] [Pitch] Support for pure functions. Part n + 1.

> But given the scope capturing nature of closures I was actually wondering if > this 'purity' should be applied to closures. I think It should, pure closure cannot have outside references and therefore cannot create reference cycles even though they are escaping. I tend toward using the =>

Re: [swift-evolution] Sequence/Collection Enhancements

I definitely find the intent here to be an interesting view at performant collection operations; in Foundation we have exposed IndexSet to do this type of thing. When Foundation migrated to structural types it was really obvious to make IndexSet a structure - it was a logical change because it

Re: [swift-evolution] final + lazy + fileprivate modifiers

What you are really asking for is a way of flexibly designating a "unit of code" within a module, for which the general solution is submodules. The objection is that, instead of tackling that issue, these are suggestions to invent ad-hoc units of code (scope + extensions only in the same file,

[swift-evolution] Basic element-wise operator set for Arrays, Arrays of Arrays, etc.

Dear all, In swift (just as in many other languages) I have been terribly missing the operators like .* ./ .^ as I know them from MATLAB/Scilab. These operators are very handy and do element-wise operations on vectors or matrices of the same size. So for instance A*B is a matrix

Re: [swift-evolution] [Pitch] Support for pure functions. Part n + 1.

That problem could be solved with the combining tilde, however it isn’t easy, because it’s simply not easy to type. If ~> would describe the pure function and -> an impure function then the combination of both would be ≃>. One thing I noticed, you said that the function itself will become pure

Re: [swift-evolution] Swift 4, stage 2 starts now

> On Feb 16, 2017, at 10:17 PM, Chris Lattner wrote: > > On Feb 16, 2017, at 4:18 PM, Ted Kremenek via swift-evolution > > wrote: >> Deferring ABI Stability from Swift 4 >> >> Given the importance of getting the

Re: [swift-evolution] [Manifesto] Ownership

> On Feb 17, 2017, at 12:08 PM, John McCall wrote: >> On Feb 17, 2017, at 4:50 AM, Adrian Zubarev > > wrote: >> Hi John, would you mind creating a markdown document for this manifesto in >>

Re: [swift-evolution] [Pitch] Support for pure functions. Part n + 1.

If we do go with the => means pure one option for closures without a signature would be something like this: {= $0.pureMethod() } This keeps the closure concise and uses = to indicate purity. The fact that it looks a little bit like assignment is interesting since a pure function always has

Re: [swift-evolution] final + lazy + fileprivate modifiers

Sent from my iPhone > On Feb 17, 2017, at 01:02, Rien wrote: > > >> On 17 Feb 2017, at 03:36, David Sweeris via swift-evolution >> wrote: >> >> >>> On Feb 16, 2017, at 14:34, Slava Pestov via swift-evolution >>>

Re: [swift-evolution] [Pitch] Support for pure functions. Part n + 1.

Another usecase would be for the type aliases: typealias PureFunc = pure (Some)->Else Or pure typealias PureFunc = (Some)->Else I'm not sure where the keyword should stand On Feb 17, 2017, 12:03 PM -0500, Matthew Johnson via swift-evolution , wrote: > > > On Feb

Re: [swift-evolution] [Proposal] [Stage–2] `return` consistency for single-expressions

OK, just wanted to confirm that you are not suggesting to allow this in 'guard'. On 17.02.2017 18:57, Adrian Zubarev via swift-evolution wrote: Exactly, couldn’t say that any better. |guard| was part of this proposal in the first draft but was dropped due the same reasons Matthew just

Re: [swift-evolution] [Manifesto] Ownership

> On Feb 17, 2017, at 4:50 AM, Adrian Zubarev > wrote: > Hi John, would you mind creating a markdown document for this manifesto in > https://github.com/apple/swift/tree/master/docs > ? :) > > Yes, it should go

Re: [swift-evolution] [Pitch] Support for pure functions. Part n + 1.

We could do: pure let closure = { _-> Else in } But given the scope capturing nature of closures I was actually wondering if this 'purity' should be applied to closures. After all an inline defined func would do. On Feb 17, 2017, 11:59 AM -0500, Matthew Johnson ,

Re: [swift-evolution] [Pitch] Support for pure functions. Part n + 1.

How do you suggest a closure indicate its purity? Something like this? { pure in $0.property } > On Feb 17, 2017, at 10:57 AM, Florent Vilmart wrote: > > We were discussing the topic yesterday with others and some suggested adding > a pure keyword, for improved

Re: [swift-evolution] [Pitch] Support for pure functions. Part n + 1.

> On Feb 17, 2017, at 10:55 AM, David Sweeris wrote: > > > On Feb 17, 2017, at 08:49, Matthew Johnson > wrote: > >> >>> On Feb 17, 2017, at 10:46 AM, David Sweeris via swift-evolution >>>

Re: [swift-evolution] [Pitch] Support for pure functions. Part n + 1.

We were discussing the topic yesterday with others and some suggested adding a pure keyword, for improved readability, just before the function declaration: Ex: pure func(a:Some) -> Else {} On Feb 17, 2017, 11:51 AM -0500, Matthew Johnson via swift-evolution ,

Re: [swift-evolution] [Pitch] Support for pure functions. Part n + 1.

> On Feb 17, 2017, at 08:49, Matthew Johnson wrote: > > >> On Feb 17, 2017, at 10:46 AM, David Sweeris via swift-evolution >> wrote: >> >> >> On Feb 17, 2017, at 08:21, Adrian Zubarev via swift-evolution >>

Re: [swift-evolution] [Pitch] Support for pure functions. Part n + 1.

> On Feb 17, 2017, at 10:46 AM, David Sweeris via swift-evolution > wrote: > > > On Feb 17, 2017, at 08:21, Adrian Zubarev via swift-evolution > > wrote: > >> I haven’t yet read all the feedback in this

Re: [swift-evolution] [Pitch] Support for pure functions. Part n + 1.

> On Feb 17, 2017, at 08:21, Adrian Zubarev via swift-evolution > wrote: > > I haven’t yet read all the feedback in this topic but I’d like to throw some > bikeshedding of mine into the room. :) > > How about this? > > Version 1: func(pure) … > Version 2: func

Re: [swift-evolution] [Pitch] Support for pure functions. Part n + 1.

> On Feb 17, 2017, at 10:33 AM, Adrian Zubarev > wrote: > > Regardless the issue you described with rethrows couldn’t we simply > explicitly tell the compiler the closures type which would include the pure > arrow? > > let _: (T) ~> SomeType = { … } > >

Re: [swift-evolution] [Pitch] Support for pure functions. Part n + 1.

> On Feb 17, 2017, at 7:37 AM, David Hart wrote: > > On 17 Feb 2017, at 08:59, Nicolas Fezans via swift-evolution > > wrote: > >> > Not only that, but even if you pass a value type as a parameter, that >> > value

Re: [swift-evolution] [Pitch] Support for pure functions. Part n + 1.

Regardless the issue you described with rethrows couldn’t we simply explicitly tell the compiler the closures type which would include the pure arrow? let _: (T) ~> SomeType = { … } That is similar to the behavior we now have with IUOs. (let myView: UIView = self.view inside UIViewController

Re: [swift-evolution] Removing enumerated?

> On 17 Feb 2017, at 16:53, Vladimir.S via swift-evolution > wrote: > > Btw, in context of discussion of indices, > should this be fixed soon: > > func function(c: C) { > for index in c.indices { >print(c[index]) > } > } > ERROR: cannot subscript a value of

Re: [swift-evolution] [Pitch] Support for pure functions. Part n + 1.

I haven’t yet read all the feedback in this topic but I’d like to throw some bikeshedding of mine into the room. :) How about this? Version 1: func(pure) … Version 2: func label(…) ~> ReturnType --  Adrian Zubarev Sent with Airmail Am 17. Februar 2017 um 17:16:49, Anton Zhilin via

Re: [swift-evolution] [Pitch] Support for pure functions. Part n + 1.

I didn’t mean to emphasize any specific syntax. I’m fine with either @const, @constexpr, @pure or =>. Anyway, I see no reason why generic functions shouldn’t be supported in any of the suggested models. 2017-02-17 19:08 GMT+03:00 Abe Schneider : +1. I think this is a

Re: [swift-evolution] [Pitch] Support for pure functions. Part n + 1.

2017-02-17 17:13 GMT+03:00 T.J. Usiyan : It is my opinion that you are describing an entirely different, and > somewhat orthogonal, feature. I would like the feature that you describe. > Constant expressions are powerful and open up quite a few optimizations. > What

Re: [swift-evolution] [Pitch] Refactor Metatypes

Personally I’d like a shortcut like AnyType, but it won’t work as a typealias, because it will create a circle reference between AnyType and AnyType. However, there is a small possibility that this type might be generalized like Any (now possibly AnyObject) directly into the language. That

Re: [swift-evolution] [Pitch] Support for pure functions. Part n + 1.

+1. I think this is a great idea. As I was following this thread, I was wondering if someone might suggest the C++ constexpr syntax. Would this support generics? E.g. could you do: @constepxr func foo(a:S, b:S) { return a+b } and have that be done at compile time? While this

Re: [swift-evolution] [Proposal] [Stage–2] `return` consistency for single-expressions

Exactly, couldn’t say that any better. guard was part of this proposal in the first draft but was dropped due the same reasons Matthew just described. --  Adrian Zubarev Sent with Airmail Am 17. Februar 2017 um 15:46:33, Matthew Johnson (matt...@anandabits.com) schrieb: > On Feb 17, 2017,

Re: [swift-evolution] Removing enumerated?

Btw, in context of discussion of indices, should this be fixed soon: func function(c: C) { for index in c.indices { print(c[index]) } } ERROR: cannot subscript a value of type 'C' with an index of type 'C.Indices.Iterator.Element' ? (have access for Swift 3.0.2 Release only for now,

Re: [swift-evolution] [Pitch] Support for pure functions. Part n + 1.

+1 for pure functions +1 for combining them with constexpr -1 for the syntax originally proposed +1 for pure or @pure keywords (before func and before a closure opening { ) One thing is probably worth considering if pure functions and closures are combined with constexpr and evaluated at

Re: [swift-evolution] [Proposal] [Stage–2] `return` consistency for single-expressions

> On Feb 17, 2017, at 8:41 AM, Vladimir.S via swift-evolution > wrote: > > I think I like this, but what about guard? > > func f(x: Int) -> Int { > guard x > 0 else { return 0 } > ... > } > > vs > > func f(x: Int) -> Int { > guard x > 0 else { 0 } > …

Re: [swift-evolution] [Proposal] [Stage–2] `return` consistency for single-expressions

I think I like this, but what about guard? func f(x: Int) -> Int { guard x > 0 else { return 0 } ... } vs func f(x: Int) -> Int { guard x > 0 else { 0 } ... } ? On 17.02.2017 11:20, Adrian Zubarev via swift-evolution wrote: I’d like to revive an additive proposal that

Re: [swift-evolution] [Pitch] Support for pure functions. Part n + 1.

> On Feb 16, 2017, at 3:18 PM, T.J. Usiyan via swift-evolution > wrote: > > I am ok with a keyword but `pure` in front of func doesn't work well with > inline closures. The `=>` function arrow syntax is a clever way to avoid making pure functions heaver

Re: [swift-evolution] [Proposal] [Stage–2] `return` consistency for single-expressions

+1. I have always thought this sugar should be consistent throughout the language. > On Feb 17, 2017, at 2:20 AM, Adrian Zubarev via swift-evolution > wrote: > > I’d like to revive an additive proposal that couldn’t make it into Swift 3. > This proposal has a

Re: [swift-evolution] [Pitch] Support for pure functions. Part n + 1.

Anton, It is my opinion that you are describing an entirely different, and somewhat orthogonal, feature. I would like the feature that you describe. Constant expressions are powerful and open up quite a few optimizations. What constexpr addresses is not purity, at the heart of it. Pure

Re: [swift-evolution] [Pitch] Support for pure functions. Part n + 1.

> On 17 Feb 2017, at 08:59, Nicolas Fezans via swift-evolution > wrote: > > > Not only that, but even if you pass a value type as a parameter, that value > > type might have reference types as ivars. > > I think that arguments passed to a pure function shall be

Re: [swift-evolution] [Pitch] Refactor Metatypes

I guess, now is the time? The response on this has been positive, both for the new metatype syntax and separation of static and dynamic metatypes. I’ve got one more feature in mind since then—a shorthand of AnyType ≡ AnyType. Would this addition be worth extra syntax? Is it feasible from current

Re: [swift-evolution] [Pitch] Support for pure functions. Part n + 1.

My vision of “pure” functions was the following: 1. Compiler automatically marks all functions and expressions as pure, wherever possible - We should be interested not in “Haskell-ish pure” functions, but in “computable during compilation” functions - Therefore I prefer to

Re: [swift-evolution] Swift 4: Support for static libs / modular development.

> On 17 Feb 2017, at 10:28, Raphael Sebbe via swift-evolution > wrote: > > I'm not fully aware of the state of discussion, so sorry if it is already > being addressed. I wanted to bring some feedback and awareness about the need > of a supported way to build app

Re: [swift-evolution] final + lazy + fileprivate modifiers

On 17.02.2017 11:29, Slava Pestov via swift-evolution wrote: On Feb 17, 2017, at 12:09 AM, Charlie Monroe via swift-evolution > wrote: True, what I meant was a wider feedback - let's face it, there are many more Swift developers now

Re: [swift-evolution] [Pitch] Support for pure functions. Part n + 1.

I like the idea of having pure functions in Swift, but my first thought is; should we have to declare it at all? Is it not easier to just have the compiler automatically flag a function as pure or not? With that in mind we don't need any new syntax, but a simple @pure attribute should be

Re: [swift-evolution] Does protocol support add to an object's size?

> On 15 Feb 2017, at 17:51, Daryle Walker via swift-evolution > wrote: > > I don't know how protocol support works. I asking because I want to maintain > the stride of an array being the total count times the stride of the element, > which would complicate nominal

Re: [swift-evolution] Dictionary Enhancements

> On 17 Feb 2017, at 00:26, Ben Cohen via swift-evolution > wrote: > > Hi swift-evolution, > > Add capacity property and reserveCapacity() method. Just wanted to quickly weigh in on this one, but I wonder if this might make most sense coming as a slight

Re: [swift-evolution] [Pitch] Support for pure functions. Part n + 1.

This syntax is actually a really clean solution, which can be generalised to arguments and composes well: A -> B => C -> D vs A -> (@pure B -> C -> D) Begin Message Group: gmane.comp.lang.swift.evolution MsgID:

Re: [swift-evolution] [Pitch] Support for pure functions. Part n + 1.

This syntax is actually a really clean solution, which can be generalised to arguments and composes well: A -> B => C -> D vs A -> (@pure B -> C -> D) Begin Message Group: gmane.comp.lang.swift.evolution MsgID:

Re: [swift-evolution] [Manifesto] Ownership

Hi John, would you mind creating a markdown document for this manifesto in https://github.com/apple/swift/tree/master/docs? :)___ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution

[swift-evolution] Swift 4: Support for static libs / modular development.

I'm not fully aware of the state of discussion, so sorry if it is already being addressed. I wanted to bring some feedback and awareness about the need of a supported way to build app components as *static libraries* in Swift. We've moved most of our new developments to Swift 3. Our apps are

Re: [swift-evolution] final + lazy + fileprivate modifiers

> On 16 Feb 2017, at 23:34, Slava Pestov via swift-evolution > wrote: > > While we’re bikeshedding, I’m going to add my two cents. Hold on to your hat > because this might be controversial here. > > I think both ‘private’ and ‘fileprivate’ are unnecessary

Re: [swift-evolution] final + lazy + fileprivate modifiers

> On Feb 17, 2017, at 9:29 AM, Slava Pestov wrote: > > >> On Feb 17, 2017, at 12:09 AM, Charlie Monroe via swift-evolution >> > wrote: >> >> True, what I meant was a wider feedback - let's face it, there are many

Re: [swift-evolution] final + lazy + fileprivate modifiers

> On Feb 17, 2017, at 12:09 AM, Charlie Monroe via swift-evolution > wrote: > > True, what I meant was a wider feedback - let's face it, there are many more > Swift developers now than 2 years ago. > > My objection is not to the documentation itself, but to the

Re: [swift-evolution] [Proposal] `return` consistency for single-expressions

Such something went wrong with the `[Stage-2]` annotation?  --  Adrian Zubarev Sent with Airmail Am 17. Februar 2017 um 09:20:41, Adrian Zubarev (adrian.zuba...@devandartist.com) schrieb: I’d like to revive an additive proposal that couldn’t make it into Swift 3. This proposal has a small

[swift-evolution] [Proposal] [Stage–2] `return` consistency for single-expressions

I’d like to revive an additive proposal that couldn’t make it into Swift 3. This proposal has a small improvement to the language compared to other big features currently being proposed. It almost feels like a bug fix rather than a new feature, but it still needs a full and quick review

Re: [swift-evolution] final + lazy + fileprivate modifiers

True, what I meant was a wider feedback - let's face it, there are many more Swift developers now than 2 years ago. My objection is not to the documentation itself, but to the fact that I'm unnecessarily exposing an internal implementation detail to the rest of the module. Being able to hide

Re: [swift-evolution] [Pitch] Support for pure functions. Part n + 1.

> Not only that, but even if you pass a value type as a parameter, that value type might have reference types as ivars. I think that arguments passed to a pure function shall be checked against containing such references or objects that contains such references themselves: I guess that this check

<    1   2