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

[Adrian Zubarev via swift-evolution]

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 18:59:17, Nicolas Fezans (nicolas.fez...@gmail.com) 
schrieb:

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 letters of the pure keyword but just confusing and frightening  
for newcomers (BTW __pure exists in GCC if I remember well) whereas  
"pure func" is something that people can easily google in case they  
need to learn the concept. The different arrows are very compact but  
feel a bit like J, which is a language I would not like swift to look  
like.  

For closure I would rather see it as in this example  

[2.0 , 3.0 , 4.0].map(pure {(x: Double)->Double in return x*x})  

just pure preceding the closure and it would preceeds "func" in "pure  
func". (it could be @pure in both case too)  

Nicolas  


On Fri, Feb 17, 2017 at 6:36 PM, Adrian Zubarev via swift-evolution  
 wrote:  
> 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 or  
> impure depending on the other function. Doesn’t this imply that -> is  
> exactly this pure OR impure function. It’s either or but never both right?  
> Otherwise it might lead us to a huge breaking change. A suggestion building  
> on top of the arrow syntax we could have:  
>  
> pure function: ~>  
> impure function: ≈> (That’s a ‘double tilde’)  
> pure or impure function: -> (it is as to top and bottom tilde was merged and  
> smoothed together)  
>  
>  
>  
> --  
> Adrian Zubarev  
> Sent with Airmail  
>  
> Am 17. Februar 2017 um 17:43:21, Matthew Johnson (matt...@anandabits.com)  
> schrieb:  
>  
> Well sure, but then you have just supplied the type annotation. I am  
> describing a specific scenario where an API can accept a function that is  
> pure or a function that is impure and will have the purity of the function  
> passed into it.  
>  
>  
> ___  
> 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] Swift 4: Support for static libs / modular development.

[Raphael Sebbe via swift-evolution]

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 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.
>
> Part of the recently accepted (for Swift 4) SE-0146 "Package Manager
> Product Definitions" [1] is support for static library products in the
> Swift Package Manager.
>
> SwiftPM is not Xcode, of course. I just thought I'd mention it.
>
> [1]:
> https://github.com/apple/swift-evolution/blob/master/proposals/0146-package-manager-product-definitions.md
>
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Xiaodi Wu via swift-evolution]

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 implementations of BLAS/LAPACK do the same for
Linux and Windows platforms.

There has been talk on this list of writing Swifty wrappers for such
libraries. The core team has said that the way to get such facilities into
Swift corelibs is to write your own library, get broad adoption, then
propose its acceptance here. Currently, several libraries like Surge and
Upsurge offer vectorized wrappers in Swifty syntax for Apple platforms; it
would be interesting to explore whether the same can be done in a
cross-platform way.

But simply adding sugar to the standard library will not give you the
results you're looking for (by which I mean, the performance will be
unacceptable), and there's no point in providing sugar for something that
doesn't work like the operator implies (Matlab's elementwise operators
offer _great_ performance).




On Fri, Feb 17, 2017 at 11:46 Nicolas Fezans via swift-evolution <
swift-evolution@swift.org> wrote:

> 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 multiplication (and the number of
> columns for A must correspond to the number of rows in B), whereas A*B
> (with A and B of same size) returns the matrix of that size whose
> elements are obtained by making the product of each pair of elements
> at the same location in A and B.
>
> So just a small example:
> [1.0 , 2.5 , 3.0] .* [2.0 , 5.0 , -1.0] -> [2.0 , 12.5 , -3.0]
>
> The same exists for the division (./) or for instance for the power
> function (.^). Here another example with *, .* , ^ , and .^ to show
> the difference in behaviour in MATLAB/Scilab
>
> >> A = [1 2 3 ; 4 5 6 ; 7 8 9];
> >> A*A
>
> ans =
>
> 303642
> 668196
>102   126   150
>
> >> A.*A
>
> ans =
>
>  1 4 9
> 162536
> 496481
>
> >> A^2
>
> ans =
>
> 303642
> 668196
>102   126   150
>
> >> A.^3
>
> ans =
>
>  1 827
> 64   125   216
>343   512   729
>
> For addition and subtraction the regular operator (+ and -) and their
> counterparts (.+ and .-) are actually doing the same. However note
> that since the + operator on arrays is defined differently (it does an
> append operation), there is a clear use for a .+ operation in swift.
>
> Version 1:
> In principle, we can define it recursively, for instance ...+ would be
> the element-wise application of the ..+ operator, which is itself the
> element-wise application of the .+ operator, which is also the
> element-wise application of the + operator.
>
> Version 2:
> Alternatively we could have a concept where .+ is the element-wise
> application of the .+ operator and finally when reaching the basic
> type (e.g. Double when starting from Double) the .+ operator
> needs to be defined as identical to the + operator. I do prefer this
> version since it does not need to define various operators depending
> on the "level" (i.e. Double -> level 0, [Double] -> level 1,
> [[Double]] -> level 2, etc.). I could make this option work without
> generics, but as I tried it with generics it generated a runtime error
> as the call stack grew indefinitely (which does not seem as something
> that should actually happen since at each call the level gets lower
> and when reaching 0 it all solvable).
>
>
> Anyway, I would like to discuss first the basic idea of defining these
> element-wise operators for Arrays, before seeing how far it would be
> interesting to go on this and how the implementation should exactly
> look like. As a support for the discussion, you will find hereunder a
> first shot for a generics-based solution for the aforementioned
> Version 1 and going up to level 3 and for the 4 basic operators + - *
> /
> (BTW you can see that I have twice the same code, once with the
> protocol conformance to my own protocols and once for FloatingPoint:
> is there a way to specific the protocol conformance to protocol A or
> to protocol B at once?)
>
> I personally think that these operators are very practical and helping
> programmers to directly "vectorize" the way they write their
> operations. Often these element-wise operations replace loops and I
> think that the required syntax analysis (on compiler's side) to
> vectorize the code is much simpler then. In swift, I have been using
> map, flatMap, zip + map with a closure to make these type of
> operations, but I think that the proposed operators would be a much
> clearer and expressive way of coding this for most basic 

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

[Nicolas Fezans via swift-evolution]

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 letters of the pure keyword but just confusing and frightening
for newcomers (BTW __pure exists in GCC if I remember well) whereas
"pure func" is something that people can easily google in case they
need to learn the concept. The different arrows are very compact but
feel a bit like J, which is a language I would not like swift to look
like.

For closure I would rather see it as in this example

[2.0 , 3.0 , 4.0].map(pure {(x: Double)->Double in return x*x})

just pure preceding the closure and it would preceeds "func" in "pure
func". (it could be @pure in both case too)

Nicolas


On Fri, Feb 17, 2017 at 6:36 PM, Adrian Zubarev via swift-evolution
 wrote:
> 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 or
> impure depending on the other function. Doesn’t this imply that -> is
> exactly this pure OR impure function. It’s either or but never both right?
> Otherwise it might lead us to a huge breaking change. A suggestion building
> on top of the arrow syntax we could have:
>
> pure function: ~>
> impure function: ≈> (That’s a ‘double tilde’)
> pure or impure function: -> (it is as to top and bottom tilde was merged and
> smoothed together)
>
>
>
> --
> Adrian Zubarev
> Sent with Airmail
>
> Am 17. Februar 2017 um 17:43:21, Matthew Johnson (matt...@anandabits.com)
> schrieb:
>
> Well sure, but then you have just supplied the type annotation.  I am
> describing a specific scenario where an API can accept a function that is
> pure or a function that is impure and will have the purity of the function
> passed into it.
>
>
> ___
> 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] Support for pure functions. Part n + 1.

[Vladimir.S via swift-evolution]

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 this is a "modifier" not the 
closure body.

in case you have parameters: {=> x,y in $0.pureMethod(x,y) }




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 to have a return value.

Sent from my iPad

On Feb 17, 2017, at 10:59 AM, Matthew Johnson via swift-evolution
> wrote:


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 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
>, 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
> 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 label(…) ~> ReturnType|


Version 2 is going to upset those who use "~>" as an operator.

As the # of possible attributes grows, having an obvious grouping
mechanism for them, like version 1, might be worthwhile simply to help
make the list clearer. What about allowing "@(list, of, attributes)"
instead of "@list, @of, @attributes”?


That would be a little bit awkward for attributes that are
parameterized.  And if we did do this we should allow the parens to be
omitted when there is only one attribute.



- 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



___
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] Support for pure functions. Part n + 1.

[André “Zephyz” Videla via swift-evolution]

> 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 => sign since it doesn't require a lot of change, it 
has a nice lightweight syntax and seems different enough from -> .
The pure keyword in front of the function signature looks like a lot of noise 
for such a simple concept. And It will only get worse in function signatures.

see the difference between 

func pureCurryCompose(f: @pure(B) -> C) -> @pure(@pure(A) -> B) -> 
(@pure(A) -> C)

and 

func pureCurryCompose(f: (B) => C) => ((A) => B) => (A) => C

The second is easiest to read.

(of course I would argue that 

func pureCurryCompose(f: B => C) => (A => B) => (A => C) 

is the most readable of all but I'm too late for that proposal )

> On 17 Feb 2017, at 18:02, Florent Vilmart via swift-evolution 
>  wrote:
> 
> 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 , 
> wrote:
>> 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 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 
>>> >, 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 
> > 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 label(…) ~> ReturnType
> Version 2 is going to upset those who use "~>" as an operator.
> 
> As the # of possible attributes grows, having an obvious grouping 
> mechanism for them, like version 1, might be worthwhile simply to help 
> make the list clearer. What about allowing "@(list, of, attributes)" 
> instead of "@list, @of, @attributes”?
 
 That would be a little bit awkward for attributes that are parameterized.  
 And if we did do this we should allow the parens to be omitted when there 
 is only one attribute.
 
> 
> - 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

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Sequence/Collection Enhancements

[Philippe Hausler via swift-evolution]

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 already was 
used as that concept in the Objective-C APIs. One of it’s biggest features is 
that it interoperates with NSArray/NSMutableArray which unfortunately it does 
not operate upon Array/Collection etc as of current. But there are APIs like 
UI/NS CollectionView that some of the primitive interoperation is based upon 
IndexSet which mirror NSArray/NSMutableArray making modeling really nice. As of 
current Swift is lacking some of those handy parallels. The IndexSet type has 
been used across many APIs in the SDK (as well as third party code). I wonder 
if it would be reasonable to sink an encapsulation type of the collection of 
ranges (as an efficient store) down and make it generic for the Index type. 
That way we would have a cohesive story when it comes to interoperation with 
on-going improvements that might happen in UIKit/AppKit/Foundation etc where 
the changes like this would interoperate well.

There are also a few other methods that I think might be worth investigating; 

non mutation
Fetching elements out of a collection given a sequence of ranges.
Fetching a sequence of ranges where a predicate matches elements (and perhaps 
even a sequence of ranges as a constraint upon that predicate)

mutation
Inserting a sequence of elements into the collection at indexes defined by a 
sequence of ranges
Replacing elements at indexes defined by a sequence of ranges with elements 
from a sequence

If we modified IndexSet to be generic (and perhaps moved it further down to 
interoperate with collection) I am certain that this would work really well 
with the already established APIs we have (just making bridged NSIndexSets 
really a IndexSet ). However this would mean that we would need some sort 
of way of indicating types were “Countable” which might be a decent addendum to 
the collection protocol cluster.


I think that overall these APIs have worked nicely with other counterparts 
(perhaps with a slight caveat of the matching of replacement counts and index 
counts). Additionally I am quite certain that having an encapsulating efficient 
storage for a sequence of ranges can allow for some really nice performance 
improvements and getting the performance point right is not always easy or 
obvious; so having the higher level APIs to handle these can not only be easier 
for the developer but also offer some really great performance optimizations 
too.

I have already tinkered with the idea of using IndexSet on Data and it is 
amazing; I can easily write really complex parsers for doing awful things like 
parsing mach-o headers from executables or other such things. I have also 
tinkered with the idea of making a slice type that is a sparse slice (it breaks 
some other assumptions of how collections work) and that works pretty nicely 
too (I think that should be a further discussion and this is probably not the 
time to introduce that idea just yet).

Hope that gives somethings to chew on from a frameworks perspective.

Cheers!
Philippe Hausler

> On Feb 16, 2017, at 4:39 PM, Ben Cohen via swift-evolution 
>  wrote:
> 
> Hi swift-evolution,
> 
> Following up on Ted’s post regarding the opening up of stage 2, I’m starting 
> a thread to discuss additive algorithms for Sequence and Collection.
> 
> Here is a list of commonly requested algorithms to operate on Sequence or 
> Collection:
> 
> In-place transformations:
> transform elements in a MutableCollection using a closure i.e. in-place map
> remove(where:) that takes a predicate i.e. in-place filter
> remove(indices:) that takes a Sequence of Index
> bulk operations (replace, remove, insert) on RangeReplaceableCollection for a 
> Sequence of subranges
> Sorting:
> change sort/sorted/partition to be stable
> possibly add an explicitly unstable sort
> provide partial sorting i.e. the _n_th lowest element of a sequence
> Select a random element of a RandomAccessCollection (note this could include 
> a random element of 0.. Check if all elements in a Sequence match a predicate (i.e. 
> !contains(!predicate))
> reduce with an inout argument for the running value (PR for proposal here: 
> https://github.com/apple/swift-evolution/pull/587 
> )
> cycle – repeat a collection over and over.
> scan/accumulate/reductions/some other spelling of a reduce that returns the 
> running values (previously proposed: 
> https://github.com/apple/swift-evolution/blob/master/proposals/0045-scan-takewhile-dropwhile.md
>  
> )
> rotation of elements in a collection (deferred proposal: 
> 

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

[Xiaodi Wu via swift-evolution]

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,
scope + extensions only in the same module, class + extensions only in the
same file + subclasses only in the same module), and it is possible to
invent arbitrary many of these.

There is, objectively, an actual minimum number of access modifiers, which
is two. Those two are: visible only inside the unit of code, or visible
both inside and outside the unit of code. In Swift, those are spelled
internal and public. Everything else here is really talking about better or
more flexible ways of defining a unit of code.


On Fri, Feb 17, 2017 at 06:21 Vladimir.S via swift-evolution <
swift-evolution@swift.org> wrote:

> 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 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 it from the rest IMHO leads to better
> >> though-through API that is indeed meant to be exposed; whereas exposing
> >> internal details leads to allowing various quick hacks instead. We know
> >> these quick hacks very well from the ObjC world by accessing private
> >> parts of the object via duck typing or setting values via KVO.
> >>
> >> At least this is my experience with which the less implementation
> details
> >> are exposed to the outer world, the better.
> >
> > I think the fundamental disagreement we’re seeing in this thread is the
> > meaning of “outer world”; to some, it means “users of your module”. To
> > others, it also means “other developers on my team who are working on
> other
> > files in the module”.
> >
> > Personally I feel enforced encapsulation of implementation detail to the
> > latter group is less important than the former, and can be handled by
> > convention. Whereas other users of your module definitely benefit from
> > access control and being able to consume a clearly-defined interface.
>
> I assume we are discussing access modifiers mainly for the former group,
> i.e. when we are "inside" the module (even when this module is written by
> the same one person, and especially when it is written by the group).
>
> "handled by convention" - are we talking about something like declaring
> props and methods as __privateprop , m_privateprop etc and write comments
> to mark that they should not be used outside of some scope? Is it really
> Swifty and acceptable for the modern language? Will this help to prevent
> some mistakes with incorrect access? Is it better than simple and clean
> schema for access modifiers and compiler's help?  I don't understand this.
>
> IMO, access modifiers is very known and handy abstraction to distinct
> levels of access and to structure code many developers knows about and use
> in other languages.
> At the end, if one wants to keep all internal - no problems!, you can do
> this right now, just don't use fileprivate/private/etc.
>
> Yes, I agree we need a simple and clean schema, not over-complicated, we
> need nice keywords, we need a required minimum of access modifiers,
> not more, and I do believe currently we don't have this minimum.
>
> Was already suggested, trying again(I do believe this could be a
> compromised solution to suit needs of the main part of developers):
> * (as currently) public/open -> outside of the module
> * (as currently) internal -> inside module
> * private -> inside file (instead of fileprivate)
> * protected(or *other* keyword) -> inside file + subtype in the
> *same module*
>
> What objections could be made for this?
> Thank you.
>
> >
> > Slava
> >
> >>
> >>> On Feb 17, 2017, at 8:54 AM, Xiaodi Wu  >>> > wrote:
> >>>
> >>> That blog post starts out right away to say that it's a response to
> >>> community feedback. Moreover, the scenario you describe was just as
> >>> possible in 2014 as it is now. Finally, then as now, it's unclear why
> >>> you consider documentation to be "not pretty." After all, your reader
> >>> would need to consult the documentation before using a variable anyway.
> >>> On Fri, Feb 17, 2017 at 01:04 Charlie Monroe via swift-evolution
> >>> > wrote:
> >>>
> >>> I'm aware of this, but that's fairly a long time ago - before Swift
> >>> was open source and had community feedback and before Swift was
> used
> >>> widely among developers.
> >>>
> >>>  

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

[Nicolas Fezans via swift-evolution]

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 multiplication (and the number of
columns for A must correspond to the number of rows in B), whereas A*B
(with A and B of same size) returns the matrix of that size whose
elements are obtained by making the product of each pair of elements
at the same location in A and B.

So just a small example:
[1.0 , 2.5 , 3.0] .* [2.0 , 5.0 , -1.0] -> [2.0 , 12.5 , -3.0]

The same exists for the division (./) or for instance for the power
function (.^). Here another example with *, .* , ^ , and .^ to show
the difference in behaviour in MATLAB/Scilab

>> A = [1 2 3 ; 4 5 6 ; 7 8 9];
>> A*A

ans =

303642
668196
   102   126   150

>> A.*A

ans =

 1 4 9
162536
496481

>> A^2

ans =

303642
668196
   102   126   150

>> A.^3

ans =

 1 827
64   125   216
   343   512   729

For addition and subtraction the regular operator (+ and -) and their
counterparts (.+ and .-) are actually doing the same. However note
that since the + operator on arrays is defined differently (it does an
append operation), there is a clear use for a .+ operation in swift.

Version 1:
In principle, we can define it recursively, for instance ...+ would be
the element-wise application of the ..+ operator, which is itself the
element-wise application of the .+ operator, which is also the
element-wise application of the + operator.

Version 2:
Alternatively we could have a concept where .+ is the element-wise
application of the .+ operator and finally when reaching the basic
type (e.g. Double when starting from Double) the .+ operator
needs to be defined as identical to the + operator. I do prefer this
version since it does not need to define various operators depending
on the "level" (i.e. Double -> level 0, [Double] -> level 1,
[[Double]] -> level 2, etc.). I could make this option work without
generics, but as I tried it with generics it generated a runtime error
as the call stack grew indefinitely (which does not seem as something
that should actually happen since at each call the level gets lower
and when reaching 0 it all solvable).


Anyway, I would like to discuss first the basic idea of defining these
element-wise operators for Arrays, before seeing how far it would be
interesting to go on this and how the implementation should exactly
look like. As a support for the discussion, you will find hereunder a
first shot for a generics-based solution for the aforementioned
Version 1 and going up to level 3 and for the 4 basic operators + - *
/
(BTW you can see that I have twice the same code, once with the
protocol conformance to my own protocols and once for FloatingPoint:
is there a way to specific the protocol conformance to protocol A or
to protocol B at once?)

I personally think that these operators are very practical and helping
programmers to directly "vectorize" the way they write their
operations. Often these element-wise operations replace loops and I
think that the required syntax analysis (on compiler's side) to
vectorize the code is much simpler then. In swift, I have been using
map, flatMap, zip + map with a closure to make these type of
operations, but I think that the proposed operators would be a much
clearer and expressive way of coding this for most basic operations.

Note that I mention and consider only Arrays here, but the idea might
be extended to other collections/containers.

I am very curious to see the feedback of the community on this!


Nicolas




infix operator .+
infix operator ..+
infix operator ...+
infix operator .-
infix operator ..-
infix operator ...-
infix operator .*
infix operator ..*
infix operator ...*
infix operator ./
infix operator ../
infix operator .../

protocol ImplementsInnerAddition   { static func + (_: Self,_: Self)->Self }
protocol ImplementsInnerSubtraction{ static func - (_: Self,_: Self)->Self }
protocol ImplementsInnerMultiplication { static func * (_: Self,_: Self)->Self }
protocol ImplementsInnerDivision   { static func / (_: Self,_: Self)->Self }

func .+ (lhs: [T], rhs: [T]) -> [T] where T:ImplementsInnerAddition {
guard (lhs.count != rhs.count) else { return zip(lhs,rhs).map({(a:
T,b: T)->T in return a + b }) }
guard (lhs.count != 1) else { return rhs.map({(b: T)->T
   in return lhs[0] + b }) }
guard (rhs.count != 1) else { return lhs.map({(a: T)->T
   in return a + rhs[0] }) }
assert(false,"Element-wise operation can only be applied to arrays
of same size or alternatively if one of the array is of size
1",file:#file,line:#line)
}
func .+ (lhs: [T], rhs:  T ) -> [T] where T:ImplementsInnerAddition
{ return lhs.map({(a: T)->T  in return  a 

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

[Adrian Zubarev via swift-evolution]

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 or 
impure depending on the other function. Doesn’t this imply that -> is exactly 
this pure OR impure function. It’s either or but never both right? Otherwise it 
might lead us to a huge breaking change. A suggestion building on top of the 
arrow syntax we could have:

pure function: ~>
impure function: ≈> (That’s a ‘double tilde’)
pure or impure function: -> (it is as to top and bottom tilde was merged and 
smoothed together)


-- 
Adrian Zubarev
Sent with Airmail

Am 17. Februar 2017 um 17:43:21, Matthew Johnson (matt...@anandabits.com) 
schrieb:

Well sure, but then you have just supplied the type annotation.  I am 
describing a specific scenario where an API can accept a function that is pure 
or a function that is impure and will have the purity of the function passed 
into it.  
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Ted Kremenek via swift-evolution]

> 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 core ABI and the related fundamentals 
>> correct, we are going to defer the declaration of ABI stability out of Swift 
>> 4 while still focusing the majority of effort to get to the point where the 
>> ABI can be declared stable.
>> 
> Given where we are in the yearly schedule, I think that this is a pragmatic 
> decision.  ABI stability is far more important to Apple than it is to most 
> developers, so I’m happy to see that you’re prioritizing the needs of the 
> community (improved compile time, compiler stability, etc), particularly 
> given the importance of doing the right thing for the long term success of 
> Swift.
> 
> Beyond that, I agree that it is prudent to continue work on the many ABI 
> stability tasks despite it not being a goal for Swift 4.  Given the 
> significance of declaring ABI stability, it would be great to get these tasks 
> really nailed down early in the Swift 5 schedule so you have time to bake it 
> out.

Absolutely — giving time for these changes to bake to make sure we did not miss 
anything is essential part of keeping the focus in Swift 4 on core ABI 
stability tasks (and other language fundamentals that impact ABI and source 
stability).  That thinking went into the scoping of stage 2.

> 
> Do you have any idea what the typical download size impact of the Swift 4 
> libraries will be on the ARM64 slice of a typical iOS app?  I know that many 
> of the ABI-related optimizations also contribute to a significant code size 
> improvement, but don’t know how folks expect that to net out.  Do you think 
> that it is plausible to get the overlays coalesced with the stdlib into a 
> single dylib, improving app launch times?

This is an interesting idea, but off-topic for swift-evolution.  A better place 
to discuss this is swift-dev.

That said, there are tradeoffs here: creating a single dylib slightly 
complicates the long-term goal of sinking the overlay APIs back into the OS, 
and the number of overlays is not guaranteed to remain fixed so the tradeoffs 
of creating a single dylib versus multiple are nuanced.  The focus has been on 
the ABI-related optimizations, such as reducing the size of mangled symbols, 
which are tasks that absolutely need to be done before ABI stability.___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Manifesto] Ownership

[John McCall via swift-evolution]

> 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 
>> https://github.com/apple/swift/tree/master/docs 
>> ? :)
>> 
>> 
> Yes, it should go in the repository.  That commit is pending, but the in 
> meantime, you can see the document properly rendered at:
>   
> https://github.com/rjmccall/swift/blob/4c67c1d45b6f9649cc39bbb296d63663c1ef841f/docs/OwnershipManifesto.md
>  
> 
Ah, and of course the second I send this, my PR gets merged. :)

The new URL is:
  https://github.com/apple/swift/blob/master/docs/OwnershipManifesto.md 


John.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Matthew Johnson via swift-evolution]

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 to have a return value. 

Sent from my iPad

> On Feb 17, 2017, at 10:59 AM, Matthew Johnson via swift-evolution 
>  wrote:
> 
> 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 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 
>>> , 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 
  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 label(…) ~> ReturnType
 Version 2 is going to upset those who use "~>" as an operator.
 
 As the # of possible attributes grows, having an obvious grouping 
 mechanism for them, like version 1, might be worthwhile simply to help 
 make the list clearer. What about allowing "@(list, of, attributes)" 
 instead of "@list, @of, @attributes”?
>>> 
>>> That would be a little bit awkward for attributes that are parameterized.  
>>> And if we did do this we should allow the parens to be omitted when there 
>>> is only one attribute.
>>> 
 
 - 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
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[David Sweeris via swift-evolution]

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 
>>>  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 complications that 
>>> only serve to clutter the language.
>>> 
>>> It would make a lot more sense to just have internal and public only. No 
>>> private, no fileprivate, no lineprivate, no protected. It’s all silly.
>> 
>> Eh, I've used `private` to keep myself honest in terms of going through some 
>> book-keeping functions instead of directly accessing a property.
> 
> But is that not an argument to get rid of ‘private’ & ‘fileprivate’?
> 
> With great power there comes great responsibility ;-)

I don't see how... I used `private` on some dicts that interact with each other 
(faking a lightweight database) to ensure I was using my type's subscript 
functions (which handle updating all the dicts correctly) instead of directly 
accessing the dictionaries in some areas where the interactions theoretically 
wouldn't matter. Since I was able to mark those properties as private, I know 
that all the access to those properties goes through the proper book-keeping 
functions. Not only does this reduce the opportunity for bugs, it makes it far 
simpler to change the implementation later if I decide it should be backed by a 
"proper" database since everything that directly touches the storage will be 
right there in the type definition instead of spread through however many 
extensions across however many files.

- Dave Sweeris 
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Florent Vilmart via swift-evolution]

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 17, 2017, at 10:55 AM, David Sweeris  > (mailto:daveswee...@mac.com)> wrote:
> >
> > On Feb 17, 2017, at 08:49, Matthew Johnson  > (mailto:matt...@anandabits.com)> 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 
> > > >  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 label(…) ~> ReturnType
> > > > >
> > > > >
> > > > >
> > > >
> > > > Version 2 is going to upset those who use "~>" as an operator.
> > > >
> > > > As the # of possible attributes grows, having an obvious grouping 
> > > > mechanism for them, like version 1, might be worthwhile simply to help 
> > > > make the list clearer. What about allowing "@(list, of, attributes)" 
> > > > instead of "@list, @of, @attributes”?
> > >
> > > That would be a little bit awkward for attributes that are parameterized.
> >
> > Are there any parameterized attributes other than "@inline(always|never)”?
>
> I am not sure, but there has been discussion of introducing them. For 
> example, regardless of what syntax we choose for indicating a public enum is 
> closed it will need to have an optional parameter indicating the first 
> version of the library in which it was closed (which can be omitted if it was 
> closed the first time it appeared). One option for indicating this is to use 
> an attribute.
> >
> > > And if we did do this we should allow the parens to be omitted when there 
> > > is only one attribute.
> > Agreed.
> >
> > - 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] [Proposal] [Stage–2] `return` consistency for single-expressions

[Vladimir.S via swift-evolution]

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



--
Adrian Zubarev
Sent with Airmail

Am 17. Februar 2017 um 15:46:33, Matthew Johnson (matt...@anandabits.com
) schrieb:



> 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 }
> …
> }

Any time you have a guard statement you no longer have a single
expression. There is at least one expression in the guard clause itself,
at least one in the else block, and at least one following the guard
statement.

>
> ?
>
> On 17.02.2017 11:20, 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 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 process.
>>
>> You can read the formatted version here:
>> https://github.com/apple/swift-evolution/pull/608
>>
>>
>>  |return| consistency for single-expressions
>>
>>  * Proposal: SE-
>>

>>  * Author: Adrian Zubarev 
>>  * Status: *Awaiting review*
>>  * Review manager: TBD
>>
>>
>>Introduction
>>
>> Any single-expression closure can omit the |return| statement. This
>> proposal aims to make this feature more consistent in some other corners of
>> the language.
>>
>> Original swift-evolution thread: * [Pitch] [Stage–2] |return| consistency
>> for single-expressions * [Pitch] (Bofore Swift 3) Make |return| optional in
>> computed properties for a single case
>> 

>>
>>
>>Motivation
>>
>> Closures can omit the |return| and have an inferred return type:
>>
>> |let _ = { 42 } // Type: () -> Int let _ = [1,2,3].map { $0 * 5 } // T == 
Int |
>>
>> There are also value returning code blocks in the language that feel the
>> same but are inconsistent to the mentioned feature:
>>
>> |// Read-write computed property: var integer: Int { get { return 2016 } set
>> { /* do some work */ } } // Read-only computed property: var string: String
>> { return "hello swift" } // Function: func pi() -> Double { return 3.141 }
>> // Read-Write subscript: subscript(index: Int) -> Int { get { return index
>> % 2 } set { /* do some work */ } } // Read-only subscript: subscript(index:
>> Int) -> Int { return index * 2 } |
>>
>>
>>Proposed solution
>>
>> Make |return| optional for the following top level code blocks that only
>> contain a single expression:
>>
>>  * /variable-declaration/
>>  * /getter-setter-block/
>>  * /getter-clause/
>>  * /function-body/
>>  * /subscript-declaration/
>>
>> That will allow us to rewrite the above example to:
>>
>> |// Read-Write computed property: var integer: Int { get { 2016 } ... } //
>> Read-only computed property: var string: String { "hello swift" } //
>> Function: func pi() -> Double { 3.141 } // Read-Write subscript:
>> subscript(index: Int) -> Int { get { index % 2 } ... } // Read-only
>> subscript: subscript(index: Int) -> Int { index * 2 } |
>>
>> *Possible real world example:*
>>
>> |// Today public struct Character { public let source: Module.Source private
>> let _pointer: UnsafePointer public var value:
>> Swift.Character { return self._pointer.pointee } ... } // Rewritten: public
>> struct Character { ... public var value: Swift.Character {
>> self._pointer.pointee } ... } |
>>
>>
>>Impact on existing code
>>
>> None, this change will only relax some existing rules.
>>
>>
>>Alternatives considered
>>
>> Leave this as is and live with such inconsistency.
>>
>>
>>
>> --
>> Adrian Zubarev
>> Sent with Airmail
>>
>>
>>
>> ___
>> 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] [Manifesto] Ownership

[John McCall via swift-evolution]

> 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 in the repository.  That commit is pending, but the in 
meantime, you can see the document properly rendered at:
  
https://github.com/rjmccall/swift/blob/4c67c1d45b6f9649cc39bbb296d63663c1ef841f/docs/OwnershipManifesto.md
 


John.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Florent Vilmart via swift-evolution]

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 , 
wrote:
> 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  > (mailto:flor...@flovilmart.com)> wrote:
> > 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 
> > , 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 
> > > >  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 label(…) ~> ReturnType
> > > > >
> > > > >
> > > > >
> > > >
> > > > Version 2 is going to upset those who use "~>" as an operator.
> > > >
> > > > As the # of possible attributes grows, having an obvious grouping 
> > > > mechanism for them, like version 1, might be worthwhile simply to help 
> > > > make the list clearer. What about allowing "@(list, of, attributes)" 
> > > > instead of "@list, @of, @attributes”?
> > >
> > > That would be a little bit awkward for attributes that are parameterized. 
> > > And if we did do this we should allow the parens to be omitted when there 
> > > is only one attribute.
> > > >
> > > > - Dave Sweeris ___
> > > > swift-evolution mailing list
> > > > swift-evolution@swift.org (mailto:swift-evolution@swift.org)
> > > > https://lists.swift.org/mailman/listinfo/swift-evolution
> > >
> > > ___
> > > swift-evolution mailing list
> > > swift-evolution@swift.org (mailto: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] Support for pure functions. Part n + 1.

[Matthew Johnson via swift-evolution]

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 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 
> , 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 
>>> > 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 label(…) ~> ReturnType
>>> Version 2 is going to upset those who use "~>" as an operator.
>>> 
>>> As the # of possible attributes grows, having an obvious grouping mechanism 
>>> for them, like version 1, might be worthwhile simply to help make the list 
>>> clearer. What about allowing "@(list, of, attributes)" instead of "@list, 
>>> @of, @attributes”?
>> 
>> That would be a little bit awkward for attributes that are parameterized.  
>> And if we did do this we should allow the parens to be omitted when there is 
>> only one attribute.
>> 
>>> 
>>> - 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] Support for pure functions. Part n + 1.

[Matthew Johnson via swift-evolution]

> 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 
>>> > wrote:
>>> 
>>> 
>>> 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 label(…) ~> ReturnType
>>> Version 2 is going to upset those who use "~>" as an operator.
>>> 
>>> As the # of possible attributes grows, having an obvious grouping mechanism 
>>> for them, like version 1, might be worthwhile simply to help make the list 
>>> clearer. What about allowing "@(list, of, attributes)" instead of "@list, 
>>> @of, @attributes”?
>> 
>> That would be a little bit awkward for attributes that are parameterized.
> 
> Are there any parameterized attributes other than "@inline(always|never)”?

I am not sure, but there has been discussion of introducing them.  For example, 
regardless of what syntax we choose for indicating a public enum is closed it 
will need to have an optional parameter indicating the first version of the 
library in which it was closed (which can be omitted if it was closed the first 
time it appeared).  One option for indicating this is to use an attribute.

> 
>> And if we did do this we should allow the parens to be omitted when there is 
>> only one attribute.
> 
> Agreed.
> 
> - Dave Sweeris 

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Florent Vilmart via swift-evolution]

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 
, 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 
> >  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 label(…) ~> ReturnType
> > >
> > >
> > >
> >
> > Version 2 is going to upset those who use "~>" as an operator.
> >
> > As the # of possible attributes grows, having an obvious grouping mechanism 
> > for them, like version 1, might be worthwhile simply to help make the list 
> > clearer. What about allowing "@(list, of, attributes)" instead of "@list, 
> > @of, @attributes”?
>
> That would be a little bit awkward for attributes that are parameterized. And 
> if we did do this we should allow the parens to be omitted when there is only 
> one attribute.
> >
> > - Dave Sweeris ___
> > swift-evolution mailing list
> > swift-evolution@swift.org (mailto: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] Support for pure functions. Part n + 1.

[David Sweeris via swift-evolution]

> 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 
>>  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 label(…) ~> ReturnType
>> Version 2 is going to upset those who use "~>" as an operator.
>> 
>> As the # of possible attributes grows, having an obvious grouping mechanism 
>> for them, like version 1, might be worthwhile simply to help make the list 
>> clearer. What about allowing "@(list, of, attributes)" instead of "@list, 
>> @of, @attributes”?
> 
> That would be a little bit awkward for attributes that are parameterized.

Are there any parameterized attributes other than "@inline(always|never)"?

> And if we did do this we should allow the parens to be omitted when there is 
> only one attribute.

Agreed.

- Dave Sweeris ___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Matthew Johnson via swift-evolution]

> 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 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
> Version 2 is going to upset those who use "~>" as an operator.
> 
> As the # of possible attributes grows, having an obvious grouping mechanism 
> for them, like version 1, might be worthwhile simply to help make the list 
> clearer. What about allowing "@(list, of, attributes)" instead of "@list, 
> @of, @attributes”?

That would be a little bit awkward for attributes that are parameterized.  And 
if we did do this we should allow the parens to be omitted when there is only 
one attribute.

> 
> - 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] Support for pure functions. Part n + 1.

[David Sweeris via swift-evolution]

> 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 label(…) ~> ReturnType
Version 2 is going to upset those who use "~>" as an operator.

As the # of possible attributes grows, having an obvious grouping mechanism for 
them, like version 1, might be worthwhile simply to help make the list clearer. 
What about allowing "@(list, of, attributes)" instead of "@list, @of, 
@attributes"?

- Dave Sweeris___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Matthew Johnson via swift-evolution]

> 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 = { … }
> 
> That is similar to the behavior we now have with IUOs. (let myView: UIView = 
> self.view inside UIViewController on iOS)
> 
> I don’t know if the tilde is heavily used in any other programming patterns 
> and might create confusion here, but from the aesthetic point of view I’d 
> prefer ~> over =>.
> 
> 

Well sure, but then you have just supplied the type annotation.  I am 
describing a specific scenario where an API can accept a function that is pure 
or a function that is impure and will have the purity of the function passed 
into it.  

In many cases such APIs are used with simple closures, often single-expression 
closures.  Our options for determining purity of the closure are:

1. Allow the compiler to infer the purity of these closures.
2. Require an annotation indicating the programmers intent of purity (hopefully 
one that doesn’t eliminate the conciseness of single-expression closures)

We also need a way for the API to indicate it’s conditional purity (something 
like rethrows).  If we don’t have this then we would be forced to write pure 
and impure overloads when we want to support both and retain the purity when 
the provided closure is pure.

> 
> 
> 
> -- 
> Adrian Zubarev
> Sent with Airmail
> 
> Am 17. Februar 2017 um 15:37:15, Matthew Johnson via swift-evolution 
> (swift-evolution@swift.org ) schrieb:
> 
>> Also, what about pure closures that have no need to state a signature 
>> because it is inferred?  This syntactic sugar is a pretty important aspect 
>> of Swift and often times some of our smallest closures will be pure.  For 
>> example Array’s map should be pure when the closure is pure and many map 
>> closures are very small.  We don’t want to have to annotate these closures 
>> with a signature.  
> 

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Charles Srstka via swift-evolution]

> 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 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 could be made by the compiler.
>> Programmers will then have to see whether they choose a) to go to "pure 
>> value-type arguments" (i.e. not containing directly nor indirectly such 
>> references) and be able to declare some of their functions as pure or b) to 
>> keep these references and not declare the corresponding functions as pure.
> 
> Wouldn't we need a way to declare value semantics? Array has such references 
> but has value semantics so should be fine, no?

Arrays can contain reference types. If you have an array of references, you can 
call a mutating function on one of them…

There’s also the other built-in value types that are backed by reference types: 
URL is backed by NSURL, Data is backed by NSData. They won’t mutate, because 
they’re set up to make sure they get immutable versions of them, but how is the 
compiler going to prove it?

Charles

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Adrian Zubarev via swift-evolution]

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 on iOS)

I don’t know if the tilde is heavily used in any other programming patterns and 
might create confusion here, but from the aesthetic point of view I’d prefer ~> 
over =>.



-- 
Adrian Zubarev
Sent with Airmail

Am 17. Februar 2017 um 15:37:15, Matthew Johnson via swift-evolution 
(swift-evolution@swift.org) schrieb:

Also, what about pure closures that have no need to state a signature because 
it is inferred?  This syntactic sugar is a pretty important aspect of Swift and 
often times some of our smallest closures will be pure.  For example Array’s 
map should be pure when the closure is pure and many map closures are very 
small.  We don’t want to have to annotate these closures with a signature.  
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Removing enumerated?

[Ole Begemann via swift-evolution]

> 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 type 'C' with an index of type 
> 'C.Indices.Iterator.Element'
> 
> ?
> (have access for Swift 3.0.2 Release only for now, so probably this already 
> fixed in dev version)

This will work once SE-0142 "Permit where clauses to constrain associated 
types" 
(https://github.com/apple/swift-evolution/blob/master/proposals/0142-associated-types-constraints.md)
 is implemented and the standard library takes advantage of this.

For the time being, you need to add an explicit constraint to the function:

func function(c: C)
where C.Indices.Iterator.Element == C.Index {
for index in c.indices {
print(c[index])
}
}

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Adrian Zubarev via swift-evolution]

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 swift-evolution 
(swift-evolution@swift.org) schrieb:

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 constexpr 
addresses is not purity, at the heart of it. Pure expressions that accept 
compile-time-known values are, by happy accident, compile-time-computable, but 
pure expressions that accept dynamic values are not. Conflating the two 
qualities of being compile-time-known and being pure within the same keyword 
and overloading it in this way is not desirable to me.
I see now. I’d say that access to global state is not vital, and  
@pure functions are more useful than  
@const functions, so I’m OK with having only  
@const functions.

To control growth of compilation time, we could have both  
@pure function annotation and  
@const variable annotation to ensure that a  
@pure expression is computed at compilation time.

I’d also want to infer  
@pure whenever possible, but is it possible with functions in different modules?

___
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] Support for pure functions. Part n + 1.

[Anton Zhilin via swift-evolution]

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 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 could potentially
> add a huge amount of complication on the backend, I could this as
> being useful (also related to my previous postings as to having a way
> of determining generic types at compile time).
>
​
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Anton Zhilin via swift-evolution]

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 constexpr addresses is not purity, at the heart of it. Pure
> expressions that accept compile-time-known values are, by happy accident,
> compile-time-computable, but pure expressions that accept dynamic values
> are not. Conflating the two qualities of being compile-time-known and being
> pure within the same keyword and overloading it in this way is not
> desirable to me.
>
I see now. I’d say that access to global state is not vital, and @pure
functions are more useful than @const functions, so I’m OK with having only
@const functions.

To control growth of compilation time, we could have both @pure function
annotation and @const variable annotation to *ensure* that a @pure
expression is computed at compilation time.

I’d also want to infer @pure whenever possible, but is it possible with
functions in different modules?
​
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Adrian Zubarev via swift-evolution]

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 would probably 
allow us to use AnyType as a shortcut to AnyType.

I’m not sure if this should be part of our proposal or not. I’d like to have 
some more feedback from the core team on this one.



-- 
Adrian Zubarev
Sent with Airmail

Am 17. Februar 2017 um 14:24:14, Anton Zhilin (antonyzhi...@gmail.com) schrieb:

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 generics 
point of view? Anyway, it can be done in a separate proposal.

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Abe Schneider via swift-evolution]

+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 could potentially
add a huge amount of complication on the backend, I could this as
being useful (also related to my previous postings as to having a way
of determining generic types at compile time).


On Fri, Feb 17, 2017 at 8:01 AM, Anton Zhilin via swift-evolution
 wrote:
> My vision of “pure” functions was the following:
>
> 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 use @constexpr or const instead of @pure
>
> We can mark a function as const to assert that it is indeed pure
> We can mark a variable as const to ensure that it’s computed at compilation
> time
>
> Compiler might compute some non-const expressions, but no guarantees given
>
> One issue is, we don’t have or suggest any facilities to make use of pure
> functions, other than some optimization, which can be performed anyway as of
> now.
>
> One use-case would be conversion of metatypes to types:
>
> const let x: Any = makeSomething()
> typealias T = type(of: x)
>
> This feature can be powerful enough to fill the niche of macros in Swift,
> without unsafety of C++ or specific syntax of Rust.
>
> 2017-02-17 14:14 GMT+03:00 Haravikk via swift-evolution
> :
>>
>> 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 sufficient. This can be used anywhere that a function is
>> declared, or a closure is accepted as a parameter, allowing us to be
>> explicit that we are trying to define a pure function, or only accept pure
>> closures.
>>
>> The big benefit of this is that it is retroactive; all existing functions
>> that are pure will be automatically detected as such, and can be passed into
>> any method accepting only pure functions. The new capability will be that
>> developers can specify that a function *must* be pure and thus produce an
>> error if it isn't.
>
>
> ___
> 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] [Proposal] [Stage–2] `return` consistency for single-expressions

[Adrian Zubarev via swift-evolution]

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

Any time you have a guard statement you no longer have a single expression. 
There is at least one expression in the guard clause itself, at least one in 
the else block, and at least one following the guard statement.  

>  
> ?  
>  
> On 17.02.2017 11:20, 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 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 process.  
>>  
>> You can read the formatted version here:  
>> https://github.com/apple/swift-evolution/pull/608  
>>  
>>  
>> |return| consistency for single-expressions  
>>  
>> * Proposal: SE-  
>> 
>>   
>> * Author: Adrian Zubarev   
>> * Status: *Awaiting review*  
>> * Review manager: TBD  
>>  
>>  
>> Introduction  
>>  
>> Any single-expression closure can omit the |return| statement. This  
>> proposal aims to make this feature more consistent in some other corners of  
>> the language.  
>>  
>> Original swift-evolution thread: * [Pitch] [Stage–2] |return| consistency  
>> for single-expressions * [Pitch] (Bofore Swift 3) Make |return| optional in  
>> computed properties for a single case  
>> 
>>   
>>  
>>  
>> Motivation  
>>  
>> Closures can omit the |return| and have an inferred return type:  
>>  
>> |let _ = { 42 } // Type: () -> Int let _ = [1,2,3].map { $0 * 5 } // T == 
>> Int |  
>>  
>> There are also value returning code blocks in the language that feel the  
>> same but are inconsistent to the mentioned feature:  
>>  
>> |// Read-write computed property: var integer: Int { get { return 2016 } set 
>>  
>> { /* do some work */ } } // Read-only computed property: var string: String  
>> { return "hello swift" } // Function: func pi() -> Double { return 3.141 }  
>> // Read-Write subscript: subscript(index: Int) -> Int { get { return index  
>> % 2 } set { /* do some work */ } } // Read-only subscript: subscript(index:  
>> Int) -> Int { return index * 2 } |  
>>  
>>  
>> Proposed solution  
>>  
>> Make |return| optional for the following top level code blocks that only  
>> contain a single expression:  
>>  
>> * /variable-declaration/  
>> * /getter-setter-block/  
>> * /getter-clause/  
>> * /function-body/  
>> * /subscript-declaration/  
>>  
>> That will allow us to rewrite the above example to:  
>>  
>> |// Read-Write computed property: var integer: Int { get { 2016 } ... } //  
>> Read-only computed property: var string: String { "hello swift" } //  
>> Function: func pi() -> Double { 3.141 } // Read-Write subscript:  
>> subscript(index: Int) -> Int { get { index % 2 } ... } // Read-only  
>> subscript: subscript(index: Int) -> Int { index * 2 } |  
>>  
>> *Possible real world example:*  
>>  
>> |// Today public struct Character { public let source: Module.Source private 
>>  
>> let _pointer: UnsafePointer public var value:  
>> Swift.Character { return self._pointer.pointee } ... } // Rewritten: public  
>> struct Character { ... public var value: Swift.Character {  
>> self._pointer.pointee } ... } |  
>>  
>>  
>> Impact on existing code  
>>  
>> None, this change will only relax some existing rules.  
>>  
>>  
>> Alternatives considered  
>>  
>> Leave this as is and live with such inconsistency.  
>>  
>>  
>>  
>> --  
>> Adrian Zubarev  
>> Sent with Airmail  
>>  
>>  
>>  
>> ___  
>> 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] Removing enumerated?

[Vladimir.S via swift-evolution]

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, so probably this already 
fixed in dev version)


On 01.02.2017 1:54, Xiaodi Wu via swift-evolution wrote:

On Tue, Jan 31, 2017 at 1:16 PM, Ben Cohen via swift-evolution
> wrote:

I think whether enumerated() is justified as a method on Sequence is
one example of a wider question which definitely needs some discussion,
which is: where should the standard library draw the line in providing
convenience functions that can easily be composed from other functions
in the std lib? Here’s another example:

SE-100


 is
a proposal to add an init to Dictionary from a sequence of key/value
pairs. It’s a commonly requested feature, and IMO much needed and
should be added as soon as we move to the appropriate phase in Swift’s
evolution.

Another commonly requested Dictionary feature is similar: add a
Dictionary.init that takes a sequence, and a closure that maps that
sequence to keys. This is useful, for example, when you have a sequence
of objects that you frequently need to index into via one property on
those objects, so you want to build a fast lookup cache using that
property.

Now, if we implement SE-100, that second request can be easily
composed. It would be something like Dictionary(sequence.lazy.map {
(key: $0.someProperty, value: $0) } )

Some people look at that line of code and think sure, that’s what I’d
do and it’s easy enough that the second helper shouldn’t be added as
it’s superfluous. Others look at it and say that it is unreadable
clever-code FP nonsense, and we should just add the helper method
because most programmers wouldn’t be able to read or write that easily.

As we expand (and maybe contract :) the standard library, this kind of
question comes up a lot, so it is worth setting out some criteria for
judging these “helper” methods. Here’s my take on such a list (warning:
objectivity and subjectivity blended together in the below).

*1. Is it truly a frequent operation?*

The operation needs to carry its weight. Even once we have ABI
stability, so the size of the std lib becomes less of a concern as it
could ship as part of the OS, we still need to keep helper method
growth under control. APIs bristling with methods like an
over-decorated Xmas tree are bad for usability. As mentioned in the
String manifesto, String+Foundation currently has over 200
methods/properties. Helpers are no good if you can’t find them to use them.

Someone mentioned that they actually don’t find themselves using
enumerated() all that often. I suspect enumerated in its current form
isn’t all that useful. In a quick (and non-scientific) review of search
results for its use on GitHub, nearly all the examples I see of it are
either 1) misuse – see more below, or 2) use of it to perform the
equivalent of in-place map where the index is used to subscript into
the array and replace it with a transformed element.


So, in general, I agree with your overarching points. But I have to push
back on this part:

Although it's clearly a misuse when one assumes `startIndex == 0` while
working with a generic Collection, it's been said on this list many times
that `0..

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

[Nicolas Fezans via swift-evolution]

+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 compile-time. This might be
problematic if the produced results are large (in size) and in that case it
might be interesting to have the possibility to delay the computation at
run-time... maybe with another keyword then?

Nicolas


On Fri, 17 Feb 2017 at 15:37, Matthew Johnson via swift-evolution <
swift-evolution@swift.org> wrote:

> On Feb 16, 2017, at 3:18 PM, T.J. Usiyan via swift-evolution <
> swift-evolution@swift.org> 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 syntactically than impure functions.  That said, I don’t
> think it will stand out very clearly when reading code and is likely to be
> confusing for new programmers who don’t understand purity or why you would
> sometimes want it and other times that it won’t be possible.
>
> Also, what about pure closures that have no need to state a signature
> because it is inferred?  This syntactic sugar is a pretty important aspect
> of Swift and often times some of our smallest closures will be pure.  For
> example Array’s map should be pure when the closure is pure and many map
> closures are very small.  We don’t want to have to annotate these closures
> with a signature.
>
> Could we allow inference of purity for closures when they are used in a
> context which accepts a pure function?  If we had an annotation similar to
> `rethrows` maybe inference could prefer purity, but fall back to an impure
> semantic for `map` (or other methods using the annotation) when the closure
> isn’t pure.  Come to think of it, using `->` vs `=>` to make the
> distinction kind of falls apart when the purity of a function is
> conditional depending on the purity of its arguments.  Have you thought
> about how to handle this?
>
> Overall, I *really* want to see pure functions in Swift and would be very
> excited to see them make it into Swift 4.  That said, I’m on the fence
> about the syntax you have proposed.
>
>
> A few people talked through many of these issues starting with this tweet.
> https://twitter.com/griotspeak/status/832247545325842432
>
> On Thu, Feb 16, 2017 at 4:13 PM, Jonathan Hull  wrote:
>
> +1 for the idea of pure functions in swift.  Seems like it would enable a
> lot of good optimizations (in some cases even just evaluating the function
> at compile time).
>
> -1 on the specific notation.  I would much rather just put the word ‘pure’
> in front of ‘func’, the same way we put ‘mutating' in front of mutating
> functions… it seems to me like these are part of the same family.
>
> I agree we should allow inout.
>
> Thanks,
> Jon
>
> On Feb 16, 2017, at 9:03 AM, T.J. Usiyan via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> # Pure Functions
>
> * Proposal: [SE-](
> https://github.com/apple/swift-evolution/blob/master/proposals/-name.md
> )
> * Author(s): [TJ Usiyan](https://github.com/griotspeak)
> * Status: **Awaiting review**
> * Review manager: TBD
>
> ## Introduction
>
> Some functions are, essentially, only meant to be transformations of their
> input and–as such–do not and should not reference any variables other than
> those passed in. These same functions are not meant to have any effects
> other than the aforementioned transformation of input. Currently, Swift
> cannot assist the developer and confirm that any given function is one of
> these 'pure' functions. To facilitate this, this proposal adds syntax to
> signal that a function is 'pure'.
>
> 'pure', in this context, means:
> 1. The function must have a return value
> 1. This function can only call other pure functions
> 1. This function cannot access/modify global or static variables.
>
> ## Motivation
>
> Consider the following example where `_computeNullability(of:)` is meant
> to create its output solely based on the provided recognizer.
>
> ```
> class Recognizer {
> var nullabilityMemo: Bool?
> var isNullable: Bool {
> func _computeNullability(of recognizer: Recognizer) -> Bool {…}
> if let back = nullabilityMemo {
> return back
> } else {
> let back =  _computeNullability(of: self)
> nullabilityMemo = back
> return back
> }
> }
> }
> ```
> if `_computeNullability(of:)` is recursive at all, there exists a real
> potential to accidentally reference `self` in its body and the mistake,
> depending on circumstance, can be terribly subtle. Converting
> `_computeNullability(of:)` to a `static` function is an option but
> obfuscates the fact that it is *only* to be called within `isNullable`.
>
>
> ## Proposed solution
>
> Given the ability to indicate that `_computeNullability(of:)` is a 'pure'
> function, the developer 

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

[Matthew Johnson via swift-evolution]

> 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 }
> …
> }

Any time you have a guard statement you no longer have a single expression.  
There is at least one expression in the guard clause itself, at least one in 
the else block, and at least one following the guard statement.

> 
> ?
> 
> On 17.02.2017 11:20, 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 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 process.
>> 
>> You can read the formatted version here:
>> https://github.com/apple/swift-evolution/pull/608
>> 
>> 
>>  |return| consistency for single-expressions
>> 
>>  * Proposal: SE-
>>
>> 
>>  * Author: Adrian Zubarev 
>>  * Status: *Awaiting review*
>>  * Review manager: TBD
>> 
>> 
>>Introduction
>> 
>> Any single-expression closure can omit the |return| statement. This
>> proposal aims to make this feature more consistent in some other corners of
>> the language.
>> 
>> Original swift-evolution thread: * [Pitch] [Stage–2] |return| consistency
>> for single-expressions * [Pitch] (Bofore Swift 3) Make |return| optional in
>> computed properties for a single case
>> 
>> 
>> 
>>Motivation
>> 
>> Closures can omit the |return| and have an inferred return type:
>> 
>> |let _ = { 42 } // Type: () -> Int let _ = [1,2,3].map { $0 * 5 } // T == 
>> Int |
>> 
>> There are also value returning code blocks in the language that feel the
>> same but are inconsistent to the mentioned feature:
>> 
>> |// Read-write computed property: var integer: Int { get { return 2016 } set
>> { /* do some work */ } } // Read-only computed property: var string: String
>> { return "hello swift" } // Function: func pi() -> Double { return 3.141 }
>> // Read-Write subscript: subscript(index: Int) -> Int { get { return index
>> % 2 } set { /* do some work */ } } // Read-only subscript: subscript(index:
>> Int) -> Int { return index * 2 } |
>> 
>> 
>>Proposed solution
>> 
>> Make |return| optional for the following top level code blocks that only
>> contain a single expression:
>> 
>>  * /variable-declaration/
>>  * /getter-setter-block/
>>  * /getter-clause/
>>  * /function-body/
>>  * /subscript-declaration/
>> 
>> That will allow us to rewrite the above example to:
>> 
>> |// Read-Write computed property: var integer: Int { get { 2016 } ... } //
>> Read-only computed property: var string: String { "hello swift" } //
>> Function: func pi() -> Double { 3.141 } // Read-Write subscript:
>> subscript(index: Int) -> Int { get { index % 2 } ... } // Read-only
>> subscript: subscript(index: Int) -> Int { index * 2 } |
>> 
>> *Possible real world example:*
>> 
>> |// Today public struct Character { public let source: Module.Source private
>> let _pointer: UnsafePointer public var value:
>> Swift.Character { return self._pointer.pointee } ... } // Rewritten: public
>> struct Character { ... public var value: Swift.Character {
>> self._pointer.pointee } ... } |
>> 
>> 
>>Impact on existing code
>> 
>> None, this change will only relax some existing rules.
>> 
>> 
>>Alternatives considered
>> 
>> Leave this as is and live with such inconsistency.
>> 
>> 
>> 
>> --
>> Adrian Zubarev
>> Sent with Airmail
>> 
>> 
>> 
>> ___
>> 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] [Proposal] [Stage–2] `return` consistency for single-expressions

[Vladimir.S via swift-evolution]

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

You can read the formatted version here:
https://github.com/apple/swift-evolution/pull/608


  |return| consistency for single-expressions

  * Proposal: SE-


  * Author: Adrian Zubarev 
  * Status: *Awaiting review*
  * Review manager: TBD


Introduction

Any single-expression closure can omit the |return| statement. This
proposal aims to make this feature more consistent in some other corners of
the language.

Original swift-evolution thread: * [Pitch] [Stage–2] |return| consistency
for single-expressions * [Pitch] (Bofore Swift 3) Make |return| optional in
computed properties for a single case



Motivation

Closures can omit the |return| and have an inferred return type:

|let _ = { 42 } // Type: () -> Int let _ = [1,2,3].map { $0 * 5 } // T == Int |

There are also value returning code blocks in the language that feel the
same but are inconsistent to the mentioned feature:

|// Read-write computed property: var integer: Int { get { return 2016 } set
{ /* do some work */ } } // Read-only computed property: var string: String
{ return "hello swift" } // Function: func pi() -> Double { return 3.141 }
// Read-Write subscript: subscript(index: Int) -> Int { get { return index
% 2 } set { /* do some work */ } } // Read-only subscript: subscript(index:
Int) -> Int { return index * 2 } |


Proposed solution

Make |return| optional for the following top level code blocks that only
contain a single expression:

  * /variable-declaration/
  * /getter-setter-block/
  * /getter-clause/
  * /function-body/
  * /subscript-declaration/

That will allow us to rewrite the above example to:

|// Read-Write computed property: var integer: Int { get { 2016 } ... } //
Read-only computed property: var string: String { "hello swift" } //
Function: func pi() -> Double { 3.141 } // Read-Write subscript:
subscript(index: Int) -> Int { get { index % 2 } ... } // Read-only
subscript: subscript(index: Int) -> Int { index * 2 } |

*Possible real world example:*

|// Today public struct Character { public let source: Module.Source private
let _pointer: UnsafePointer public var value:
Swift.Character { return self._pointer.pointee } ... } // Rewritten: public
struct Character { ... public var value: Swift.Character {
self._pointer.pointee } ... } |


Impact on existing code

None, this change will only relax some existing rules.


Alternatives considered

Leave this as is and live with such inconsistency.



--
Adrian Zubarev
Sent with Airmail



___
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] Support for pure functions. Part n + 1.

[Matthew Johnson via swift-evolution]

> 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 syntactically than impure functions.  That said, I don’t think it will 
stand out very clearly when reading code and is likely to be confusing for new 
programmers who don’t understand purity or why you would sometimes want it and 
other times that it won’t be possible.  

Also, what about pure closures that have no need to state a signature because 
it is inferred?  This syntactic sugar is a pretty important aspect of Swift and 
often times some of our smallest closures will be pure.  For example Array’s 
map should be pure when the closure is pure and many map closures are very 
small.  We don’t want to have to annotate these closures with a signature.  

Could we allow inference of purity for closures when they are used in a context 
which accepts a pure function?  If we had an annotation similar to `rethrows` 
maybe inference could prefer purity, but fall back to an impure semantic for 
`map` (or other methods using the annotation) when the closure isn’t pure.  
Come to think of it, using `->` vs `=>` to make the distinction kind of falls 
apart when the purity of a function is conditional depending on the purity of 
its arguments.  Have you thought about how to handle this?

Overall, I *really* want to see pure functions in Swift and would be very 
excited to see them make it into Swift 4.  That said, I’m on the fence about 
the syntax you have proposed.

> 
> A few people talked through many of these issues starting with this tweet. 
> https://twitter.com/griotspeak/status/832247545325842432 
> 
> 
> On Thu, Feb 16, 2017 at 4:13 PM, Jonathan Hull  > wrote:
> +1 for the idea of pure functions in swift.  Seems like it would enable a lot 
> of good optimizations (in some cases even just evaluating the function at 
> compile time).
> 
> -1 on the specific notation.  I would much rather just put the word ‘pure’ in 
> front of ‘func’, the same way we put ‘mutating' in front of mutating 
> functions… it seems to me like these are part of the same family.
> 
> I agree we should allow inout.
> 
> Thanks,
> Jon
> 
>> On Feb 16, 2017, at 9:03 AM, T.J. Usiyan via swift-evolution 
>> > wrote:
>> 
>> # Pure Functions
>> 
>> * Proposal: 
>> [SE-](https://github.com/apple/swift-evolution/blob/master/proposals/-name.md
>>  
>> )
>> * Author(s): [TJ Usiyan](https://github.com/griotspeak 
>> )
>> * Status: **Awaiting review**
>> * Review manager: TBD
>> 
>> ## Introduction
>> 
>> Some functions are, essentially, only meant to be transformations of their 
>> input and–as such–do not and should not reference any variables other than 
>> those passed in. These same functions are not meant to have any effects 
>> other than the aforementioned transformation of input. Currently, Swift 
>> cannot assist the developer and confirm that any given function is one of 
>> these 'pure' functions. To facilitate this, this proposal adds syntax to 
>> signal that a function is 'pure'.
>> 
>> 'pure', in this context, means:
>> 1. The function must have a return value
>> 1. This function can only call other pure functions
>> 1. This function cannot access/modify global or static variables.
>> 
>> ## Motivation
>> 
>> Consider the following example where `_computeNullability(of:)` is meant to 
>> create its output solely based on the provided recognizer.
>> 
>> ```
>> class Recognizer {
>>  var nullabilityMemo: Bool?
>>  var isNullable: Bool {
>>  func _computeNullability(of recognizer: Recognizer) -> Bool {…}
>>  if let back = nullabilityMemo {
>>  return back 
>>  } else {
>>  let back =  _computeNullability(of: self)
>>  nullabilityMemo = back
>>  return back
>>  }
>>  }
>> }
>> ```
>> if `_computeNullability(of:)` is recursive at all, there exists a real 
>> potential to accidentally reference `self` in its body and the mistake, 
>> depending on circumstance, can be terribly subtle. Converting 
>> `_computeNullability(of:)` to a `static` function is an option but 
>> obfuscates the fact that it is *only* to be called within `isNullable`.
>> 
>> 
>> ## Proposed solution
>> 
>> Given the ability to indicate that `_computeNullability(of:)` is a 'pure' 
>> function, the developer gains assurance from the tooling that it doesn't 
>> reference anything or cause any side effects.
>> 
>> 
>> ```
>> class Recognizer {
>>  var 

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

[Matthew Johnson via swift-evolution]

+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 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 process.
> 
> You can read the formatted version here: 
> https://github.com/apple/swift-evolution/pull/608 
> 
> return consistency for single-expressions
> 
> Proposal: SE- 
> 
> Author: Adrian Zubarev 
> Status: Awaiting review 
> Review manager: TBD
> Introduction
> 
> Any single-expression closure can omit the return statement. This proposal 
> aims to make this feature more consistent in some other corners of the 
> language.
> 
> Original swift-evolution thread: * [Pitch] [Stage–2] return consistency for 
> single-expressions  * 
> [Pitch] (Bofore Swift 3) Make return optional in computed properties for a 
> single case 
> 
> Motivation
> 
> Closures can omit the return and have an inferred return type:
> 
> let _ = { 42 } // Type: () -> Int
> 
> let _ = [1,2,3].map { $0 * 5 } // T == Int
> There are also value returning code blocks in the language that feel the same 
> but are inconsistent to the mentioned feature:
> 
> // Read-write computed property:
> var integer: Int {  
> get { return 2016 }  
> set { /* do some work */ }  
> }  
> 
> // Read-only computed property:
> var string: String { return "hello swift" }  
> 
> // Function:
> func pi() -> Double {
> return 3.141
> }
> 
> // Read-Write subscript:
> subscript(index: Int) -> Int {
> get { return index % 2 }
> set { /* do some work */ }
> }
> 
> // Read-only subscript:
> subscript(index: Int) -> Int { return index * 2 }
> Proposed solution
> 
> Make return optional for the following top level code blocks that only 
> contain a single expression:
> 
> variable-declaration
> getter-setter-block
> getter-clause
> function-body
> subscript-declaration
> That will allow us to rewrite the above example to:
> 
> // Read-Write computed property:
> var integer: Int {  
> get { 2016 }  
> ...
> }  
> 
> // Read-only computed property:
> var string: String { "hello swift" }  
> 
> // Function:
> func pi() -> Double { 3.141 }
> 
> // Read-Write subscript:
> subscript(index: Int) -> Int {
> get { index % 2 }
> ...
> }
> 
> // Read-only subscript:
> subscript(index: Int) -> Int { index * 2 }
> Possible real world example:
> 
> // Today
> public struct Character {
>  
> public let source: Module.Source
> private let _pointer: UnsafePointer
>  
> public var value: Swift.Character {
> return self._pointer.pointee
> }
> ...
> }
> 
> // Rewritten:
> public struct Character {
> ...
> public var value: Swift.Character { self._pointer.pointee }
> ...
> }
> Impact on existing code
> 
> None, this change will only relax some existing rules.
> 
> Alternatives considered
> 
> Leave this as is and live with such inconsistency.
> 
> 
> 
> 
> -- 
> Adrian Zubarev
> Sent with Airmail
> 
> ___
> 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] Support for pure functions. Part n + 1.

[T.J. Usiyan via swift-evolution]

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
expressions that accept compile-time-known values are, by happy accident,
compile-time-computable, but pure expressions that accept dynamic values
are not. Conflating the two qualities of being compile-time-known and being
pure within the same keyword and overloading it in this way is not
desirable to me.


Thank you,
TJ

On Fri, Feb 17, 2017 at 8:01 AM, Anton Zhilin via swift-evolution <
swift-evolution@swift.org> wrote:

> 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 use @constexpr or const instead of @pure
>2. We can mark a function as const to *assert* that it is indeed pure
>3. We can mark a variable as const to *ensure* that it’s computed at
>compilation time
>   - Compiler might compute some non-const expressions, but no
>   guarantees given
>
> One issue is, we don’t have or suggest any facilities to make use of pure
> functions, other than some optimization, which can be performed anyway as
> of now.
>
> One use-case would be conversion of metatypes to types:
>
> const let x: Any = makeSomething()
> typealias T = type(of: x)
>
> This feature can be powerful enough to fill the niche of macros in Swift,
> without unsafety of C++ or specific syntax of Rust.
>
> 2017-02-17 14:14 GMT+03:00 Haravikk via swift-evolution <
> swift-evolution@swift.org>:
>
> 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 sufficient. This can be used anywhere that a function
>> is declared, or a closure is accepted as a parameter, allowing us to be
>> explicit that we are trying to define a pure function, or only accept pure
>> closures.
>>
>> The big benefit of this is that it is retroactive; all existing functions
>> that are pure will be automatically detected as such, and can be passed
>> into any method accepting only pure functions. The new capability will be
>> that developers can specify that a function *must* be pure and thus produce
>> an error if it isn't.
>>
> ​
>
> ___
> 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] Support for pure functions. Part n + 1.

[David Hart via swift-evolution]

> 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 checked against 
> containing such references or objects that contains such references 
> themselves: I guess that this check could be made by the compiler.
> Programmers will then have to see whether they choose a) to go to "pure 
> value-type arguments" (i.e. not containing directly nor indirectly such 
> references) and be able to declare some of their functions as pure or b) to 
> keep these references and not declare the corresponding functions as pure.

Wouldn't we need a way to declare value semantics? Array has such references 
but has value semantics so should be fine, no?

> This seems to me to be the first and relatively easy way to solve this 
> problem. Later on I could imagine even that the compiler would be clever 
> enough to check whether the contained references are used (regardless of 
> whether it is just for a read access or also to mutate some values existing 
> outside the scope of the function itself) and if they are not used the purity 
> of the function could be validated also in that case.
> 
> 
> Nicolas
> 
> 
> 
>> On Fri, Feb 17, 2017 at 8:26 AM, Charles Srstka via swift-evolution 
>>  wrote:
>> On Feb 16, 2017, at 1:27 PM, Sean Heber via swift-evolution 
>>  wrote:
>> >
>> > Doesn’t this break down if you can pass a reference as a parameter to a 
>> > pure function? If that’s not allowed, I guess I must have missed it. Also 
>> > this seems to require the function has a return value. I suppose generally 
>> > a pure function without a return value wouldn’t make much sense - unless 
>> > you pass it a reference.
>> 
>> Not only that, but even if you pass a value type as a parameter, that value 
>> type might have reference types as ivars. So since any call to any reference 
>> type can potentially mutate it, and any call to any value type could call 
>> through to a reference type which might then be mutated, it does seem that 
>> purity is quite difficult to guarantee.
>> 
>> Charles
>> 
>> ___
>> 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] Refactor Metatypes

[Anton Zhilin via swift-evolution]

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
generics point of view? Anyway, it can be done in a separate proposal.
​
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Anton Zhilin via swift-evolution]

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 use @constexpr or const instead of @pure
   2. We can mark a function as const to *assert* that it is indeed pure
   3. We can mark a variable as const to *ensure* that it’s computed at
   compilation time
  - Compiler might compute some non-const expressions, but no
  guarantees given

One issue is, we don’t have or suggest any facilities to make use of pure
functions, other than some optimization, which can be performed anyway as
of now.

One use-case would be conversion of metatypes to types:

const let x: Any = makeSomething()
typealias T = type(of: x)

This feature can be powerful enough to fill the niche of macros in Swift,
without unsafety of C++ or specific syntax of Rust.

2017-02-17 14:14 GMT+03:00 Haravikk via swift-evolution <
swift-evolution@swift.org>:

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 sufficient. This can be used anywhere that a function
> is declared, or a closure is accepted as a parameter, allowing us to be
> explicit that we are trying to define a pure function, or only accept pure
> closures.
>
> The big benefit of this is that it is retroactive; all existing functions
> that are pure will be automatically detected as such, and can be passed
> into any method accepting only pure functions. The new capability will be
> that developers can specify that a function *must* be pure and thus produce
> an error if it isn't.
>
​
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Ole Begemann via swift-evolution]

> 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 components as *static libraries* in Swift. 

Part of the recently accepted (for Swift 4) SE-0146 "Package Manager Product 
Definitions" [1] is support for static library products in the Swift Package 
Manager.

SwiftPM is not Xcode, of course. I just thought I'd mention it.

[1]: 
https://github.com/apple/swift-evolution/blob/master/proposals/0146-package-manager-product-definitions.md

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Vladimir.S via swift-evolution]

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 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 it from the rest IMHO leads to better
though-through API that is indeed meant to be exposed; whereas exposing
internal details leads to allowing various quick hacks instead. We know
these quick hacks very well from the ObjC world by accessing private
parts of the object via duck typing or setting values via KVO.

At least this is my experience with which the less implementation details
are exposed to the outer world, the better.


I think the fundamental disagreement we’re seeing in this thread is the
meaning of “outer world”; to some, it means “users of your module”. To
others, it also means “other developers on my team who are working on other
files in the module”.

Personally I feel enforced encapsulation of implementation detail to the
latter group is less important than the former, and can be handled by
convention. Whereas other users of your module definitely benefit from
access control and being able to consume a clearly-defined interface.


I assume we are discussing access modifiers mainly for the former group, 
i.e. when we are "inside" the module (even when this module is written by 
the same one person, and especially when it is written by the group).


"handled by convention" - are we talking about something like declaring 
props and methods as __privateprop , m_privateprop etc and write comments 
to mark that they should not be used outside of some scope? Is it really 
Swifty and acceptable for the modern language? Will this help to prevent 
some mistakes with incorrect access? Is it better than simple and clean 
schema for access modifiers and compiler's help?  I don't understand this.


IMO, access modifiers is very known and handy abstraction to distinct 
levels of access and to structure code many developers knows about and use 
in other languages.
At the end, if one wants to keep all internal - no problems!, you can do 
this right now, just don't use fileprivate/private/etc.


Yes, I agree we need a simple and clean schema, not over-complicated, we 
need nice keywords, we need a required minimum of access modifiers, 
not more, and I do believe currently we don't have this minimum.


Was already suggested, trying again(I do believe this could be a 
compromised solution to suit needs of the main part of developers):

* (as currently) public/open -> outside of the module
* (as currently) internal -> inside module
* private -> inside file (instead of fileprivate)
* protected(or *other* keyword) -> inside file + subtype in the 
*same module*


What objections could be made for this?
Thank you.



Slava




On Feb 17, 2017, at 8:54 AM, Xiaodi Wu > wrote:

That blog post starts out right away to say that it's a response to
community feedback. Moreover, the scenario you describe was just as
possible in 2014 as it is now. Finally, then as now, it's unclear why
you consider documentation to be "not pretty." After all, your reader
would need to consult the documentation before using a variable anyway.
On Fri, Feb 17, 2017 at 01:04 Charlie Monroe via swift-evolution
> wrote:

I'm aware of this, but that's fairly a long time ago - before Swift
was open source and had community feedback and before Swift was used
widely among developers.

To me, real-world use of the language has shown some flaws of
missing a protected access control, mainly having to decide between
having a variable internal or cramming all of the class extension
into one file, making it a 3KLOC mess. Either solution is not pretty
- now I have it split among several files with an internal variable
commented as "Do not use, for private use of this class only."


On Feb 17, 2017, at 7:47 AM, Jose Cheyo Jimenez
> wrote:

https://developer.apple.com/swift/blog/?id=11



On Feb 16, 2017, at 10:05 PM, Charlie Monroe via swift-evolution
> wrote:


How about removing fileprivate, getting Swift 2 meaning of private
(as most people here now suggest) and add additional @protected
annotation for those who want a more fine-grained solution:

@protected private - members accessable only from the
class/struct/enum/... and their extensions within the file

@protected internal - again, but you can access it even from
extensions and subclasses outside of the file 

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

[Haravikk via swift-evolution]

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 sufficient. This can be used anywhere that a function is declared, or 
a closure is accepted as a parameter, allowing us to be explicit that we are 
trying to define a pure function, or only accept pure closures.

The big benefit of this is that it is retroactive; all existing functions that 
are pure will be automatically detected as such, and can be passed into any 
method accepting only pure functions. The new capability will be that 
developers can specify that a function *must* be pure and thus produce an error 
if it isn't.

> On 16 Feb 2017, at 17:03, T.J. Usiyan via swift-evolution 
>  wrote:
> 
> # Pure Functions
> 
> * Proposal: 
> [SE-](https://github.com/apple/swift-evolution/blob/master/proposals/-name.md
>  
> )
> * Author(s): [TJ Usiyan](https://github.com/griotspeak 
> )
> * Status: **Awaiting review**
> * Review manager: TBD
> 
> ## Introduction
> 
> Some functions are, essentially, only meant to be transformations of their 
> input and–as such–do not and should not reference any variables other than 
> those passed in. These same functions are not meant to have any effects other 
> than the aforementioned transformation of input. Currently, Swift cannot 
> assist the developer and confirm that any given function is one of these 
> 'pure' functions. To facilitate this, this proposal adds syntax to signal 
> that a function is 'pure'.
> 
> 'pure', in this context, means:
> 1. The function must have a return value
> 1. This function can only call other pure functions
> 1. This function cannot access/modify global or static variables.
> 
> ## Motivation
> 
> Consider the following example where `_computeNullability(of:)` is meant to 
> create its output solely based on the provided recognizer.
> 
> ```
> class Recognizer {
>   var nullabilityMemo: Bool?
>   var isNullable: Bool {
>   func _computeNullability(of recognizer: Recognizer) -> Bool {…}
>   if let back = nullabilityMemo {
>   return back 
>   } else {
>   let back =  _computeNullability(of: self)
>   nullabilityMemo = back
>   return back
>   }
>   }
> }
> ```
> if `_computeNullability(of:)` is recursive at all, there exists a real 
> potential to accidentally reference `self` in its body and the mistake, 
> depending on circumstance, can be terribly subtle. Converting 
> `_computeNullability(of:)` to a `static` function is an option but obfuscates 
> the fact that it is *only* to be called within `isNullable`.
> 
> 
> ## Proposed solution
> 
> Given the ability to indicate that `_computeNullability(of:)` is a 'pure' 
> function, the developer gains assurance from the tooling that it doesn't 
> reference anything or cause any side effects.
> 
> 
> ```
> class Recognizer {
>   var nullabilityMemo: Bool?
>   var isNullable: Bool {
>   pfunc _computeNullability(of recognizer: Recognizer) -> Bool {…}
>   if let back = nullabilityMemo {
>   return back 
>   } else {
>   let back =  _computeNullability(of: self)
>   nullabilityMemo = back
>   return back
>   }
>   }
> }
> ```
> 
> ## Detailed design
> 
> This proposal introduces a new annotation `=>`, which is to be accepted 
> everywhere `->` currently is. Members created using this kewyord must follow 
> the rules listed in the introduction.
> 
> ## Impact on existing code
> 
> This is an additive feature unless alternative 2 is chosen and, as such, 
> should not require an effect on existing code. It could be used to annotate 
> closures accepted by methods in the standard library such as `map`, `filter`, 
> and `reduce`. While this would fit well with their typical use, such a change 
> is not necessarily part of this proposal.
> 
> ## Alternatives considered
> 
> It should be noted that neither of these alternatives can remain consistent 
> for inline closures.
> 1. keyword `pfunc` (pronounciation: pifəŋk) for 'pure' functions. 
> 2. `proc` keyword for 'impure' functions and 'func' for 'pure' functions. 
> This would be a massively source breaking change and, as such, is unlikely to 
> have any feasibility. It is, however, the most clean semantically, in my 
> opinion.
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Haravikk via swift-evolution]

> 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 arrays if adding protocols to one breaks that. 

Short answer; no.

A protocol can't add stored properties, which are what determine the 
size/stride of a type; all they can add are computed properties and methods, 
neither of which are actually stored alongside the objects themselves.

Basically a type's size is memory required to store only the parts that are 
unique to that specific object (stored properties), all a protocol does is tell 
the compiler some operations you can perform, the actual code for which is 
stored elsewhere.

As Karl points out though the type's size isn't necessarily the full picture, 
as a store property can be a pointer to some other piece of memory such as an 
object (class, rather than struct) or to an unmanaged buffer and other 
constructs that are particularly useful for things like arrays.

Also, for future reference, questions like this are more appropriate to the 
swift-users mailing list; swift-evolution is intended more for language 
improvements, rather than general queries. Easy enough mistake to make though!
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Dictionary Enhancements

[Haravikk via swift-evolution]

> 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 restructuring of the collection protocols. It 
could for example make sense as an ExtendableCollection protocol, which could 
also take a general purpose add/insert method (in the case of Dictionary this 
would take a Key/Value pair), which I believe is something that's also lacking 
from Dictionary?

Basically it's a protocol representing a Collection whose contents can grow, 
but which places no guarantees over ordering. So unlike append() you're not 
guaranteed to have the new element under .last. It makes sense to group with 
capacity since you don't need capacity in something that can't expand in some 
way.___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[James Froggatt via swift-evolution]

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.

[James Froggatt via swift-evolution]

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

[Adrian Zubarev via swift-evolution]

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.

[Raphael Sebbe via swift-evolution]

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 complex,
making use of 10's of internal libraries and/or open source ones. We've
done that for years now, creating reusable components that are built in
Obj-C as static libraries. Static libraries are great for apps: no runtime
cost, stripped to what's really needed (smaller binary). Using tons of
dylibs/frameworks does not make much sense when it comes to building apps
(see below for when they actually make sense).

Swift in its current state (v3) does not support making static libs from
Xcode. This is a major problem for large apps that need to be built on
reusable components.

There are dirty tricks that we use right now (like creating static libs
from object files through specific Xcode phase, or directly importing
source in the app target). Dylibs don't scale. Even more so with Swift. We
see so many tiny bits of code implementing one collection type or specific
algorithms. This is fine, makes a lot of sense, but dylibs don't scale for
that (app launch time). We can't have one dylib per sorting algorithm for
instance.

The case where dylib / frameworks make sense still exist through: system
libraries, or internal app libraries that enables the same feature in both
the app itself and its extensions (in iOS sense). Even in that case, the
best way to handle this situation is that those "large, feature" framework
are themselve built on 10's of smaller static libraries.

Not using dylibs but instead directly importing source in the app target
has its own share of problems. Like the absence of namespace that creates
conflicts because so many developers want to use elegant small names that
Swift rightfully encourages.

Note that ABI stability is orthogonal to this discussion, as the libs
(static, dylibs) I'm mentioning above are built all together with the same
compiler as components of the final product. The way apps are typically
built. ABI stability still makes sense for system libraries / distributed
libraries, but this is another topic.

To summarise, I'd really like to see some official support for building
static libs directly in Xcode / Swift 4 toolchain, as it's really a
limitation currently to build complex apps even though Swift appears to be
a great language to tackle that.

Raphael
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Rien via swift-evolution]

> 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 complications that 
> only serve to clutter the language.
> 
> It would make a lot more sense to just have internal and public only. No 
> private, no fileprivate, no lineprivate, no protected. It’s all silly.
> 
> Slava

+1

Not because it is silly, and there are uses, but simplification is imo way more 
powerful than questionable features.

Regards,
Rien

Site: http://balancingrock.nl
Blog: http://swiftrien.blogspot.com
Github: http://github.com/Balancingrock
Project: http://swiftfire.nl
> 
>> On Feb 15, 2017, at 7:40 AM, T.J. Usiyan via swift-evolution 
>>  wrote:
>> 
>> "Either keep it or drop it, but don't keep fiddling with it." sums up my 
>> position well.
>> 
>> On Wed, Feb 15, 2017 at 7:00 AM, Brent Royal-Gordon via swift-evolution 
>>  wrote:
>> > On Feb 14, 2017, at 9:31 PM, Chris Lattner via swift-evolution 
>> >  wrote:
>> >
>> > Keeping with the spirit of Swift and staying consistent with its design, I 
>> > see two plausible meanings for private:
>> >
>> > Private could mean either:
>> > 1) private to the file (Swift 2 semantics)
>> > 2) accessible only to the current type/scope and to extensions to that 
>> > type that are in the current file.
>> >
>> > I don’t think we’ve ever evaluated and debated approach #2 systematically.
>> 
>> For what it's worth:
>> 
>> I was opposed to SE-0025, but since I lost, I have tried to use `private` 
>> wherever it made sense, rather than fighting with the language.
>> 
>> Sometimes, the change of keyword makes no difference. Other times, it's a 
>> hassle, because I have to switch between `private` and `fileprivate` as I 
>> redesign things, with little perceived benefit. I'd say the split between 
>> these is about 50/50.
>> 
>> On a few occasions, I *have* genuinely appreciated the SE-0025 version of 
>> `private`. These involved cases where I wanted to ensure that instance 
>> variables were only manipulated in certain ways, using interfaces I had 
>> specifically designed to handle them correctly. For instance, I might have 
>> two parallel arrays, and I wanted to make sure that I only added or removed 
>> elements from both arrays at once. I could do this with `fileprivate` by 
>> splitting the type into two files, but it was more convenient to do it in 
>> one.
>> 
>> In these cases, switching to #2 would *completely* defeat the purpose of 
>> using `private`, because the extensions would be able to directly manipulate 
>> the private instance variables. I would no longer gain any benefit at all 
>> from `private`. All of my uses would either fall into "makes no difference" 
>> or "it's a hassle".
>> 
>> I do not support the idea of changing `private` to mean #2. Doing so would 
>> eliminate the few decent use cases I've found for `private`. Either keep it 
>> or drop it, but don't keep fiddling with 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
> 
> ___
> 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] final + lazy + fileprivate modifiers

[Charlie Monroe via swift-evolution]

> 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 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 it from the rest IMHO leads to better 
>> though-through API that is indeed meant to be exposed; whereas exposing 
>> internal details leads to allowing various quick hacks instead. We know 
>> these quick hacks very well from the ObjC world by accessing private parts 
>> of the object via duck typing or setting values via KVO.
>> 
>> At least this is my experience with which the less implementation details 
>> are exposed to the outer world, the better.
> 
> I think the fundamental disagreement we’re seeing in this thread is the 
> meaning of “outer world”; to some, it means “users of your module”. To 
> others, it also means “other developers on my team who are working on other 
> files in the module”.

I've come across projects where multiple developers contributed to the project 
over the time, some leaving the company, some coming, thus inheriting the 
project. Those that came to the project at later stages (with the project being 
larger) often tried to use the path of least resistance when fixing 
issues/adding new features, which often resulted in hack-ish code that accessed 
members that were meant to be private to the class but weren't since the 
members were used by subclasses/extensions in other files, etc. (things 
solvable by extensions).

If these members were protected, the developer wouldn't be able to access them 
and it would encourage a discussion on why the member is protected and if there 
is a "cleaner" way to do this. That's why I'm saying that the correct access 
control encourages cleaner code and better public APIs. Even when "public" 
means "internal" (as in within one module).

I totally agree that it's a lot depending on the team and the people, but you 
can't always control everyone all the time and that's where the language should 
help and guide.

> 
> Personally I feel enforced encapsulation of implementation detail to the 
> latter group is less important than the former, and can be handled by 
> convention. Whereas other users of your module definitely benefit from access 
> control and being able to consume a clearly-defined interface.
> 
> Slava
> 
>> 
>>> On Feb 17, 2017, at 8:54 AM, Xiaodi Wu >> > wrote:
>>> 
>>> That blog post starts out right away to say that it's a response to 
>>> community feedback. Moreover, the scenario you describe was just as 
>>> possible in 2014 as it is now. Finally, then as now, it's unclear why you 
>>> consider documentation to be "not pretty." After all, your reader would 
>>> need to consult the documentation before using a variable anyway.
>>> On Fri, Feb 17, 2017 at 01:04 Charlie Monroe via swift-evolution 
>>> > wrote:
>>> I'm aware of this, but that's fairly a long time ago - before Swift was 
>>> open source and had community feedback and before Swift was used widely 
>>> among developers.
>>> 
>>> To me, real-world use of the language has shown some flaws of missing a 
>>> protected access control, mainly having to decide between having a variable 
>>> internal or cramming all of the class extension into one file, making it a 
>>> 3KLOC mess. Either solution is not pretty - now I have it split among 
>>> several files with an internal variable commented as "Do not use, for 
>>> private use of this class only."
>>> 
 On Feb 17, 2017, at 7:47 AM, Jose Cheyo Jimenez > wrote:
 
 https://developer.apple.com/swift/blog/?id=11 
 
 
 
 
 On Feb 16, 2017, at 10:05 PM, Charlie Monroe via swift-evolution 
 > wrote:
 
> How about removing fileprivate, getting Swift 2 meaning of private (as 
> most people here now suggest) and add additional @protected annotation 
> for those who want a more fine-grained solution:
> 
> @protected private - members accessable only from the 
> class/struct/enum/... and their extensions within the file
> 
> @protected internal - again, but you can access it even from extensions 
> and subclasses outside of the file within the entire module.
> 
> @protected public/open - the same as above, but outside the modules.
> 
> To me, this way most people here will be happy:
> 
> - those wishing the access control gets 

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

[Slava Pestov via swift-evolution]

> 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 fact that I'm 
> unnecessarily exposing an internal implementation detail to the rest of the 
> module. Being able to hide it from the rest IMHO leads to better 
> though-through API that is indeed meant to be exposed; whereas exposing 
> internal details leads to allowing various quick hacks instead. We know these 
> quick hacks very well from the ObjC world by accessing private parts of the 
> object via duck typing or setting values via KVO.
> 
> At least this is my experience with which the less implementation details are 
> exposed to the outer world, the better.

I think the fundamental disagreement we’re seeing in this thread is the meaning 
of “outer world”; to some, it means “users of your module”. To others, it also 
means “other developers on my team who are working on other files in the 
module”.

Personally I feel enforced encapsulation of implementation detail to the latter 
group is less important than the former, and can be handled by convention. 
Whereas other users of your module definitely benefit from access control and 
being able to consume a clearly-defined interface.

Slava

> 
>> On Feb 17, 2017, at 8:54 AM, Xiaodi Wu > > wrote:
>> 
>> That blog post starts out right away to say that it's a response to 
>> community feedback. Moreover, the scenario you describe was just as possible 
>> in 2014 as it is now. Finally, then as now, it's unclear why you consider 
>> documentation to be "not pretty." After all, your reader would need to 
>> consult the documentation before using a variable anyway.
>> On Fri, Feb 17, 2017 at 01:04 Charlie Monroe via swift-evolution 
>> > wrote:
>> I'm aware of this, but that's fairly a long time ago - before Swift was open 
>> source and had community feedback and before Swift was used widely among 
>> developers.
>> 
>> To me, real-world use of the language has shown some flaws of missing a 
>> protected access control, mainly having to decide between having a variable 
>> internal or cramming all of the class extension into one file, making it a 
>> 3KLOC mess. Either solution is not pretty - now I have it split among 
>> several files with an internal variable commented as "Do not use, for 
>> private use of this class only."
>> 
>>> On Feb 17, 2017, at 7:47 AM, Jose Cheyo Jimenez >> > wrote:
>>> 
>>> https://developer.apple.com/swift/blog/?id=11 
>>> 
>>> 
>>> 
>>> 
>>> On Feb 16, 2017, at 10:05 PM, Charlie Monroe via swift-evolution 
>>> > wrote:
>>> 
 How about removing fileprivate, getting Swift 2 meaning of private (as 
 most people here now suggest) and add additional @protected annotation for 
 those who want a more fine-grained solution:
 
 @protected private - members accessable only from the 
 class/struct/enum/... and their extensions within the file
 
 @protected internal - again, but you can access it even from extensions 
 and subclasses outside of the file within the entire module.
 
 @protected public/open - the same as above, but outside the modules.
 
 To me, this way most people here will be happy:
 
 - those wishing the access control gets simplified - it in fact does, you 
 don't need to use @protected, if you don't want to/need to.
 - those who need a fine-grained solution, here it is.
 
 
 
> On Feb 17, 2017, at 3:49 AM, Matthew Johnson via swift-evolution 
> > wrote:
> 
> 
> 
> Sent from my iPad
> 
>> On Feb 16, 2017, at 8:36 PM, David Sweeris via swift-evolution 
>> > wrote:
>> 
>> 
>>> On Feb 16, 2017, at 14: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 complications 
>>> that only serve to clutter the language.
>>> 
>>> It would make a lot more sense to just have internal and public only. 
>>> No private, no fileprivate, no lineprivate, no protected. It’s all 
>>> silly.
>> 
>> Eh, I've used `private` to keep myself honest in terms of going through 
>> some book-keeping functions instead of directly accessing 

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

[Adrian Zubarev via swift-evolution]

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

You can read the formatted version here: 
https://github.com/apple/swift-evolution/pull/608

return consistency for single-expressions

Proposal: SE-
Author: Adrian Zubarev
Status: Awaiting review
Review manager: TBD
Introduction

Any single-expression closure can omit the return statement. This proposal aims 
to make this feature more consistent in some other corners of the language.

Original swift-evolution thread: * [Pitch] [Stage–2] return consistency for 
single-expressions * [Pitch] (Bofore Swift 3) Make return optional in computed 
properties for a single case

Motivation

Closures can omit the return and have an inferred return type:

let _ = { 42 } // Type: () -> Int

let _ = [1,2,3].map { $0 * 5 } // T == Int
There are also value returning code blocks in the language that feel the same 
but are inconsistent to the mentioned feature:

// Read-write computed property:
var integer: Int {   
get { return 2016 }   
set { /* do some work */ }   
}   

// Read-only computed property:
var string: String { return "hello swift" }   

// Function:
func pi() -> Double {
return 3.141
}

// Read-Write subscript:
subscript(index: Int) -> Int {
get { return index % 2 }
set { /* do some work */ }
}

// Read-only subscript:
subscript(index: Int) -> Int { return index * 2 }
Proposed solution

Make return optional for the following top level code blocks that only contain 
a single expression:

variable-declaration
getter-setter-block
getter-clause
function-body
subscript-declaration
That will allow us to rewrite the above example to:

// Read-Write computed property:
var integer: Int {   
get { 2016 }   
...
}   

// Read-only computed property:
var string: String { "hello swift" }   

// Function:
func pi() -> Double { 3.141 }

// Read-Write subscript:
subscript(index: Int) -> Int {
get { index % 2 }
...
}

// Read-only subscript:
subscript(index: Int) -> Int { index * 2 }
Possible real world example:

// Today
public struct Character {
  
public let source: Module.Source
private let _pointer: UnsafePointer
  
public var value: Swift.Character {
return self._pointer.pointee
}
...
}

// Rewritten:
public struct Character {
...
public var value: Swift.Character { self._pointer.pointee }
...
}
Impact on existing code

None, this change will only relax some existing rules.

Alternatives considered

Leave this as is and live with such inconsistency.



-- 
Adrian Zubarev
Sent with Airmail
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Adrian Zubarev via swift-evolution]

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

You can read the formatted version here: 
https://github.com/apple/swift-evolution/pull/608

return consistency for single-expressions

Proposal: SE-
Author: Adrian Zubarev
Status: Awaiting review
Review manager: TBD
Introduction

Any single-expression closure can omit the return statement. This proposal aims 
to make this feature more consistent in some other corners of the language.

Original swift-evolution thread: * [Pitch] [Stage–2] return consistency for 
single-expressions * [Pitch] (Bofore Swift 3) Make return optional in computed 
properties for a single case

Motivation

Closures can omit the return and have an inferred return type:

let _ = { 42 } // Type: () -> Int

let _ = [1,2,3].map { $0 * 5 } // T == Int
There are also value returning code blocks in the language that feel the same 
but are inconsistent to the mentioned feature:

// Read-write computed property:
var integer: Int {  
get { return 2016 }  
set { /* do some work */ }  
}  

// Read-only computed property:
var string: String { return "hello swift" }  

// Function:
func pi() -> Double {
return 3.141
}

// Read-Write subscript:
subscript(index: Int) -> Int {
get { return index % 2 }
set { /* do some work */ }
}

// Read-only subscript:
subscript(index: Int) -> Int { return index * 2 }
Proposed solution

Make return optional for the following top level code blocks that only contain 
a single expression:

variable-declaration
getter-setter-block
getter-clause
function-body
subscript-declaration
That will allow us to rewrite the above example to:

// Read-Write computed property:
var integer: Int {  
get { 2016 }  
...
}  

// Read-only computed property:
var string: String { "hello swift" }  

// Function:
func pi() -> Double { 3.141 }

// Read-Write subscript:
subscript(index: Int) -> Int {
get { index % 2 }
...
}

// Read-only subscript:
subscript(index: Int) -> Int { index * 2 }
Possible real world example:

// Today
public struct Character {
 
public let source: Module.Source
private let _pointer: UnsafePointer
 
public var value: Swift.Character {
return self._pointer.pointee
}
...
}

// Rewritten:
public struct Character {
...
public var value: Swift.Character { self._pointer.pointee }
...
}
Impact on existing code

None, this change will only relax some existing rules.

Alternatives considered

Leave this as is and live with such inconsistency.



-- 
Adrian Zubarev
Sent with Airmail
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Charlie Monroe via swift-evolution]

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 it from the rest IMHO leads to better though-through 
API that is indeed meant to be exposed; whereas exposing internal details leads 
to allowing various quick hacks instead. We know these quick hacks very well 
from the ObjC world by accessing private parts of the object via duck typing or 
setting values via KVO.

At least this is my experience with which the less implementation details are 
exposed to the outer world, the better.

> On Feb 17, 2017, at 8:54 AM, Xiaodi Wu  wrote:
> 
> That blog post starts out right away to say that it's a response to community 
> feedback. Moreover, the scenario you describe was just as possible in 2014 as 
> it is now. Finally, then as now, it's unclear why you consider documentation 
> to be "not pretty." After all, your reader would need to consult the 
> documentation before using a variable anyway.
> On Fri, Feb 17, 2017 at 01:04 Charlie Monroe via swift-evolution 
> > wrote:
> I'm aware of this, but that's fairly a long time ago - before Swift was open 
> source and had community feedback and before Swift was used widely among 
> developers.
> 
> To me, real-world use of the language has shown some flaws of missing a 
> protected access control, mainly having to decide between having a variable 
> internal or cramming all of the class extension into one file, making it a 
> 3KLOC mess. Either solution is not pretty - now I have it split among several 
> files with an internal variable commented as "Do not use, for private use of 
> this class only."
> 
>> On Feb 17, 2017, at 7:47 AM, Jose Cheyo Jimenez > > wrote:
>> 
>> https://developer.apple.com/swift/blog/?id=11 
>> 
>> 
>> 
>> 
>> On Feb 16, 2017, at 10:05 PM, Charlie Monroe via swift-evolution 
>> > wrote:
>> 
>>> How about removing fileprivate, getting Swift 2 meaning of private (as most 
>>> people here now suggest) and add additional @protected annotation for those 
>>> who want a more fine-grained solution:
>>> 
>>> @protected private - members accessable only from the class/struct/enum/... 
>>> and their extensions within the file
>>> 
>>> @protected internal - again, but you can access it even from extensions and 
>>> subclasses outside of the file within the entire module.
>>> 
>>> @protected public/open - the same as above, but outside the modules.
>>> 
>>> To me, this way most people here will be happy:
>>> 
>>> - those wishing the access control gets simplified - it in fact does, you 
>>> don't need to use @protected, if you don't want to/need to.
>>> - those who need a fine-grained solution, here it is.
>>> 
>>> 
>>> 
 On Feb 17, 2017, at 3:49 AM, Matthew Johnson via swift-evolution 
 > wrote:
 
 
 
 Sent from my iPad
 
> On Feb 16, 2017, at 8:36 PM, David Sweeris via swift-evolution 
> > wrote:
> 
> 
>> On Feb 16, 2017, at 14: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 complications 
>> that only serve to clutter the language.
>> 
>> It would make a lot more sense to just have internal and public only. No 
>> private, no fileprivate, no lineprivate, no protected. It’s all silly.
> 
> Eh, I've used `private` to keep myself honest in terms of going through 
> some book-keeping functions instead of directly accessing a property.
 
 This is exactly the kind of thing I like it for and why I hope we might be 
 able to keep scoped access even if it gets a new name that ends up as 
 awkward as fileprivate (allowing private to revert to the Swift 2 meaning).
 
> 
> - 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] Support for pure functions. Part n + 1.

[Nicolas Fezans via swift-evolution]

> 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 could be made by the compiler.
Programmers will then have to see whether they choose a) to go to "pure
value-type arguments" (i.e. not containing directly nor indirectly such
references) and be able to declare some of their functions as pure or b) to
keep these references and not declare the corresponding functions as pure.

This seems to me to be the first and relatively easy way to solve this
problem. Later on I could imagine even that the compiler would be clever
enough to check whether the contained references are used (regardless of
whether it is just for a read access or also to mutate some values existing
outside the scope of the function itself) and if they are not used the
purity of the function could be validated also in that case.


Nicolas



On Fri, Feb 17, 2017 at 8:26 AM, Charles Srstka via swift-evolution <
swift-evolution@swift.org> wrote:

> On Feb 16, 2017, at 1:27 PM, Sean Heber via swift-evolution <
> swift-evolution@swift.org> wrote:
> >
> > Doesn’t this break down if you can pass a reference as a parameter to a
> pure function? If that’s not allowed, I guess I must have missed it. Also
> this seems to require the function has a return value. I suppose generally
> a pure function without a return value wouldn’t make much sense - unless
> you pass it a reference.
>
> Not only that, but even if you pass a value type as a parameter, that
> value type might have reference types as ivars. So since any call to any
> reference type can potentially mutate it, and any call to any value type
> could call through to a reference type which might then be mutated, it does
> seem that purity is quite difficult to guarantee.
>
> Charles
>
> ___
> 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