Re: [swift-evolution] Handling unknown cases in enums [RE: SE-0192]

[Mike Kluev via swift-evolution]

on Wed, 10 Jan 2018 07:12:27 + Antoine Cœur 
wrote:

>
> And what about, as an alternative:
>
> case (_, #unknown): …  matches any int and any unknown enum case ...
> case _:  … matches anything ...
>
> Then it clearly goes the "pattern matching" way.
>

this will be logical and consistent. or #default everywhere instead of _

case (#default, #unknown):
case #default:

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

Re: [swift-evolution] [Proposal] Random Unification

[Mike Kluev via swift-evolution]

on Thu, 11 Jan 2018 00:02:18 +0100 Jens Persson  wrote:

If there should be an API to produce a random Double without parameters
> then IMHO it should simply be a uniformly distributed Double in the unit
> range [0, 1). Very useful as a basic building block...


[0..1) sounds reasonable. even if disregard +/- zeroes, infinities, NAN's,
etc., uniform distribution between Double.min ... Double.max makes little
sense.

and it shall be relatively easy to bit cast UInt64 to Double for those who
want to test various double patterns (e.g. for testing).

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

Re: [swift-evolution] Proposal: Introduce User-defined "Dynamic Member Lookup" Types

[Mike Kluev via swift-evolution]

Correct me if I’m wrong, but to me it looks like the main objectives to this 
proposal are cleared once we make it either a DynamicObject (vs a dynamic 
protocol) or we restrict this protocol adoptions to be only possible from 
within the main body of types, so in no way it will be possible to 
retrospectively extend, say, NSObject to conform to this protocol. Cool.

About the only bit missing is autocomplete and other mentioned things like goto 
definition, indexing, etc... IMHO these are not that important... but ok, 
assuming they are... we have a precedent of image literals to effectively 
“autocomplete” UIImage(named: “string”), perhaps we can have a similarity 
machinery that can autocomplete the relevant python method names and check for 
the typos. all during compile time.

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

Re: [swift-evolution] [Proposal] Random Unification

[Mike Kluev via swift-evolution]

on Thu, 30 Nov 2017 15:08:55 -0800 Jonathan Hull  wrote:

>
> I think it is important to have Type.random as the base because there are
> many types which would conform (not just Int & Double).



what would Double.random return though? a "uniformly distributed value" in
the range minus DBL_MAX ...  plus DBL_MAX ?

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

Re: [swift-evolution] Synthesizing Equatable, Hashable, and Comparable for tuple types

[Mike Kluev via swift-evolution]

On 25 November 2017 at 23:39, Xiaodi Wu  wrote:

> On Sat, Nov 25, 2017 at 5:21 PM, Mike Kluev  wrote:
>
>> On 25 November 2017 at 23:07, Xiaodi Wu  wrote:
>>
>>> Not sure what you’re asking. Equatable is a protocol.
>>>
>>
>> that's the point. i mean, if user writes this:
>>
>> extension (Equatable, Equatable) : Equatable
>>
>> what *else* could he mean other than this:
>>
>> extension  (T, R) : Equatable
>>
>
> No, it would mean extending the concrete type `(Equatable, Equatable)`
> (which has other roadblocks to becoming possible because Equatable has Self
> requirements).
>

>
>> and if it is indeed the only reasonable meaning we can think of - i'd say
>> the first notation is nicer.
>>
>>
>>> For a protocol P, (P, P) is a concrete type with two elements each of
>>> existential type P.
>>>
>>
>> this part i do not understand. protocol is not an existential type. or is
>> it?
>>
>
> Ah. You seem to be unfamiliar with protocol existentials. Protocols
> (currently, only those without Self or associated type requirements, for
> various implementation reasons) are themselves types. For example, you can
> write:
>
> ```
> protocol P { }
> extension Int : P { }
> let x: P = 42
> ```
>

thanks, indeed i was totally unaware of this. can't even find it in the
language reference.

if i decipher this correctly, the above example with Equatable is probably
"fine" (because Equatable has self requirement) but in other cases it won't
be fine.


> In this example, x is of type `P`, not of type `Int`. Let's clarify the
> difference:
>
> ```
> extension Array where Element == P {
>   func hi() {
> print("Hello")
>   }
> }
>
> extension Array where Element : P {
>   func hi() {
> print("World!")
>   }
> }
>
> let y: [P] = [x]
> let z: [Int] = [x as Int]
>
> y.hi() // Prints "Hello"
> z.hi() // Prints "World!"
> ```
>
> Moreover, if we do not write the first `extension Array`, then `y.hi()`
> doesn't compile. This helps to illustrate that P does not conform to itself.
>


thanks for example. too subtle feature imho. i never thought protocol could
be a type on it's own, makes the whole story more complex.

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

Re: [swift-evolution] Synthesizing Equatable, Hashable, and Comparable for tuple types

[Mike Kluev via swift-evolution]

on Date: Wed, 22 Nov 2017 08:01:16 +0100 David Hart 
wrote:

>
> What confuses me is that I always thought that T? was sugar for
> Optional by design, and found that to be quite elegant.


ditto, i thought the same.


> But now you’re telling me that its just a hack to allow conformance on
> Optionals until it can be made structural. I would have thought that it
> would be cleaner to have specific concepts (optionals, tuples, etc…)
> represented in terms of more general concepts (enum, struct) so that the
> compiler had less to reason about. I’m just trying to understand :-)
>

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

Re: [swift-evolution] Synthesizing Equatable, Hashable, and Comparable for tuple types

[Mike Kluev via swift-evolution]

On 25 November 2017 at 23:07, Xiaodi Wu  wrote:

> Not sure what you’re asking. Equatable is a protocol.
>

that's the point. i mean, if user writes this:

extension (Equatable, Equatable) : Equatable

what *else* could he mean other than this:

extension  (T, R) : Equatable

and if it is indeed the only reasonable meaning we can think of - i'd say
the first notation is nicer.


> For a protocol P, (P, P) is a concrete type with two elements each of
> existential type P.
>

this part i do not understand. protocol is not an existential type. or is
it?


> For a type T : P, a tuple of type (T, T) is not a tuple of type (P, P). If
> we can extend tuples, you can write a generic algorithm that works with any
> type (T, T) where T : P, and/or you can write an algorithm that works with
> concrete type (P, P). Note that there is no overlap between these two
> because existential type P does not conform to protocol P.
>
>
Mike
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Synthesizing Equatable, Hashable, and Comparable for tuple types

[Mike Kluev via swift-evolution]

on Date: Thu, 23 Nov 2017 09:56:35 +1100 Howard Lovatt <
howard.lov...@gmail.com> wrote:

>
> I would defend turning tuples into structs (change from structural type to
> nominal type). This is a much better story for programmers, compare the two
> stories:
>
>1. Tuples are just syntax sugar for simple structs.
>2. Tuples are sort of like structs but there is a list of things tuples
>can do that structs can't and a list of things structs can do and tuples
>can't.
>
> I think unification can be achieved with some name mangling (Chris Lattner
> noted this previously - I am just spelling out one scheme), e.g.:
>
> // var a = (zero: 0, one: 1)
> public struct Tuple_zero_Int_one_Int { // Mangle name.
> public var zero: Int
> public var one: Int
> }
> var a = Tuple_zero_Int_one_Int(zero: 0, one: 1)
> // a.0 = -1
> a.zero = -1
>
> // var b = (0, 1)
> public struct Tuple_0_Int_1_Int { // Mangle name.
> public var _0_: Int // Unique name.
> public var _1_: Int // Unique name.
> }
> var b = Tuple_0_Int_1_Int(_0_: 0, _1_: 1)
> // a = b
> a = Tuple_zero_Int_one_Int(zero: b._0_, one: b._1_)
>
>
> Implicit in the above transformation is:
>
>1. struct and tuple have the same memory layout.
>2. `.0` access the 1st stored property of a struct, `.1` the 2nd, etc.
>

not sure about the name mangling per se, but the very idea of treating
tuples as structs is awesome and worth exploring.

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

Re: [swift-evolution] Synthesizing Equatable, Hashable, and Comparable for tuple types

[Mike Kluev via swift-evolution]

On 25 November 2017 at 22:38, Xiaodi Wu  wrote:

> On Sat, Nov 25, 2017 at 4:30 PM, Mike Kluev  wrote:
>
>>
>>> i haven't encounter this notation before so it looks strange and
>> requires some effort to decipher. if it was e.g. in this form:
>>
>> extension (Equatable...) : Equatable
>>
>> then it would be immediately obvious what it means, IMHO
>>
>
> That reads to me like you are extending a tuple of type `(Equatable...)`.
> This is not the same as extending a tuple of type `(E...) where ...E :
> Equatable`.
>

and if Equatable is not a type but a protocol then the practical difference
is what ?

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

Re: [swift-evolution] Synthesizing Equatable, Hashable, and Comparable for tuple types

[Mike Kluev via swift-evolution]

On 25 November 2017 at 16:04, Xiaodi Wu  wrote:

>
> The workaround substantially bloats the standard library, and the result
> is nothing close to the same because your type is still not Equatable. This
> means that it cannot benefit from any generic algorithms. For example, an
> array of such tuples cannot be Equatable in turn.
>
>>
>
i see. then the current workaround is not deep enough.


> speaking of ugliness, the ellipsis on the left of names is quite ugly:
>>
>>  extension<...Elements : Equatable> (Elements...) : Equatable
>>
>
> Seems perfectly fine to me.
>

i haven't encounter this notation before so it looks strange and requires
some effort to decipher. if it was e.g. in this form:

extension (Equatable...) : Equatable

then it would be immediately obvious what it means, IMHO

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

Re: [swift-evolution] Synthesizing Equatable, Hashable, and Comparable for tuple types

[Mike Kluev via swift-evolution]

On 25 November 2017 at 03:12, Xiaodi Wu <xiaodi...@gmail.com> wrote:

> On Fri, Nov 24, 2017 at 9:08 PM, Mike Kluev via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>> On 24 November 2017 at 23:47, Douglas Gregor <dgre...@apple.com> wrote:
>>
>>>
>>> e.g., making all tuples of Equatable elements Equatable
>>>
>>>
>> that's already the case.. (all tuples of equatable elements are
>> equatable). no?
>>
>
> No, tuples do not conform to any protocols. There are hardcoded
> implementations of `==` up to some arity in the stdlib to partially
> mitigate the lack of protocol conformance.
>
>
to me as a user the end result is the same...
probably we need a better convincing example of what users may want that
doesn't have a workaround now.

speaking of ugliness, the ellipsis on the left of names is quite ugly:

 extension<...Elements : Equatable> (Elements...) : Equatable

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

Re: [swift-evolution] Synthesizing Equatable, Hashable, and Comparable for tuple types

[Mike Kluev via swift-evolution]

On 24 November 2017 at 23:47, Douglas Gregor  wrote:

>
> e.g., making all tuples of Equatable elements Equatable
>
>
that's already the case.. (all tuples of equatable elements are equatable).
no?

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

Re: [swift-evolution] Synthesizing Equatable, Hashable, and Comparable for tuple types

[Mike Kluev via swift-evolution]

on Date: Tue, 21 Nov 2017 22:54:21 -0800 Douglas Gregor 
wrote:

> On Nov 21, 2017, at 10:48 PM, David Hart  wrote:
> >
> > On 22 Nov 2017, at 07:41, Douglas Gregor via swift-evolution <
> swift-evolution@swift.org > wrote:
> >
> >>
> >> I think it’s straightforward and less ugly to make structural types
> allow extensions and protocol conformances.
> >
> > Can somebody explain to me what is less ugly about that? I would have
> naturally thought that the language would be simpler as a whole if there
> only existed nominal types and all structural types were just sugar over
> them.
>
> See Thorsten’s response with, e.g.,
>
>   Function
>
> which handles “inout” by adding wrappers around the parameter types (which
> one would have to cope with in any user of Function), but still doesn’t
> handle argument labels. To handle argument labels, we would need something
> like strings as generic arguments. We’d also need to handle calling
> conventions and anything else we invent for function types.
>
>
can you outline how extensions and protocol conformances might look
for structural types? to compare the ugliness of both approaches.

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

Re: [swift-evolution] [Pitch] Improving capturing semantics of local functions

[Mike Kluev via swift-evolution]

On 21 November 2017 at 21:55, Mike Kluev  wrote:

>
> maybe this?
>
> {
> capture weak foo, loo, poo // "capture list", if present
> capture unowned bar, baz, booz   // shall be at the beginning
> capture weak delegate = self.delegate!  // before anything else
>
> foo()
> ...
> }
>
> compare to the current:
> {
> [
> weak foo, weak loo, weak poo
> unowned bar, unowned baz, unowned booz
> weak delegate = self.delegate!
> ] in
>
> foo()
> ...
> }
>
> a bit more explicit / expressive, looks like ordinary statements, and
> doesn't have that strange "in" at the end.
>
>
or even this:

{
weak capture foo, loo, poo
unowned capture bar, baz, booz
weak capture delegate = self.delegate!

// capture list if any has to be before anything else

weak var some = other
foo()
...
 }

here "capture" is a noun, playing the role of "var" / "let".

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

Re: [swift-evolution] [Pitch] Improving capturing semantics of local functions

[Mike Kluev via swift-evolution]

on Tue, 21 Nov 2017 11:06:04 +0100 Tino Heth <2...@gmx.de> wrote:

>
> > 5. func fn[foo, bar](param: T) throws -> T where T: Equatable
> captures [foo, bar] { … }
>
> I guess it can be considered good practice to start a line with the most
> important information, and move the details to the far right, so that they
> don’t distract the hasty reader.
> I’m not sure if the capture list an example for this, but for good or
> worse, it didn’t draw much attention in another position either (the first
> „[foo, bar]“ that slipped through).
>
> That variant (func fn[foo, bar](param: T)) is definitely my favorite,
> because it keeps a characteristic of closures (first the capture list, then
> the parameters), but doesn’t carry over the mingling of body and parameters
> that has to be done in closures.
>


maybe this?

{
capture weak foo, loo, poo // "capture list", if present
capture unowned bar, baz, booz   // shall be at the beginning
capture weak delegate = self.delegate!  // before anything else

foo()
...
}

compare to the current:
{
[
weak foo, weak loo, weak poo
unowned bar, unowned baz, unowned booz
weak delegate = self.delegate!
] in

foo()
...
}

a bit more explicit / expressive, looks like ordinary statements, and
doesn't have that strange "in" at the end.

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

Re: [swift-evolution] [Pitch] Improving capturing semantics of local functions

[Mike Kluev via swift-evolution]

On 14 November 2017 at 21:36, Mike Kluev  wrote:

>
> it might cover well over 90% of use cases (by my "pessimistic"
> estimate)... if someone has a quick way to scan and analyse, say, github
> swift sources we may even know that current percentage number of real life
> usage.
>

i did a quick & dirty search on github (queries below). here are some stats:

1) "weak var" - 946K hits

2) "weak self" - 168K hits

3) "weak" - 1127K hits

the summ of "weak var" + "weak self" = 1114K hits

number of "weak" - 1114K = 13K

let's assume this 13K is for weak "something" which is not "self"

number of "weak something" + "weak self" = 181K

"weak self" = 168K / 181K = 93%

"weak something" = 13K / 181K = 7%

the search queries for those interested:

https://github.com/search?utf8=✓=%22weak+var%22+filename%3A.swift=Code

https://github.com/search?utf8=✓=%22weak+self%22+filename%3A.swift=Code

https://github.com/search?utf8=✓=%22weak%22+filename%3A.swift=Code


note that you have to rerun the search multiple times until it settles
around some number.
also note, you can't easily use [ ] or other punctuation in github builtin
search.

the stat suggests that in 90%+ real-life cases [weak self] is used so the
"weak func" syntax sugar is worth to consider as an addition to this
proposal.

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

Re: [swift-evolution] [Pitch] Improving capturing semantics of local functions

[Mike Kluev via swift-evolution]

On 14 November 2017 at 21:02, David Hart  wrote:

>
>
> I’d be very hesitant to introduce this syntax:
>
>
>- it’s new syntax, so it comes with a complexity tax (it isn’t
>naturally obvious what it means for a func to be weak)
>- it’s only sugar for the capture of self
>
> it might cover well over 90% of use cases (by my "pessimistic"
estimate)... if someone has a quick way to scan and analyse, say, github
swift sources we may even know that current percentage number of real life
usage.

>
>- it doesn’t transpose well to local closures
>
>
the last one - maybe not. follow me:

let closure = { [weak self, bar] in ... }

which today can be written as:

let closure = { [weak self, bar] () -> Int in ... } // full form

or as:

let closure: () -> Int = { [weak self, bar] in ... } // full form

which allows this change:

let closure:  [weak self, bar] () -> Int = { ... } // full alt form

or in alternative form:

let closure:  weak () -> Int = { [bar] in ... } // short hand form

same can be with functions:

func fn() -> Int { [weak self, bar] in ... } // full form

weak func fn() -> Int { [bar] in ... } // short hand form

the two capture attributes will in practice be "close" to each other:

weak func fn() {
[bar] in

}

and in majority of cases there will be only weak self:

weak func fn() {

}

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

Re: [swift-evolution] [Pitch] Improving capturing semantics of local functions

[Mike Kluev via swift-evolution]

On 14 November 2017 at 19:02, Mike Kluev  wrote:

> On Mon, 13 Nov 2017 22:30:25 +0100 David Hart  wrote:
>
> > On 13 Nov 2017, at 05:52, Slava Pestov  wrote:
>> >
>> >> On Nov 12, 2017, at 8:11 PM, Brent Royal-Gordon via swift-evolution <
>> swift-evolution@swift.org> wrote:
>> >>
>> >> By analogy with the current closure syntax, the capture list ought to
>> go somewhere before the parameter list, in one of these slots:
>> >>
>> >> 1.   func fn[foo, bar](param: T) throws -> T where T: Equatable { …
>> }
>> >> 2.   func fn[foo, bar](param: T) throws -> T where T: Equatable { …
>> }
>> >> 3.   func [foo, bar] fn(param: T) throws -> T where T: Equatable {
>> … }
>> >> 4.   [foo, bar] func fn(param: T) throws -> T where T: Equatable {
>> … }
>> >>
>> >> Of these options, I actually think #4 reads best; 1 and 2 are very
>> cluttered, and 3 just seems weird. But it seems like the one that would be
>> easiest to misparse.
>> >
>> > Another option that reads nicely IMHO is
>> >
>> > func fn(param: T) throws -> T where T : Equatable [foo, bar] { … }
>> >
>> > I think #4 is ambiguous with array literals unfortunately.
>>
>
> adding to the list of options:
>
> 6. func fn(param: T) throws -> T where T: Equatable [foo, bar] { … }
>
> otherwise +1 to #1 and to the one in proposal. also see about #4 below.
>
> plus, if 90%+ of use cases in practice would be [weak self] -- (the only
> examples shown in the proposals FTM) -- i would strongly consider this
> syntax sugar in addition to a generic notation:
>
> weak func fn(param: T) throws -> T where T: Equatable { … }
>
> works with "unowned" as a bonus.
>
> if implement this sugar than some variation of #4 looks appealing to have
> these capture things close.
>
>

the closer we have it to this English sentence the better IMHO:

weak throwing function "fn", capturing "foo" and "bar" weakly, using
generic type "T" which is "Equatable", having parameter "param" of type
"T", returning type "T", with the following body { ... }

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

Re: [swift-evolution] [Pitch] Improving capturing semantics of local functions

[Mike Kluev via swift-evolution]

On Mon, 13 Nov 2017 22:30:25 +0100 David Hart  wrote:

> On 13 Nov 2017, at 05:52, Slava Pestov  wrote:
> >
> >> On Nov 12, 2017, at 8:11 PM, Brent Royal-Gordon via swift-evolution <
> swift-evolution@swift.org> wrote:
> >>
> >> By analogy with the current closure syntax, the capture list ought to
> go somewhere before the parameter list, in one of these slots:
> >>
> >> 1.   func fn[foo, bar](param: T) throws -> T where T: Equatable { … }
> >> 2.   func fn[foo, bar](param: T) throws -> T where T: Equatable { … }
> >> 3.   func [foo, bar] fn(param: T) throws -> T where T: Equatable { …
> }
> >> 4.   [foo, bar] func fn(param: T) throws -> T where T: Equatable { …
> }
> >>
> >> Of these options, I actually think #4 reads best; 1 and 2 are very
> cluttered, and 3 just seems weird. But it seems like the one that would be
> easiest to misparse.
> >
> > Another option that reads nicely IMHO is
> >
> > func fn(param: T) throws -> T where T : Equatable [foo, bar] { … }
> >
> > I think #4 is ambiguous with array literals unfortunately.
>

adding to the list of options:

6. func fn(param: T) throws -> T where T: Equatable [foo, bar] { … }

otherwise +1 to #1 and to the one in proposal. also see about #4 below.

plus, if 90%+ of use cases in practice would be [weak self] -- (the only
examples shown in the proposals FTM) -- i would strongly consider this
syntax sugar in addition to a generic notation:

weak func fn(param: T) throws -> T where T: Equatable { … }

works with "unowned" as a bonus.

if implement this sugar than some variation of #4 looks appealing to have
these capture things close.

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

Re: [swift-evolution] JSONEncoder: Key strategies

[Mike Kluev via swift-evolution]

On 11 November 2017 at 21:56, Eagle Offshore  wrote:

> I have to agree, would be better to allow one to provide a mapping
> dictionary or delegate.  Building the encodingKeys into the class itself is
> short sighted and a half measure.
>
> Different types of codings will necessarily desire different key sets and
> even different names for what are logically the same keys.  This absolutely
> should NOT be baked into the class that implements Codable but rather maybe
> a delegate that is presented each key/value and given an opportunity to
> provide a substitute key and value.
>
> Codable is a fairly useless one trick pony in its current incarnation.  It
> doesn't really solve any problem I have with respect to interacting with
> web services.
>
>

in defence of Codable, my experience so far told me:

- it is very useful

- easy to use especially when you can change those structures / keys, e.g.
when you have an influence on the service side as well, or the service side
is designed at the same time - when you start from clean state in other
words.

- even if you need to talk to an already established service - the key's
translation it's doable now (could have been easier though)

- it is very logical to hook the logic of the key translation in the
Codable subclass itself (maybe in a different form to what it is now)
rather than do it externally - the latter is a more "manual" and thus a
more error prone approach where things can be easily screwed.

- the ideal design (not current) would allow to do the translation the way
you want (e.g. via the delegate). so shall be win-win.

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

Re: [swift-evolution] continuations - "extensions on steroids" idea

[Mike Kluev via swift-evolution]

On 8 November 2017 at 15:56, Benjamin G 
wrote:

> I'm extremely curious to know the use case that made you code this way. Is
> it one of the case Adam listed before ?
>
>
to "manage complexities". once the type is relatively big (it's not a view
controller :) -> there's a need to split it into different extensions (or
even files) to keep things manageable -> hence the need to expose the
private things as internals due to the current language limitations ->
hence the fear that someone on the same module (even myself few weeks
later) one day will take advantage of "what is supposed to be private" and
get an unwanted dependency on it. plus of course a desire to save time on
trips to the main type and back when i have to change the variables, which
is quite annoying. if your type is reasonably big you may find yourself in
a situation when all you have in the main type definitions is just
variables (*), and you have several extensions each implementing a certain
feature.

(*) and those methods that relate to other language limitations, e.g.
"can't override methods of extensions yet"

among those 1.5 million hits for "how do i store variables in extensions in
swift" a significant portion would be for the "own type" use cases - so
that's not "just me".

the use case of IB outlets/variables brought by Adam can be a significant
plus for parts/continuations/partial ideas. just imagine you no longer have
to manually keep in sync the two (storyboard and outlets/variables) as
Xcode will do it itself. once we have this feature all IB classes (e.g. all
view controllers) will become parts/continuations/partials.

I don't want to sidetrack this issue, but i wonder if something like this
> https://golang.org/doc/effective_go.html#embedding wouldn't be a
> "cleaner" solution.
>
>
at the first glance it resembles... the ledger :) just from a slightly
different angle.

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

Re: [swift-evolution] Pitch: Remove default initialization of optional bindings

[Mike Kluev via swift-evolution]

on Mon, 06 Nov 2017 14:33:44 -0800 Slava Pestov  wrote:

Hi all,
>
> Right now, the following two declarations are equivalent:
>
> struct S {
>   var x: Int?
> }
>
> struct S {
>   var x: Int? = nil
> }
>
> That is, mutable bindings of sugared optional type (but not Optional!)
> always have a default value of ‘nil’. This feature increases the surface
> area of the language for no good reason, and I would like to deprecate it
> in -swift-version 5 with a short proposal. Does anyone feel strongly about
> giving it up? I suspect most Swift users don’t even know it exists.
>

value types only or classes as well?

i use the first form (and rely on it every here and there) and to me having
to set to nil explicitly will amount to more visual noise in the source.

btw, what is "the surface area of the language"?

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

Re: [swift-evolution] continuations - "extensions on steroids" idea

[Mike Kluev via swift-evolution]

On 8 November 2017 at 14:20, Mike Kluev  wrote:

> On 8 November 2017 at 10:54, Benjamin G 
> wrote:
>
>> All your use cases make perfect sense, however i see one potential issue
>> with this "pattern" :
>>
>> I've seen a LOT of iOS developers (some juniors, some not) ending up with
>> monstruous UIViewControllers, and it has happened almost since the very
>> beginning of iOS development. Because of their lack of understanding of the
>> MVC pattern, they completely under estimate either the model or the view
>> layer and put too many things in their VC.
>>
>> Now this pattern would give them the illusion that they're working in a
>> sane architecture and that they've decomposed the problem correctly, but in
>> fact were not. The fact that extension wouldn't let you add variable makes
>> it harder to conceal the problem, but with "continuations" i can see no
>> limit.
>>
>> What do you think ?
>>
>>
> good tools won't fix bad developers (c)
>
> you know that you can already sort of "store variables" in extensions,
> right? obj-c associated object is one way (1). and if we are talking about
> the use case of extending "your own types only" -- i am -- your own classes
> are under your full control, so nobody stops you from having, say, an
> "extensionVars" dictionary in your root class(es) and a handy set of
> generic api's to get/set those in a convenient manner without too much
> effort (2). is it ideal? no. performance suffers. usability suffers. non
> trivial to have weak/unowned variables with (2). not a "first class
> citizen" solution. the sheer number of hits of "how to i store variables in
> extensions in swift" (more than a million now) hints you that the language
> can step in to help, at least in the critical use case of "own types".
>
>
ftm, this is what i have now (based on method 2):

extension SomeClass /* FeatureX */ {



var someVar: Float {

get { return extensionVar() }

set { setExtensionVar(newValue) }

}



var otherVar: Bool {

get { return extensionVar() }

set { setExtensionVar(newValue) }

}



var someOptionalVar: Int? {

get { return extensionVarOpt() }

set { setExtensionVarOpt(newValue) }

}



func initFeatureX() {

// init is optional if you can trust your code doing "set" before
the first "get"

someVar = 0

otherVar = false

}

}


this is on the use side. "not too bad". not too insane syntax. not too much
code on the use side. note that i don't even have to spell the keys
explicitly, so it is the same copy-paste code for all the variables. but
then... optional vars need a different syntax. no weak/unowned support.
non-optional ones need to be "set before get". performance suffers. etc,
etc... (see the above).


this is the ideal i am dreaming of:


part FeatureX SomeClass {

var someOptionalVar: Int? {

var someVar: Float = 0

var otherVar: Bool = false

var someOptionalVar: Int?



weak var someWeakVar: X?

}

}

parts (continuations) can be an answer.

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

Re: [swift-evolution] continuations - "extensions on steroids" idea

[Mike Kluev via swift-evolution]

On 8 November 2017 at 10:54, Benjamin G 
wrote:

> All your use cases make perfect sense, however i see one potential issue
> with this "pattern" :
>
> I've seen a LOT of iOS developers (some juniors, some not) ending up with
> monstruous UIViewControllers, and it has happened almost since the very
> beginning of iOS development. Because of their lack of understanding of the
> MVC pattern, they completely under estimate either the model or the view
> layer and put too many things in their VC.
>
> Now this pattern would give them the illusion that they're working in a
> sane architecture and that they've decomposed the problem correctly, but in
> fact were not. The fact that extension wouldn't let you add variable makes
> it harder to conceal the problem, but with "continuations" i can see no
> limit.
>
> What do you think ?
>
>
good tools won't fix bad developers (c)

you know that you can already sort of "store variables" in extensions,
right? obj-c associated object is one way (1). and if we are talking about
the use case of extending "your own types only" -- i am -- your own classes
are under your full control, so nobody stops you from having, say, an
"extensionVars" dictionary in your root class(es) and a handy set of
generic api's to get/set those in a convenient manner without too much
effort (2). is it ideal? no. performance suffers. usability suffers. non
trivial to have weak/unowned variables with (2). not a "first class
citizen" solution. the sheer number of hits of "how to i store variables in
extensions in swift" (more than a million now) hints you that the language
can step in to help, at least in the critical use case of "own types".

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

Re: [swift-evolution] JSONEncoder: Key strategies

[Mike Kluev via swift-evolution]

a big fat -1. sorry.

imho, this is barking up the wrong tree and things like converting from
camel case / snake case / removal underscores/ capitalization / etc, etc
shall not be part of foundation. even if people in the labs asking for
that. third party library - probably.

more easy way to handle keys customization would be nice, last i checked it
was "all or nothing", whenever i wanted to customise a single key i had to
do them all and the source tripled in size. something simple to avoid that
would be enough, imho.

Mike

on Mon, 06 Nov 2017 12:54:38 -0800 Tony Parker 
wrote:

>
> Hi everyone,
>
> While we have no formal process at this time for proposals of changes to
> Foundation-only code, I would still like to post one that we have run
> through our internal process here for additional public comment.
>
> Link to PR with proposal content:
>
> https://github.com/apple/swift-corelibs-foundation/pull/1301
>
> Link to implementation for the overlay:
>
> https://github.com/apple/swift/pull/12779  t/pull/12779>
>
> Markdown follows.
>
> Thanks,
> - Tony
>
> # Key Strategies for JSONEncoder and JSONDecoder
>
> * Proposal: SCLF-0001
> * Author(s): Tony Parker 
>
> # Related radars or Swift bugs
>
> *  Snake case / Camel case conversions for
> JSONEncoder/Decoder
>
> # Revision history
>
> * **v1** Initial version
>
> ## Introduction
>
> While early feedback for `JSONEncoder` and `JSONDecoder` has been very
> positive, many developers have told us that they would appreciate a
> convenience for converting between `snake_case_keys` and `camelCaseKeys`
> without having to manually specify the key values for all types
>
.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Abstract methods

[Mike Kluev via swift-evolution]

On 6 November 2017 at 19:44, Tino Heth <2...@gmx.de> wrote:

> to me protocol extensions are both cool and evil. cool as you can add
> code. evil because it's more natural to add another declarations in those
> extensions rather than implementation:
>
> protocol Foo {
> func foo()
> }
>
> extension Foo {
>func bar()//*** natural assumption is that i can do this. but i
> can't
> }
>
> After a moment of reflection, I think I understand your reasoning — but
> why should you want to do this?
> Imho splitting types with extensions is already overused quite often, but
> splitting a protocol makes no sense for me at all.
>

the use case would be splitting my own big protocols into different parts
for code organizing purposes (so it's within the module boundaries).

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

Re: [swift-evolution] Abstract methods

[Mike Kluev via swift-evolution]

on Sun, 5 Nov 2017 09:27:09 + Goffredo Marocchi 
wrote:

>
> I would say that you kind of already entered a slippery slope when the
> extension to a protocol can add code / not just declare a behavioural
> contract ...


to me protocol extensions are both cool and evil. cool as you can add code.
evil because it's more natural to add another declarations in those
extensions rather than implementation:

protocol Foo {
func foo()
}

extension Foo {
   func bar()//*** natural assumption is that i can do this. but i can't
}

i'd say, abusing "extension protocol" syntax to add code looks like a
(cool) hack and my +1 would be for some other more explicit syntactic
construct for the purposes of adding code, for example:

implementation Foo {
func foo() {
...
}
}

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

Re: [swift-evolution] continuations - "extensions on steroids" idea

[Mike Kluev via swift-evolution]

On 3 November 2017 at 21:36, Adam Kemp  wrote:

>
> Your ledger idea might theoretically prevent some of those bad things from
> happening, but at the expense of making the whole thing unusable for this
> use case. That’s not a good trade off.
>

well, this particular one is not impossible with ledger:

class View: UIView {
   part Feature1// *** default
   optional part Feature2   // *** the behaviour you describing
}

or even this (if majority agrees this is a better default):

class View: UIView {
   required part Feature1// *** opt-in
   part Feature2   // *** optional, the behaviour you describing
}

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

Re: [swift-evolution] continuations - "extensions on steroids" idea

[Mike Kluev via swift-evolution]

On 3 November 2017 at 18:08, Adam Kemp  wrote:

>
> 1. You end up with a whole section of type aliases at the top of the file,
>

i'm putting those in a separate Platform.swift file


> and as you read the file it’s hard to understand what those types actually
> represent.
>

in the example above "View" - a very similar concept between macOS and
iOS/tvOS/watchOS.
in case of doubts - command click is always at the finger tips.


> Which methods are you actually allowed to use? What should code completion
> show you?
>

autocomplete shows the relevant methods on each platform correctly.

2. The type alias is only useful when the naming of the methods/properties
> is identical and the sequence of calls you have to make is identical, which
> very often isn’t the case. You end up needing conditional compilation
> anyway for cases where you only need to make a call on one platform, or
> where the method you have to call is named slightly different or takes
> different arguments.
>

if the differences are minute i'm creating my own extension methods to make
the difference non existent.

example: layer is optional on OSX and non optional on iOS. the difference
is minute and i can make this difference non existent, e.g. by:

extension UIView {

var viewLayer: CALayer? {

return layer

}

}

and a similar thing on OSX, and afterwards i have single API on both
platforms with no differences.

You end up needing conditional compilation anyway for cases where you only
> need to make a call on one platform, or where the method you have to call
> is named slightly different or takes different arguments.
>

>

i rarely have to use conditional compilation and even when have to do so i
normally hide it inside the relevant "utility" extensions, from then on i
don't see anything "conditional" within the normal app sources.


> Out of the strategies I’ve seen used for cross-platform code this one was
> the most frustrating to work with in my experience.
>

quite the contrary to me - the best possible experience with such an
approach (during many years of experience ftm)


> My argument is that there should be no ledger in the first place. IMO you
>> haven’t made the case for that requirement.
>>
> the real-world example would be:

case 1. you have a single page of paper on hands saying: "partial contract
A. continued elsewhere. Blah, blah". you look around and within a multitude
of papers on the table you managed to find another sheet of paper with
"partial contract A. continued elsewhere. Blah, blah". in order to find the
whole thing you will have to look in all papers on your table, then in the
shelve and then in the whole building (module boundaries)

case 2. you have a single page of paper on hands saying: "contract A.
continued with part B elsewhere. blah, blah". you look around and within a
multitude of papers on the table you managed to find another sheet of paper
with: "part B of contract A, blah, blah". at that point you know that you
found everything, don't need to look on the shelve or in the whole building.

case 3. you have a single page of paper on hands saying: "contract A.
continued with part B elsewhere. blah, blah". you look around the whole
building and found no "part B". at this point you know - something is lost,
and act accordingly.

i mean this:
>
> class MyView: UIView {
> optional part Drawing
> }
>
> part Drawing of MyView { //  forgot to include this into target
> override func drawRect(...) {
> .
> }
> }
>
> the app compiles but doesn't work correctly.
>
>
> That example doesn’t make any sense.
>

i don't see why (and I am not talking about cross platform code at this
point). i have instances like these implemented via extensions in a day to
day code. the split of the class into files was done merely for organising
purposes, to keep file size manageable.

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

Re: [swift-evolution] continuations - "extensions on steroids" idea

[Mike Kluev via swift-evolution]

On 3 November 2017 at 17:23, Adam Kemp  wrote:

>
>
> When you actually try to use that technique in a fuller example it becomes
> impractical. I know because some people working on the same code base tried
> that, and it was much worse.
>

please provide more details on this. i was and still using such a
technique, so want to be prepared for those pitfalls before i actually
encounter them.


> I will concede that there are other techniques for cross-platform code
> that might be considered even cleaner. This isn’t the only technique, and I
> won’t claim that it’s the best technique, but it is a very useful technique
> that I have seen used very effectively. It would be nice to be able to have
> it as an option.
>
> having said that, yes, i can see your point. my fear is that it will be
> (1) too fragile (e.g. you have "TableViewDelegate" in the ledger and just
> forgot to include the relevant file in the target - the app compiles but
> then misbehaves,
>
>
> My argument is that there should be no ledger in the first place. IMO you
> haven’t made the case for that requirement.
>

> If you forget to implement a protocol then ...
>

i mean this:

class MyView: UIView {
optional part Drawing
}

part Drawing of MyView { //  forgot to include this into target
override func drawRect(...) {
.
}
}

the app compiles but doesn't work correctly.

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

Re: [swift-evolution] Proposal: Allow operators to have parameters with default values

[Mike Kluev via swift-evolution]

on Fri, 3 Nov 2017 09:40:35 -0600 Dave DeLong  wrote:

> That’s cool, but a hygienic macro system isn’t anywhere on the Swift
roadmap.
>
> Chris has mentioned in interviews that such a system is "a big feature
that’s open-ended and requires a huge design process” which makes
off-the-table for Swift 5, and (I’m guessing) unlikely for Swift 6 too.

> Personally I’d like to be able to better debug my apps in Swift 4.1
rather than waiting another 2 or 3 years for a magical macro system to
somehow solve this.

if that's just for debugging -- consider using Thread.callStackSymbols

last i checked it has the entries in the mangled form, but probably it's
(1) good enough for debugging purposes and (2) possible to de-mangle them
somehow.

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

Re: [swift-evolution] continuations - "extensions on steroids" idea

[Mike Kluev via swift-evolution]

On 3 November 2017 at 16:42, Adam Kemp  wrote:

>
> If that’s the case then this wouldn’t solve one of the major use cases I
> listed for this: splitting up cross-platform classes into platform-specific
> files. The idea is that each target contains a different subset of the
> files. Consider a case where two platforms are similar enough to share some
> code but not all code. For instance:
>
>
i think we need a better real-world example, as in this one it's probably
easier to have "View" defined as a type alias to either UIView or NSView
depending upon a platform and similarly define currentGraphicsContext() to
be either UIGraphicsGetCurrentContext() or
NSGraphicsContext.currentContext()?.CGContext depending upon a platform and
have a single code base afterwords:

class PresentationView: View {

private func draw(inContext context: CGContext) {

// Shared CoreGraphics drawing

}



func draw(_ rect: CGRect) {

self.draw(inContext: currentGraphicsContext())

}

}


having said that, yes, i can see your point. my fear is that it will be (1)
too fragile (e.g. you have "TableViewDelegate" in the ledger and just
forgot to include the relevant file in the target - the app compiles but
then misbehaves, and (2) open for abuse.


alternative 1 - it's not too hard to put an empty:


part Feature of SomeClass {}


for the relevant platform


alternative 2 - have this in the ledger:


class Some {

part Feature1

optional part Feature2

}


as an "opt-in" to the behaviour you want.


i think this type of refinement can be done at some later stage. after all,
we do not have even (much needed IMHO) optional protocol methods without
resorting to @objc as of now...


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

Re: [swift-evolution] continuations - "extensions on steroids" idea

[Mike Kluev via swift-evolution]

On 3 November 2017 at 02:52, Noah Desch  wrote:

>
> I’m +1 on the ledger and partial classes in general. I think extensions
> serving the dual purpose of extending other module’s classes, as well as an
> organizational tool for in-module classes has resulted in some bad choices
> and makes future development harder. Having a new construct for in-module
> class organization neatly solves the problem.
>

well said


> (I still want C++’s protected scope too though, in case there was any
> doubt).
>

+1

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

Re: [swift-evolution] continuations - "extensions on steroids" idea

[Mike Kluev via swift-evolution]

On 3 November 2017 at 03:05, Adam Kemp  wrote:

>
>
> Would it be an error to have an entry in the “ledger” but not a
> corresponding implementation?
>

definitely so. and vice versa.

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

Re: [swift-evolution] Logging facade

[Mike Kluev via swift-evolution]

on Date: Wed, 01 Nov 2017 10:58:38 -0700 Max Moiseev 
wrote:

>
> I believe you are looking for the «one true way of doing logging» that is
> community accepted, but it does not have to be in the standard library to
> be that. A standalone package would do just as well. swift-server-dev
> mailing list might be a better place to discuss this idea.
>

this is only tangentially relevant to what op is asking for - i remember
having to do something like this to trace every function enter / exit into
a log:

func foo() {
enter() { defer exit() }
...
...
}

and copy-paste that mantra at the beginning of every function. the enter /
exit would do some printing of the method name (#function) among other
things.

it was a bit annoying manually doing so in every method, and one of course
can dream of some automated built-in facility to the same effect. until
that time, manual tricks like this will do.

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

Re: [swift-evolution] continuations - "extensions on steroids" idea

[Mike Kluev via swift-evolution]

to sum up. so far the feedback on this proposal was:

1) generally in favour (e.g. to have ability of adding variables and
accessing privates at all)

2) the name "continuation" is used for something else

3) why not to use partials as they are in c#

4) having explicit names for continuations is unwanted because naming is
hard

5) the ledger list is unnecessary as anyone on the same module will be able
to change it anyway - false feel of protection.

here are my thoughts on it.

1) "generally in favour (e.g. to have ability of adding variables and
accessing privates at all)"
-- great! thank you.

2) "the name "continuation" is used for something else"
-- thought the same. let it be "part" instead of continuation

3) "why not to use partials as they are in c#"
-- my belief here is that just because i made my type partial (for my own
reasons, e.g. as a result of splitting a single-file class into a
multi-file) it does not necessarily mean I want other developers of my team
(on the same module) to add continuations / parts to my class. in other
words, while there are the module boundaries (the building walls) i still
want to see some partitions between the rooms of that building to have some
privacy.

4) "having explicit names for continuations is unwanted because naming is
hard"
-- every time I am adding extension now I want to label it somehow to
indicate it's purpose. if that extensions adds a protocol conformance (e.g.
"extension ViewController: UITableViewDataSource") the problem is not as
critical as the protocol (or the list of protocols) name itself can serve
the purpose of such an indication. if there is no such a protocol
conformance however i tend to add a "MARK: ThePurpose" or a comment
("extension ViewController /* ThePurpose */) and as the comments are not
checked and get out of sync every time i do this i wish there was a a more
explicit extension label in the language for this purpose. maybe that's
just me.

5) "the ledger list is unnecessary as anyone on the same module will be
able to change it anyway - false feel of protection."
-- to this i can give the same response as in (3). here is another example
that hopefully will clarify my point: we shall not really say that
"private" in swift is useless and "internal" shall be used instead of it
just because anyone in the same module can bypass it anyway: go to your
class and change the source from "private" to "internal" for their own
benefits, so why bother with private / fileprivate to begin with. so is
true in regards to the ledger: yes, it is true that anyone on the team
working on the same module has a physical ability to go to my class (the
class who's sole maintainer and "owner" is myself) and mess around it,
changing it's ledger along the way, or making it partial as in (3) or
changing it's privates to internal, or adding variables, etc. it's just
they shouldn't, at least not talking to me first. they won't be "behaving
properly" if they do.

some additional thoughts. ledger works similar to the c++ class definition
itself, which lists all the members of the class, just on a less granular
scope: while in C++ you have to go there every time you want to add, say, a
private method, with parts you go change the ledger very infrequently, to
add a group or functionalities. another tangentially similar feature of C++
is "friends". if you class have, say, 10 different extensions each
implementing a certain feature and you converted them to "parts" the ledger
list will contain 10 entries naming those features explicitly.

Mike

ps. by now i figured that discussing protection levels in swift is akin to
having a wonderful morning walk across a mine field
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] continuations - "extensions on steroids" idea

[Mike Kluev via swift-evolution]

On 1 November 2017 at 15:31, BJ Homer  wrote:

> Again, though, “anyone” here only means “anyone working in the same
> module”. Which is a very restricted set of “anyone”: it only includes
> people who already have full access, and could just modify the original
> struct anyway.
>

by this logic we can conclude that "private" in C++ is absolutely useless,
as anyone (like "anyone in the world with the header") can change the
header from: "private: void foo();" to "public: void foo();" even without
the need of having the corresponding source file with "void foo()". right?

i'd say wrong. i'd say that even if i have a physical write access to, say,
30 third party libraries and use them in my project doesn't mean i am
"free" to go to those other people classes and change private things to
public willy nilly, or add variables to their classes, etc. my proposal, as
well as the above example with C++ private - only works if people "behave".
ledger is an explicit list of parts allowed. a guest list if you wish.
"party crashing" is not addressed in this proposal.

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

Re: [swift-evolution] continuations - "extensions on steroids" idea

[Mike Kluev via swift-evolution]

On 1 November 2017 at 15:22, Adam Kemp  wrote:

> I don’t see why “parts” would need to be named. That seems overly complex
> for little benefit.
>
>
name and ledger are essential in this proposal.

no name ->
no ledger (how to reference it?) ->
anyone can write parts of your class ->
anyone can add variables to your class ?! ->
anyone can access private members of your class ?!

makes no sense without a name and a ledger.

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

Re: [swift-evolution] continuations - "extensions on steroids" idea

[Mike Kluev via swift-evolution]

On 1 November 2017 at 13:34, Wallacy  wrote:

> Partial (like in C#) is good enough.
>

"partial" will not read correctly in this context:

class ViewController: UIViewController {
partial DataSource // ?!
...
}

partial DataSource of ViewController: UITableViewDataSource { // ?!
}

if you mean:

partial class ViewController: UITableViewDataSource {
...
}

this is not what i'm suggesting. parts/continuations must have a name and
this name must be listed in a ledger (of the main class or another part of
it) for the part to be able to exist at all.

having the "main" part (just the normal class definition) is good for:

- it is the only place to put base class in (like the above
UIViewController)

- it has the starting ledger that list parts (direct sub-parts). all parts
can be found "recursively" from that starting point.

with "parts" many pieces that are extensions today will become parts. and
"private" to "fileprivate" promotion feature will likely not be needed
anymore (we can of course leave it as is for compatibility).

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

Re: [swift-evolution] continuations - "extensions on steroids" idea

[Mike Kluev via swift-evolution]

class ViewController {
part DataSource
...
}

part DataSource of ViewController: UITableViewDataSource {

}

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

Re: [swift-evolution] classprivate protection level?

[Mike Kluev via swift-evolution]

On 31 October 2017 at 02:29, Adam Kemp  wrote:

>
> No, grep would be sufficient as well. The issue is still which files to
> grep in the first place. Everything else comes after that. If you manually
> read files looking for usages of an API you’re changing then I feel sorry
> for you. You’re doing things the hard way.
>
>
so you've used grep to search for "foo" in all files of the module (in case
of "internal func foo") and grep returned 50 files.

in case of "classprivate func foo" that would be, say, 10 files. or even 50
files - doesn't matter.

what matters is the actual number of hits of "foo" to review, in the former
case it would be, say "50 files * 10 hits in each" in the latter - "50
files with one hit in each". and in reality even "10 files with one hit in
each". thus the search set to review is much much smaller.

I’m not going to go back and forth on this any longer. We’re going in
> circles. We just don’t agree, and this doesn’t appear to be going anywhere.
>

i agree to disagree.

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

Re: [swift-evolution] continuations - "extensions on steroids" idea

[Mike Kluev via swift-evolution]

On 31 October 2017 at 06:57, Goffredo Marocchi  wrote:

> I like the IB use case :).
>
>
my favourite one would probably be continuations used for protocol adoption
- no longer the trip to the main class needed to add a variable:

continuation DataSource of MyViewController: UITableViewDataSource {

private var variable: Bool // ***

override func tableView(_ tableView: UITableView, cellForRowAt
indexPath: IndexPath) -> UITableViewCell {
...
}
}
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] classprivate protection level?

[Mike Kluev via swift-evolution]

On 31 October 2017 at 00:36, Noah Desch  wrote:

>
>
> > On Oct 30, 2017, at 6:38 PM, Adam Kemp via swift-evolution <
> swift-evolution@swift.org> wrote:
> >
> >
> >
> >> On Oct 30, 2017, at 2:23 PM, Mike Kluev  wrote:
> >>
> >> On 30 October 2017 at 19:49, Adam Kemp  wrote:
> >>
> >> How do you know there’s not an extension in this file without looking?
> If you don’t know then you have to check. That puts it in the same bucket
> as internal or public. The set of files you have to search through for
> usages is the same.
> >>
> >>
> >> I'd just search for "extension SomeClass", Xcode search result window
> will list all files that have it.
> >> or I will list all the users of "foo" if that's the one I am changing.
> >
> > When you do that search, which files do you include in the search?
> That’s the key.
>
>
> If I’m concerned with how much work I’ll have to do, no that’s not the
> key. The key is how many files do I have to read myself (only those
> containing a subclass or extension of my base class). You seem to be
> conflating a near instantaneous search in an IDE with manually evaluating a
> change’s impact to other source files in the module. “Classprivate" makes
> significantly fewer files that I have to manually review compared to
> “internal”.


exactly. significantly fewer files or fragments of files - significantly
fewer entries in the search results in other words.

when in a pub:

public / internal:
  - may i have a pint of lager please? - sure, here you are

classprivate / protected:
  - may i have a pint of ale please?
  - sure. are you a member of our club? we serve ale to members only
  - errr. no. can i become a member?
  - yes, it is free. just take a seat over there and fill this form
first, once done i will bring you your ale.
  - errr, thanks. may i have lager instead please?

private:
  - may i have a pint of potter please?
  - sure. are you a member of our club?
  - yes, i just filed the form, here it is.
   - are you aware that we serve potter only in that "core members
only" private room?
  - errr, no, how do i get there?
  - ah, no sir, it is impossible. you would know if you can go there.
it is by invitation only system.
  - damn!! lager!

i am dead sure they will serve much less ale than lager, don't you.

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

[swift-evolution] continuations - "extensions on steroids" idea

[Mike Kluev via swift-evolution]

a general feeling that there are two very different use cases of extensions
-- one to extend own classes and another to extend other people classes; a
lengthy discussion in a nearby thread; a disparity of features of class and
it's extensions and different access right treatment depending upon whether
the extension is in the same with the main class or a different file lead
me to the following idea. hopefully you will find this idea useful and we
may even see it one day in swift.

introducing class / struct / enum continuations.

in a few words the are:

1) "extensions on steroids". in fact very similar to Objective-C "class
extensions" but can be more than one and in more than one file.

2) as good as the classes they continue (or other continuations they
continue)

3) can declare variables

4) have full access to "private" members of the class or other continuations
regardless whether they are in the same or in a different files. no need
for "public/internal/module" fallbacks to pass though files boundaries.
similarly the class itself can use private members of its continuations.

5) "by invitation only" system. can only be written if declared by the
class or some continuation of it.

6) A particular continuation only defined once (of course). There can be an
arbitrary number of different continuations to a class similar to
extensions.

7) alternative name considered: "extending" (as a noun). shall definitely
be a different name than say, "extension" with some bracket-syntax
variation - the two use cases are very different and shall be named
differently.

8) the particular syntax is preliminary of course.

example:

= Some.swift ==

class Some {

private func private_method_of_class() {

// *** can use private methods of continuations even if they are in
a different file
private_method_defined_in_a_continuation()
}

// *** "by invitation" system

continuation Feature // *** declaring a continuation
continuation SomethingElse // *** Capitalized names, like classes
}

= Some-Feature.swift ==

// *** similar naming convetion to "Some+Feature.swift"
// used for extensions, just with "-" instead

// *** this is merely a naming convention, no need to
necessarily follow it, can put more than one thing into
a file, the continuation can reside in the same file as
the main class fie, etc.

continuation Feature of Some {

// *** as good as class itself. first-class citizen
// *** same syntax can be used for structs and enums

var x: Int // *** can declare variables

private func private_method_defined_in_a_continuation() {
private_method_of_class()

// *** can use private methods of the class or of other
continuations even if they are in a different file
}

// *** continuations are as good as classes and can
// *** declare other continuations if needed

continuation CanDoThis
}

= Any file ==

continuation Feature of Some { // *** error, continuation is already defined
}

continuation Other of Some { // *** error: Other is not a continuation of
Some
}

thoughts?

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

Re: [swift-evolution] classprivate protection level?

[Mike Kluev via swift-evolution]

On 30 October 2017 at 23:14, Adam Kemp  wrote:

>
> > On Oct 30, 2017, at 4:10 PM, Mike Kluev  wrote:
> >
> > "classprivate" helps to resolve this problem. if it is marked so
> developer will at least think twice before making an extension to use it
>
> Why would they think twice, though? You’ve told them extensions can use
> it, and they’ve written an extension to use it. What did they do wrong? I
> don’t think the rules are nearly as clear as for protected.
>

this is obvious: when they are writing a method in their own class and try
to call: some.foo() it will give them and access level error (or even
before that the autocomplete will not work as an early hint), they will
reveal foo's definition, see "classprivate" in there and at that very point
take a pause, think and make a conscious decision whether they really want
it or not. if they really want it they will make an extension (which would
be a legitimate use of it) if they don't need it really - they will find
another way without making an extension. the (reasonable) expectation is
that such a "classprivate" will reduce the number of instances where "foo"
is used thus reducing the "working set" of instances i have to review when
making a change to it.

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

Re: [swift-evolution] classprivate protection level?

[Mike Kluev via swift-evolution]

On 30 October 2017 at 22:38, Adam Kemp  wrote:

>
> “specialprivate", by allowing any extension to access the API, would imply
> the same set of files as either internal or public. You can’t know ahead of
> time whether some random file in your module might make an extension that
> access that API so you have to search all files within that module. You
> would perform the search exactly the same way. It doesn’t help you as a
> library maintainer. You’re not going to save work by making something
> “specialprivate” instead of internal. Worst case is you actually convince
> yourself that you don’t have to search the whole module, and then you break
> something because of that misunderstanding. That’s why internal is better.
> It avoids obfuscating the actual implications of that access level.
>

i still see a value in it:

- i do a search for, say, "foo" (all files in the module)
- let's say 50 usages will be legitimate use from within the class or it's
extensions
- another 10 usages will be wrong, that mistakenly treated it's "internal /
public" as a permission to use.
- i found those instances which shall not be there (that mistakenly use it
as it is effectively public)
- i ask developers who did it to not do this again / fix the problem / etc
- some time later i can do the same mistake myself again or other people
will do the same mistake again and the process repeats.
- compiler doesn't help as it can't check
- it becomes a manual and error prone process

"classprivate" helps to resolve this problem. if it is marked so developer
will at least think twice before making an extension to use it - similar to
how marking a method "protected" stops people from using it without
subclassing - (and creating an extension for the sole purpose of using
despite of it's access level would qualify as "cheating", which we can
leave aside). with "internal / public" there is nothing stopping them for a
second and they can use it without even realising they are doing something
wrong. all IMHO.

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

Re: [swift-evolution] classprivate protection level?

[Mike Kluev via swift-evolution]

On 30 October 2017 at 19:49, Adam Kemp  wrote:


> How do you know there’s not an extension in this file without looking? If
> you don’t know then you have to check. That puts it in the same bucket as
> internal or public. The set of files you have to search through for usages
> is the same.
>
>
I'd just search for "extension SomeClass", Xcode search result window will
list all files that have it.
or I will list all the users of "foo" if that's the one I am changing.

the good guideline from Obj-C was (and still is) using
"SomeClass+ExtensionName" file naming convention that also helps.

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

Re: [swift-evolution] classprivate protection level?

[Mike Kluev via swift-evolution]

On 30 October 2017 at 18:07, Adam Kemp  wrote:

> On Oct 30, 2017, at 10:57 AM, Mike Kluev  wrote:
>
>
> the new bucket would be "class and all of its extensions be them in the
> same file or in different files”.
>
>
> That’s not a new bucket. It is equivalent to either internal or public,
> depending on whether you want to extend this beyond the module boundary.
> The set of code you would have to audit is the same.
>

it is different, see below:

=== file: Some.swift

class Some {
   internal func foo() {
  bar()
   }
   classprivate func better() {
  good()
}
}

=== file: Some+Bar.swift

extension Some {
  internal func bar() {
  foo()
  }
  classprivate func good() {
  better()
   }
}

=== any other file (same module)

class Other {
func x() {
let some = Some()

some.foo() // ** UNWANTED!!

some.better() // error.  ** WANTED!
}
}

I do not want to audit the class Other when I make a change to "foo" or
"bar", which are essentially "private" and only made "internal" because of
the language limitation in regards to "private" vs "multi-file class" issue.


> What does marking a method as “specialprivate” (my made up name for this
> new access level) tell clients about who can use it or how it can be used?
>

it tells them: "you can't use this, unless you are writing an extension to
this class or making changes to this class itself"

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

Re: [swift-evolution] classprivate protection level?

[Mike Kluev via swift-evolution]

On 30 October 2017 at 17:22, Adam Kemp  wrote:

>
> The goal isn’t to entirely avoid having to audit any code while making a
> change. The goal is to allow you to reason about which code you would have
> to audit. A new access level should lead to a new bucket of code that needs
> to be audited, but none of the proposals here would do that. They’re all
> equivalent to existing access levels.
>

the new bucket would be "class and all of its extensions be them in the
same file or in different files".

back to your example with the locked door and the keys on the doorstep, i
can violate "protected" in C++:

developer 1:
class Base { protected void foo(); }

developer 2:
class Derived: Base { public void not_so_protected_foo() { foo() }

but that doesn't mean that "protected" in C++ shall be ditched!

this is similar to what you said before about writing an extension and
exposing the private functionality as public violating protection.

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

Re: [swift-evolution] classprivate protection level?

[Mike Kluev via swift-evolution]

sorry, hit "Sent" too early

On 30 October 2017 at 16:34, Adam Kemp  wrote:

>
> I didn’t mean “no, you can’t do that”. You can if you want to. What I
> meant was “no, I’m not suggesting that you should do that”. I don’t think
> it’s necessary.
>

as you said before the benefit of keeping private things private is
minimizing the amount of code that can break once you change a variable. if
it's "internal" - the whole module must be checked. if it is "internal"
rather than "private":

- it is done because otherwise i'd have to keep the (big) class in a single
file
- shows the limitation in the language in regards to one-file-class vs
multi-file-class
- forces me to use one module per file if I want to mimic the "private"
keyword as close as possible
- or forces me to keep my class in a single file.

> Which other language has an access level like the one being proposed?

i am not aware of such a language. C++'s "private" comes close as it can be
used in multiple files but then C++ doesn't have extensions. C++
"protected" comes close for something I can use in subclasses.

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

Re: [swift-evolution] classprivate protection level?

[Mike Kluev via swift-evolution]

On 30 October 2017 at 16:34, Adam Kemp  wrote:

>
> I didn’t mean “no, you can’t do that”. You can if you want to. What I
> meant was “no, I’m not suggesting that you should do that”. I don’t think
> it’s necessary.
>

as you said before the benefit of keeping private things private is
minimizing the amount of code that can break once you change a variable. if
it's "internal" - the whole module must be checked. if it is "internal"
rather than "private":
it is done because otherwise i'd have to keep the (big) class in a single
file



> Which other language has an access level like the one being proposed?
>
>
> this:
>
> SingleFileClass1.swift // with bunch of "privates" inside
>
> SingleFileClass2.swift // with bunch of "privates" inside
>
> SingleFileClass3.swift // with bunch of "privates" inside
>
> is equivalent to this:
>
> Module solely for Class1
>Class1.swift // with bunch of "internals inside
>Class1+Extension.swift // with bunch of "internals" inside
>
> Module solely for Class2
>Class2.swift // with bunch of "internals" inside
>Class2+Extension.swift // with bunch of "internals" inside
>
> Module solely for Class3
>Class3.swift  // with bunch of "internals" inside
>Class3+Extension.swift // with bunch of "internals" inside
>
>
> still "no" ?
>
> i mean, it's fine (although a bit odd) that a mere change from a
> single-file to a multi-file class leads to such drastic consequences.
> different to what i saw before. but I can adapt of course.
>
> Either way the answer is basically the same: don’t obfuscate the effective
>> access level and pretend you’re being strict when you’re really not. It’s
>> like putting a lock on the door with the key hanging from the doorknob. You
>> may as well just keep it unlocked.
>>
>>
> nice analogy :-)
>
> Mike
>
>
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] classprivate protection level?

[Mike Kluev via swift-evolution]

On 30 October 2017 at 07:30, Adam Kemp  wrote:

>
> No. There are two reasonable options:
>
> 1. Make it public. If it’s needed outside the module then this is an
> accurate description of its access level.
>
> 2. Make it internal and accept that any code in the same module can access
> it. Again, that is effectively what your proposed scope allows anyway so
> internal is an accurate description of its actual access level. Call it
> what it is.
>
>
Adam, i fail to see why you say "No" to "one module per class approach" if
the goal is to make the individual multi-file classes as isolated as
possible (i.e. not see each other "internal" stuff). which (this goal) is
considered the "way to go" approach in other languages and the "default"
behaviour.

this:

SingleFileClass1.swift // with bunch of "privates" inside

SingleFileClass2.swift // with bunch of "privates" inside

SingleFileClass3.swift // with bunch of "privates" inside

is equivalent to this:

Module solely for Class1
   Class1.swift // with bunch of "internals inside
   Class1+Extension.swift // with bunch of "internals" inside

Module solely for Class2
   Class2.swift // with bunch of "internals" inside
   Class2+Extension.swift // with bunch of "internals" inside

Module solely for Class3
   Class3.swift  // with bunch of "internals" inside
   Class3+Extension.swift // with bunch of "internals" inside


still "no" ?

i mean, it's fine (although a bit odd) that a mere change from a
single-file to a multi-file class leads to such drastic consequences.
different to what i saw before. but I can adapt of course.

Either way the answer is basically the same: don’t obfuscate the effective
> access level and pretend you’re being strict when you’re really not. It’s
> like putting a lock on the door with the key hanging from the doorknob. You
> may as well just keep it unlocked.
>
>
nice analogy :-)

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

Re: [swift-evolution] classprivate protection level?

[Mike Kluev via swift-evolution]

Module1

Class A in it's own file
extension A in it's own file

Class B in it's own file
extension B in it's own file

Class C in it's own file
extension C in it's own file

Module 2


obviously i do not want guys from team B and C accessing anything "team A
private".

is my understanding of your words then correct that you suggest to have
this:

Module1

Class A in it's own file
extension A in it's own file

Module2

Class B in it's own file
extension B in it's own file

Module3

Class C in it's own file
extension C in it's own file

Module 4




On 30 October 2017 at 04:04, Adam Kemp  wrote:

> Access levels exist for encapsulation. They don’t mean anything unless
> they actually allow you to reason about which code can break if you make a
> change. Given that, here is how each existing access level is useful:
>
> Public means a change could break any code.
>
> Internal means only code in the module can break so you can audit all
> usages in that module and fix as needed.
>
> File private means only code within the file can break so you only
> have to audit the one file.
>
> Private means only code within the class or extensions in the same
> file can break so you only have to audit part of that one file.
>
> What would a proposed new access level mean for which code has to be
> audited when making a change?
>
> If any extension can access something even across modules then that
> makes it the same as public. You can’t make any change without risking
> breaking a client.
>
> If any extension can access something within the same module then it’s
> the same as internal. You have to audit the whole module.
>
> If your new access level doesn’t make a new bucket for what code to audit
> then it’s not adding any value.
>
> On Oct 29, 2017, at 8:40 PM, Mike Kluev  wrote:
>
> On 30 October 2017 at 02:54, Adam Kemp  wrote:
>
>>
>> That was my original point. This is what internal does. We don’t need any
>> new access levels for extensions. Internal solves these use cases. Code in
>> the same module can be maintained in lockstep so you can make things
>> internal as needed for extensions. Anything beyond that is effectively
>> indistinguishable from public so just call it that.
>>
>>
> if I have N big classes,  each split across M files to keep size
> manageable, do I need to have N different modules if i want to achieve a
> good separation between classes? (same level of protection that private
> gives for a class that fits in a single file) i.e. one module per one class?
>
> Mike
>
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] classprivate protection level?

[Mike Kluev via swift-evolution]

On 30 October 2017 at 02:54, Adam Kemp  wrote:

>
> That was my original point. This is what internal does. We don’t need any
> new access levels for extensions. Internal solves these use cases. Code in
> the same module can be maintained in lockstep so you can make things
> internal as needed for extensions. Anything beyond that is effectively
> indistinguishable from public so just call it that.
>
>
if I have N big classes,  each split across M files to keep size
manageable, do I need to have N different modules if i want to achieve a
good separation between classes? (same level of protection that private
gives for a class that fits in a single file) i.e. one module per one class?

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

Re: [swift-evolution] classprivate protection level?

[Mike Kluev via swift-evolution]

On 29 October 2017 at 16:04, Adam Kemp  wrote:

> Internal is the right choice here. If it gives too much access then you
> might consider pulling this code into a separate module.
>
> If “private” gave access to every extension then any code outside your
> module could make a new extension and access that method. That would make
> it effectively public in that you wouldn’t have any ability to limit who
> can call it.
>
>
there are two very different use cases for which we use extensions.

1) the extensions i use to split implementation of my own classes into
different parts and / or files. for the sake of this discussion let's call
this type of extensions a "continuation".

2) the extensions that are used to extend other people classes or system
classes. this matches what we have now.

speaking of (1) the naïve newcomers from C++ land would consider these
continuations the same as splitting their C++ class implementation into
separate files. e.g. the expectation is having an ability to access
"private" members. if such a thing existed in swift at all it wouldn't be
unimaginable having an ability to add variables in these continuations the
same way as in the class itself. here  "protected" access level would be a
reasonable addition, and if we want to be totally nitpicky "protected"
would be for subclasses and some other keyword, say, "extensionprivate" or
"domestic" for continuations.

an interesting challenge would be somehow prohibiting external people
adding continuations to your own classes :)

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

Re: [swift-evolution] Making capturing semantics of local

[Mike Kluev via swift-evolution]

On 28 October 2017 at 00:00, Slava Pestov  wrote:

> That sounds like a bug, and it could occur with closure expressions also,
> since at the SILGen level and below they’re basically the same thing.
>
>
indeed:

let closure = {}
print("closure is \(closure)")  // prints: "closure is (Function)"

QED

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

Re: [swift-evolution] Making capturing semantics of local

[Mike Kluev via swift-evolution]

On 29 October 2017 at 14:02, Johannes Weiß  wrote:

Definitely not arguing with that. But there are (valid?) cases when you
> want a recursive closure which doesn’t have a native recursion mechanism
> and then `fix` can be useful I’d argue. I think more straightforward than
>
> recursive.c = { x in
>(x == 0) ? 1 : x * recursive.c(x - 1)
>}
>
>
>
you can do without "recursive.c":

var factorial: ((Int) -> Int)!

factorial = { n in
  n == 0 ? 1 : n * factorial(n - 1)
}

factorial(5) // 120



> . But fortunately have local functions, I can only recall wanting a
> recursive closure once.
>
>
in down to earth practical programming even if i didn't have local
functions i probably wouldn't bother abusing closures to implement
recursion, would just used what's available: methods. and if there is some
extra state to pass from the outer scopes, well, so be it, either via
parameters of via some instance variables, etc. wasn't too much of a
problem in good old C/C++. in a way, knowing exact state you want to pass
and passing it explicitly organises the code and the reasoning about it.

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

[swift-evolution] classprivate protection level?

[Mike Kluev via swift-evolution]

i am missing some protection level, which can be called "classprivate" or
"structprivate" / "enumprivate" (names could be better). here is an example:

--- file Some.swift ---


class Some {

private func foo() {

bar() // error: inaccessible due to 'private'

}

}

--- file Some+Bar.swift ---

extension Some {

private func bar() {

foo() // error: inaccessible due to 'private'

}

}

1) i want to have this extension in a different file (to keep file sizes
manageable).

2) i can't use either private or fileprivate due to compilation errors

3) i do not want to have neither "foo" nor "bar" public

4) "internal" doesn't help as "foo" and "bar" will be available to my app
(which is unwanted).

is there some "classprivate" to help here? if not so far, shall there be
one? opinions?

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

Re: [swift-evolution] Making capturing semantics of local

[Mike Kluev via swift-evolution]

On 28 October 2017 at 23:45, Mike Kluev  wrote:

> on Date: Fri, 27 Oct 2017 15:15:15 -0400 Alex Lynch 
> wrote:
>
> I use local functions heavily in my day-to-day workflow and an very
>> interested in them supporting capture lists.
>> Here is a draft feature specification:
>> https://bitbucket.org/snippets/lynchrb/r487zn
>>
>> Anyone see any weak spots?
>>
>
following C tradition to have declarations mimicking usage, the
weak/unowned specifier shall be on the left to the name, as the "self"
itself is on the left: self.foo

maybe a too wild idea, but how about this:

weak func foo() {
   ...
}

as a special case of "weak self" specifier. instead of:

func foo() { [weak self] in
   ...
}

of course it doesn't address everything that can be achieved by general
capture list specifiers.

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

Re: [swift-evolution] Making capturing semantics of local

[Mike Kluev via swift-evolution]

on Date: Fri, 27 Oct 2017 15:15:15 -0400 Alex Lynch 
wrote:

I use local functions heavily in my day-to-day workflow and an very
> interested in them supporting capture lists.
> Here is a draft feature specification:
> https://bitbucket.org/snippets/lynchrb/r487zn
>
> Anyone see any weak spots?
>

this shall apply to methods as well, why not.

personally i'd put things like capture list (and even parameters/result in
case of closures) outside of the brackets.

> At present, the programer has no choice but to select a closure, even if
the use case would make a local function more expressive or easier to read.

this quote raises a general question: are closures harder to read and if so
can we do anything to improve their readability.

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

Re: [swift-evolution] Making capturing semantics of local

[Mike Kluev via swift-evolution]

on Date: Fri, 27 Oct 2017 17:52:54 +0100 Johannes Weiß <
johanneswe...@apple.com> wrote:

> On 27 Oct 2017, at 6:27 am, Howard Lovatt via swift-evolution <
> swift-evolution@swift.org> wrote:
> >
> > In terms of recursion you can fiddle it:
> >
> > struct RecursiveClosure {
> > var c: C! = nil
> > }
> > func factorial(_ n: Int) -> Int {
> > var recursive = RecursiveClosure<(Int) -> Int>()
> > recursive.c = { x in
> > (x == 0) ? 1 : x * recursive.c(x - 1)
> > }
> > return recursive.c(n)
> > }
> > factorial(5) // 120


what a hack and a half :)

sorry, offtopic to the thread but that you can have easier with the
> fixed-point combinator (https://en.wikipedia.org/
> wiki/Fixed-point_combinator)
>

> // the fixed-point combinator
> func fix(_ f: @escaping ((@escaping (T) -> T) -> (T) -> T)) -> (T) -> T
> {
> return { (x: T) in (f(fix(f)))(x) }
> }
>
> // demo
> let fact = fix { fact_ in { n in n == 1 ? 1 : n * fact_(n-1) } }
> for i in 1..<10 {
> print(fact(i))
> }
>

that would be a serious crime against humanity if swift allows this type of
code at all :-)

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

Re: [swift-evolution] Making capturing semantics of local

[Mike Kluev via swift-evolution]

On Thu, 26 Oct 2017 21:54:37 -0700 Slava Pestov  wrote:

>
> Closures cannot replace all uses of local functions. Local functions can
> be recursive, and have a generic parameter list.
>
>
FTM, local functions do not help with "keep functions short" and "keep
indentation level small" rules of thumb.

what are the actual benefits of local vs non local functions? locality
principle? (define something where it is used). but we do not have it in
much more important cases, say, with static variables - we have to declare
them outside of functions. ditto for normal variables in extensions - no
matter how carefully i group functions in individual extensions based on
their purpose -- potentially in different files -- it all breaks once i
need to add a single variable to that group which i have to to in the class
itself.

what would be the damage if we remove local functions altogether, would we
lose anything really useful? aside from the fact that "it is too late at
this stage" i mean (which is appreciated).

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

[swift-evolution] stack classes

[Mike Kluev via swift-evolution]

if it wasn't already discussed here is the preliminary proposal, if it was
then my +1 to the feature.

i propose we have an explicit apparatus to denote classes having stack
storage.

stack class StackObject { // guaranteed to be on stack
}

class NonStackObject { // is not guaranteed to be on stack, can be on heap
as well
}

this is for performance reasons. sometimes what we need is “structs with
deinit” and as this is not going to happen the next best thing could be
“lightweight” classes. this shall be self obvious, here are few examples:

stack class StackObject {
var variable = 0

func foo() {
print(“i am ok to live on stack”)
}
}

stack class BadObject {
var variable = 0

func foo() {
DispatchQueue.main.async {  // error: can’t be a stack class
self.variable = 1
}
}
}

class NonStackObject {
…
}

foo() {
let stackObject = StackObject()

DispatchQueue.main.async {
stackObject.foo()  // error: can’t use a stack object in this
context
}
}
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Making capturing semantics of local

[Mike Kluev via swift-evolution]

On 27 October 2017 at 00:45, Howard Lovatt  wrote:


> Rather than expand local function syntax why not deprecate local functions
> completely
>

a cautious +0.5. local functions do not add that much value as one would
hope and beyond what's already discussed above, unfortunately break one
major programming guideline: "keep functions short" (*). the following two
fragments are not too different:

<<
func foo() {

let animations = {
self.view.alpha = 0.5 // self needed
}

UIView.animate(withDuration: 1, animations: animations) {
self.variable = 1 // self needed
print("completed")
}
}
==
func foo() {

func animations() {
view.alpha = 0.5 // can do without self...
}

func completion(_ : Bool) {
variable = 1 // can do without self...
print("completed")
}
UIView.animate(withDuration: 1, animations: animations, completion:
completion)
}
>>>

(*) - closures break the  "keep functions short" guideline as well :)

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

Re: [swift-evolution] Making capturing semantics of local

[Mike Kluev via swift-evolution]

On 26 October 2017 at 20:24, David Hart  wrote:

> I don’t see how this makes any sense or be possible:
>
> * It doesn’t make sense for me because local is not a member function of A.
> * It would cause ambiguity when trying to call another member function
> with the same name as the local function.
>

in the escaping contexts, "self." is currently required before the instance
members (**).
the idea is to require it before some local functions as well, recursively
analysing what these local functions do (at the compile time).

/* local */ foo() {
bar()
variable = 1
}

...
self.foo()

// self is required because the compiler knows what's inside, and if it
were to put the content inline that would be:

// inlining foo pseudo code:
 self.bar()
 self.variable = 1

hence the compiler can figure out that in this case "self" is required
before foo()

on the other hand:

/* local */ poo() {
print("doesnt not capture anything")
}

here, if compiler were to use poo in the escaping context it would not
require "self." before it.

this decision (whether to require "self." on not) can be on the use side.

(**) FTM, the normal instance methods that do not capture anything may as
well not require "self." before them in escaping contexts:

/* non local */ baz() {
print("doesn't capture anything")
}

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

Re: [swift-evolution] Making capturing semantics of local

[Mike Kluev via swift-evolution]

On 26 October 2017 at 19:19, Mike Kluev  wrote:

> on Wed, 25 Oct 2017 13:41:40 +0200 David Hart  wrote:
>
> class A {
>> func foo() {
>> func local() {
>> bar() // error: Call to method ‘bar' in function ‘local'
>> requires explicit 'self.' to make capture semantics explicit
>> }
>>
>> // ...
>> }
>> }
>>
>
> it's not only about calling "bar"... any variable access will require
> self. which will be quite annoying, especially given the fact that "local"
> my not even be used in an escaping context discussed. (*)
>
> i think it is more consistent to prepend local with self if it is used in
> an escaping context:
>
> func foo() {
>
> func local() {
> bar()  // no self needed here ever
> variable = 1   // no self needed here, ever
> }
>
> func otherLocal() {
> print("i am not capturing self")
> }
>
> DispatchQueue.main.async {
> local()// error without self
> self.local()   // ok
> otherLocal()   // ok without self
> }
> }
>
> (*) interestingly, closures always treat themselves as "escaping", even if
> it's not the case, e.g. even if i only use them in a non-escaping contexts.
> worth to add an explicit attribute to denote non-escaping closures?
>
> let closure = @nonescaping {
> print("i am not escaping")
> variable = 1 // ok without self
> }
>
> DispatchQueue.main.async(execute: closure) // error, non escaping closure
> passed
>
>
or, to keep the syntax close to the current one:

let closure = { nonescaping () -> Void in
 print("i am non escaping")
 variable = 1 // ok without self
}

with possible optimisations allowing omitting parameters / return values:

let closure = { nonescaping in
 print("i am non escaping")
 variable = 1 // ok without self
}
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Making capturing semantics of local

[Mike Kluev via swift-evolution]

on Wed, 25 Oct 2017 13:41:40 +0200 David Hart  wrote:

class A {
> func foo() {
> func local() {
> bar() // error: Call to method ‘bar' in function ‘local'
> requires explicit 'self.' to make capture semantics explicit
> }
>
> // ...
> }
> }
>

it's not only about calling "bar"... any variable access will require self.
which will be quite annoying, especially given the fact that "local" my not
even be used in an escaping context discussed. (*)

i think it is more consistent to prepend local with self if it is used in
an escaping context:

func foo() {

func local() {
bar()  // no self needed here ever
variable = 1   // no self needed here, ever
}

func otherLocal() {
print("i am not capturing self")
}

DispatchQueue.main.async {
local()// error without self
self.local()   // ok
otherLocal()   // ok without self
}
}

(*) interestingly, closures always treat themselves as "escaping", even if
it's not the case, e.g. even if i only use them in a non-escaping contexts.
worth to add an explicit attribute to denote non-escaping closures?

let closure = @nonescaping {
print("i am not escaping")
variable = 1 // ok without self
}

DispatchQueue.main.async(execute: closure) // error, non escaping closure
passed

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

Re: [swift-evolution] Support for a KeyCodingStrategy option in JSONEncoder and JSONDecoder

[Mike Kluev via swift-evolution]

on 19 Oct 2017 11:21:39 -0700 Eagle Offshore  wrote:

Yes, in general, I think Codable is a poor solution for json decoding just
> like I never used NSCoding to convert JSON to and from objects.  It feels
> clumsy.
>
> I found it a much better solution to add a category to NSObject that had
>
> -(NSData*)toJSONRepresentationWithMappings:(NSDictionary*)d
> +()fromJSONRepresentation:(NSData*) mappings:(NSDictionary*)d
>
> where mappings might be { @"firstName": @"first_name", etc }
>
> and was simple to write a general solution using introspection and KVC.
>
> Codable is a limited one trick pony that would be trivial to write as a
> trait or extension if Swift provided the more profound thing -
> introspection and reflection.  A whole world of opportunities would open up
> with that and we could stop wasting time on Codable and KeyPath - neither
> of which is that useful when working with string data from the wild.
>

i found Codable very useful. when you need to translate the keys it's a bit
awkward and looks "unfinished" but if you don't need the translation you
literally write no code at all which is good.

having Codable does not contradict having introspection /
reflection. general (or shall we say custom) approaches that use
introspection / reflection tend to work much slower (from Objective-C
experience). i have no data if Codable is performant in these regards but
at least it has a potential to be more optimal than a general solution
based on introspection / reflection.

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

Re: [swift-evolution] /*Let it be*/ func() -> @discardable Bool {} /*Rather Than*/ @discardableResult func() -> Bool {}

[Mike Kluev via swift-evolution]

> On 21 Oct 2017, at 17:06, Chris Lattner  wrote:
> 
> FWIW, I’d be pretty opposed to making Void? implicitly discardable.  In the 
> case of a generic function that returns T? where T can sometimes be void, the 
> optional still carries information: perhaps about failure of the operation or 
> something else.  The reason that void and Never default to being ignored is 
> that they are carry no information.   Void? carries one important bit.

Very well said.

For that same reason “return void-expression” shall not be allowed (and not 
parsed as such in a multiline statement)?

override func viewDidLoad() {
super.viewDidLoad()
return

someView = SomeView(frame: view.bounds)

}

Although it doesn’t fully solve the problem, as the two types may well be 
something other than void.

Mike

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

Re: [swift-evolution] /*Let it be*/ func() -> @discardable Bool {} /*Rather Than*/ @discardableResult func() -> Bool {}

[Mike Kluev via swift-evolution]

> On 20 Oct 2017, at 23:55, David Sweeris  wrote:
> 
>>   In any case, I think the “very high bar” we have now for breaking source 
>> compatibility makes it unlikely to change at this point

It’s not necessarily a source breaking change as both notations can be 
supported for a few versions and the older one gradually phased out via the 
deprecation warnings.

Mike


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

Re: [swift-evolution] /*Let it be*/ func() -> @discardable Bool {} /*Rather Than*/ @discardableResult func() -> Bool {}

[Mike Kluev via swift-evolution]

On 19 October 2017 at 08:52, Xiaodi Wu  wrote:

> No, I'm talking about the implicit discardability proposed by Brent, such
> as for all Optional<@discardable T>.
>
> He proposes that the @discardable syntax has a strong motivating advantage
> because it can be extended in a way to mark _types_ so that return values
> of those types are always implicitly @discardable. That is:
>
> @discardable class A { ... }
> // any return value of type A is implicitly discardable
> // what happens if A : Error and I throw A?
>
> class B : A { ... }
> // is any return value of type B also implicitly discardable?


"discardable" only apply to return types, similar to how "inout" only
applies to "parameter types"
(e.g. you can't make "func foo(x: Optional)"

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

Re: [swift-evolution] /*Let it be*/ func() -> @discardable Bool {} /*Rather Than*/ @discardableResult func() -> Bool {}

[Mike Kluev via swift-evolution]

On 19 October 2017 at 05:04, Xiaodi Wu  wrote:

>
> d) Does a class that override a `@discardable` type inherit that
> annotation? If not, they it's kind of a weird exception to the inheritance
> thing, no? If so, then we'd need a @nondiscardable annotation to do
> type-level overrides of @discardable.
>
>
the very current form of @discardableResult as a function attribute leads
to these type of questions in the first place. if it was a type modifier -
there would be no doubt:

class A {
func foo() -> Bool {
...
}

func bar() -> discardable Bool {
...
}
}

class B: A {
override func foo() -> discardable Bool { // ok, types compatible
   ...
}

override func bar() -> Bool { // error. types mismatch
...
}
}

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

Re: [swift-evolution] commas optional

[Mike Kluev via swift-evolution]

On 16 October 2017 at 01:20, Dave Yost  wrote:

> Nuance:
>
> Compiler says:
> Expression following ‘return’ is treated as an argument of the 'return
> '.
> unless foo() is indented by at least one space. Then there is no
> complaint.
>

to have more fun try this:

 return
 foo()  // visually no indent, warning

 return
 foo()  // no warning. but visually it is the same as above.

where n is the same number of spaces as in your tab-character

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

Re: [swift-evolution] commas optional

[Mike Kluev via swift-evolution]

on Date: Fri, 13 Oct 2017 20:21:22 -0700 Chris Lattner 
wrote:

We already have whitespace sensitive rules to handle this.  There is no
> fundamental implementation difference that I see between separating the
> elements of lists (which are expressions) and the elements of statements
> (which can be expressions):
>
> func foo() -> Int { … }
>
> func statements() {
>   foo()
>   foo()
> }
>
> let list = [
>   foo()
>   foo()
> ]
>

i was beaten by these optional semicolons...

override func viewDidLoad() {
super.viewDidLoad()
return // put it ad-hoc to temporarily circumvent the rest of the code
someView = SomeView(frame: view.bounds) // *
view.addSubview(someView) // **
...
}
so i put that ad-hoc return statement to circumvent the rest of the code
temporarily. of course i didn't put a semicolon after "return" as that
skill was long lost. to my surprise the app crashed, and nowhere else but
in the code that i thought was disabled...

further investigation showed that in this case compiler was treating the
statement after return which happened to have the matching type “Void” as
part of return statement.

should the function return type was, say, Int - that wouldn’t happen. or
should the next statement was of a different type - that wouldn’t happen.
in this case i was just “lucky”. here semantic information (matching vs non
matching types) is clearly "aiding" syntax parsing and sometimes it leads
to a surprising results.

there was a warning on the * line:
“warning: expression following 'return' is treated as an argument of the
'return’”

and another warning on the ** line:
“warning: code after 'return' will never be executed”

as i was prepared to get the warning about the code being unused in the
first place, i didn’t pay too much attention to the exact wording of that
warning... and was beaten by it.

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

Re: [swift-evolution] /*Let it be*/ func() -> @discardable Bool {} /*Rather Than*/ @discardableResult func() -> Bool {}

[Mike Kluev via swift-evolution]

On 15 October 2017 at 14:23, Geordie Jay  wrote:

> Hi Mike,
>
> 2017-10-15 14:55 GMT+02:00 Mike Kluev :
>
>> On 15 October 2017 at 13:35, Geordie Jay  wrote:
>>
>>> Also we're not talking about whether the Bool itself is discardable. For
>>> example, it makes no sense to write:
>>>
>>> *let something: discardable Bool = true*
>>>
>>
>> you can't write this either:
>>
>> let something: inout Bool = true
>>
>> that doesn't mean "inout" should be "@inputOutput" before the parameter
>> name in function signature.
>>
>
> This is a different case: inout is an annotation on argument types (of
> which there can be many).
>

i mean:

@discardableResult func foo(@inputOutput x: Int, @inputOutput y: Float) ->
Bool

vs:

func goo(x: inout Int, y: inout y) -> discardable Bool

i deliberately mixed the current @discardableResult syntax with a
hypothetical "consistent" @inputOutput syntax to make my point more clear.
to me these use cases are virtually the same, and syntax shall be
consistent among them.


> I don't understand what you're saying here. "Now in swift 0.0"? The first
> public version of Swift had this same functionality in its same form, with
> the name @warn_unused_result. The current version is just reversed, which
> to me is a logical change.
>

in other words: "if we didn't have swift already what would I do" kind of
test. similar to the one that we already officially use: "if it wasn't done
already, would we do it now" to prune rarely used language constructs.

remember the evolution of the "inout" keyword:

(inout x: Int)  --->  "var parameters dropped" + (x: inout Int)

similarly, it's not unimaginable to consider this evolution as well:

"@warn_unused_result func" --> "@discardableResult func" --> "func foo() ->
discardable Bool"


> throwing func foo() -> Bool
>>
>
> I personally like that syntax, because that's exactly how I *talk* about
> such a function. "oh that's a throwing function so you need to call it with
> *try*".
>

you are the first who +1-ed it so far, so we now have +2 in total for
"throwing".


> As an extension to that, I'd also say "you can call that function without
> a preceding variable assignment because it has a discardable result". I
> would never say "this function returns a discardable boolean" because that
> just doesn't match my mental model of what's going on. To me, it's the
> *function* whose return value can be discarded — in theory it has nothing
> to do with the result itself. But it's quite possible I'm in the minority
> here.
>

to me it's trivial:

func foo() -> Bool- means "function foo returning result of type Bool"

ditto:

func foo() -> discardable Bool- means "function foo returning result of
type Bool that can be unused by the caller"

very compatible with:

foo(x: inout Bool)- means input / output parameter x that is of type
Bool

if you don't complain about the latter (like: "how come Bool is input
output?! it is the parameter that is input / output, not the Bool itself
!!!" or, similarly: "how come the function returns type Never? the function
just never returns but the type shall be Void !!!") then I don't see why
you don't accept the former.

But it's quite possible I'm in the minority here.
>

as a matter of fact, so far it looks I am :)

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

Re: [swift-evolution] /*Let it be*/ func() -> @discardable Bool {} /*Rather Than*/ @discardableResult func() -> Bool {}

[Mike Kluev via swift-evolution]

On 13 October 2017 at 22:50, Jean-Daniel  wrote:

I mean:
>
> func foo() -> Int { … }
>
> func bar(callback: () -> discardable Int) { … }
>
> bar(foo) // does it warns ?
> bar({ 3 }) // does it warns ? If it does, how to avoid it ?
>

thanks.

>>> And allowing it in signature but not in lambda would be confusing.

not any more confusing than it is now (allowing @discardableResult before
function name and not allowing it before closure parameters).

but, if to fix that, than could be this (orthogonal to whether it is
"@discardableResult" or "discardable"):

func foo() -> Int {}
func bar(_ callback: () -> discardable Int) {}

bar(foo) // error, type mismatch
bar({ 3 }) // error, type mismatch
bar({ () -> discardable Int in 3 }) // ok, types matched

- and -

func poo() -> discardable Int {}
func baz(_ callback: () -> Int) {}

baz(poo) // ok, types compatible
baz({ 3 }) // ok, types matched
baz({ () -> discardable Int in 3 }) // ok, types compatible

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

Re: [swift-evolution] /*Let it be*/ func() -> @discardable Bool {} /*Rather Than*/ @discardableResult func() -> Bool {}

[Mike Kluev via swift-evolution]

On 13 October 2017 at 21:15, Jean-Daniel  wrote:

> I don’t think this is a good idea to make discardable part of the function
> type.
>
> What would fun(callback: () -> discardable Int) would means ?
>

you mean this?

func foo(callback: () -> discardable Int) {
...
let x = callback()
...
callback() // no warning or error here
}

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

Re: [swift-evolution] [Proposal] Random Unification

[Mike Kluev via swift-evolution]

On Wed Oct 11 12:21:14 CDT 2017 Cory Benfield cbenfield at apple.com  wrote:
> I strongly recommend building the padded room.

interesting view point.

FTM, the arithmetic operations in swift are "safe and slow" by default,
same principle...
although they are not that slow (compared to how secure random numbers can
be).

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

Re: [swift-evolution] /*Let it be*/ func() -> @discardable Bool {} /*Rather Than*/ @discardableResult func() -> Bool {}

[Mike Kluev via swift-evolution]

On 12 October 2017 at 14:14, David James  wrote:

> True, and it was making the method signature too long. But at least I have
> the option to do that. If we move the annotation to just before the return
> type, then we have no choice.
>

you can still put it on the next line along with the result :)

imho, this shall not be a decision maker nowadays (20 years ago it would).

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

Re: [swift-evolution] /*Let it be*/ func() -> @discardable Bool {} /*Rather Than*/ @discardableResult func() -> Bool {}

[Mike Kluev via swift-evolution]

On 12 October 2017 at 09:34, David James  wrote:

> IMO everyday app building would rarely need to use functions with
> discardable results. This is more an issue with libraries or frameworks
> that support a *fluent interface* (e.g. that return self) where an
> operator chain can be stopped at any point, unless it clearly doesn’t make
> sense, in which case @discardableResult would not be advised. I am building
> such a library. It has 200+ uses of @discardableResult and *I don’t have
> a problem with it in it’s current form* (especially since it can go on
> the line before the function). It’s an annotation for a specialized
> purpose, hence the very specific nomenclature.
>

let me guess: you put it on a different line exactly because it is in it's
current ugly form :)

personally, if "x: inout Int" is in it's current form (vs. "@inputOutput x:
Int") so shall be "discardable Int", i see no principle difference between
them to make one looking it is from a different planet altogether.

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

Re: [swift-evolution] [Proposal] Random Unification

[Mike Kluev via swift-evolution]

On 11 October 2017 at 18:30, Mike Kluev  wrote:

> > On 7 Oct 2017, at 04:24, Chris Lattner via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>> >
>> >> These aren’t the forms I was suggesting, what I meant was:
>> >
>> > extension Int {
>> >   init(randomInRange: Countable{Closed}Range)
>> > }
>> >
>> > which gives:
>> >   let x = Int(randomInRange: 0..<5)
>> >
>> > The point of this is that you’re producing an Int (or whatever type).
>> Regardless of whether the initializer is failable or not, this is the
>> preferred way of creating a new value with some property: it is an
>> initializer with a label.
>>
>
> or make it a non-initialiser: let x = Int.random or Int.random()
>

on the positive side would be ability to omit types in many cases:

foo(_ x: Int) { ... }

foo(.random)   // Int.random inferred


> have you guys considered: func random(...) -> T
> where it returns a different type based on a context?
>

or "foo(random())" here,  random() inferred

the latter case opens wide opportunities for strict type/range checking,
e.g.:

if "angle" is a variable ranging from 0 .. 2*pi then

angle = random()   // is inferred as a 0 .. 2*pi range without me typing
anything

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

Re: [swift-evolution] [Proposal] Random Unification

[Mike Kluev via swift-evolution]

> On 7 Oct 2017, at 04:24, Chris Lattner via swift-evolution <
swift-evolution@swift.org> wrote:

> >
> >> These aren’t the forms I was suggesting, what I meant was:
> >
> > extension Int {
> >   init(randomInRange: Countable{Closed}Range)
> > }
> >
> > which gives:
> >   let x = Int(randomInRange: 0..<5)
> >
> > The point of this is that you’re producing an Int (or whatever type).
> Regardless of whether the initializer is failable or not, this is the
> preferred way of creating a new value with some property: it is an
> initializer with a label.
>

every now and then i found myself in a situation i want to use this
preferred way, and i need a label... but i do not have anything to pass,
e.g.:

let x = Int(random)  // oops

has to resort to hacks: let x = Int(random: ())
or make it a non-initialiser: let x = Int.random or Int.random()

have you guys considered: func random(...) -> T
where it returns a different type based on a context?

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

Re: [swift-evolution] Property Getter Return Statement

[Mike Kluev via swift-evolution]

On Tue Oct 10 15:02:37 CDT 2017 Slava Pestov spestov at apple.com wrote:

>> I’m minorly opposed, because it feels like a slippery slope. What about
function bodies? etc
>>
>> func foo() -> Int { 3 } // should this be allowed?

a small -1

or even:

func foo() { 3 } // Int return type inferred as well

a small -1

or

func(x = true) // Bool for x parameter inferred

a small +1

> In fact the reason I thought the original thread was about
> omitting the return type, rather than just omitting the ‘return’,
> is that I feel the main reason that single-expression closures
> exist is so that their type can be inferred as part of the
> expression containing the closure. Swift does not infer types
> across statement boundaries, so single expression closures
> exist, as a special case, to help you avoid declaring types in some cases.

if you are from a school of thought that "everything is a closure" - it
would make sense.

"if expression closure else closure"

"var x { // return type inferred :-)
   get closure
   set closure
}"

"func foo closure"

in the latter case it would worth to use the same parameter passing syntax
as in closures for consistency:

func foo { (x: Int) in }
vs
func foo(x: Int) {}

> Chris will say no, it’s about concision, and omitting the ‘return’,
> but deep down in his heart, he knows that single-expression
> closures were really just a type inference hack :-)

the amount of optimisation done in closure syntax was overwhelming when i
first saw it.

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

Re: [swift-evolution] /*Let it be*/ func() -> @discardable Bool {} /*Rather Than*/ @discardableResult func() -> Bool {}

[Mike Kluev via swift-evolution]

On 10 October 2017 at 07:02, Xiaodi Wu  wrote:

> This idea was discussed long ago and the present design was selected. At
> this point in Swift Evolution, source-breaking changes are in scope only if
> the status quo is demonstrably harmful.


changes like discussed are not necessarily source-breaking: you can allow
@discardableResult for a while (along with deprecating it at some point) in
addition to having a newer preferred way - should we decide there is a
preferred way.

on Mon, 09 Oct 2017 20:07:13 +0200 Tino Heth  wrote:

> As for the line-length, I don’t buy this argument, because placement of
> line breaks is just personal preference, and keywords/annotations created
> by gluing together two words should imho avoided wherever possible (not
> only because the increased character count).


+1. same here on both counts. multi-word compound and @ symbol makes names
ugly. it feels it was done intentionally to indicate a "temporary" "to be
cleaned later" nature of a feature (it is a very good choice for @objc)

and if "fileprivate" is ugly because it is two words glued together (*)
maybe there is another name for it? just "file"? "domestic" ?

Mike
(* the very concept of "file private" is a bit ugly from a traditional
languages perspective).
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] /*Let it be*/ func() -> @discardable Bool {} /*Rather Than*/ @discardableResult func() -> Bool {}

[Mike Kluev via swift-evolution]

On 9 October 2017 at 20:43, Howard Lovatt  wrote:

>
> I would prefer something like:
>
> func x() -> Bool @ throws disguardableResult public async mutating
>
> Where @ introduces a list of space separated modifiers.
>

make it more English :)

public async mutating throwing func foo() -> discardable Bool {
...
}

Unfortunately I am not sure this is practical at this stage.
>

true :(

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

Re: [swift-evolution] /*Let it be*/ func() -> @discardable Bool {} /*Rather Than*/ @discardableResult func() -> Bool {}

[Mike Kluev via swift-evolution]

On Sat, 7 Oct 2017 07:48:08 +0100, 
wrote:

> So it would be:
>
> func() -> @discardable Bool { }
>
> Rather than:
>
> @discardableResult func() -> Bool { }
>


i'd say:

func foo() -> discardable Bool {
...
}

if we were starting from scratch

It could be even better if someone could perhaps find a shorter word that
> is a synonym for the word "discardable", that would be as explicit in
> intent as the word "discardable" is in such context, yet be written with
> fewer characters.
>

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

Re: [swift-evolution] A path forward on rationalizing unicode identifiers and operators

[Mike Kluev via swift-evolution]

On 4 October 2017 at 14:24, Alex Blewitt  wrote:

func &&&(left: Bool, right: @autoclosure () -> Bool) -> Bool {
> return left && right()
> }
>

FTM, it would be nice to be able to "syntax sugar-ize" it into a better
looking:

func &&& (left: Bool, right: lazy Bool) -> Bool {
return left && right  // no parens here
}

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

Re: [swift-evolution] A path forward on rationalizing unicode identifiers and operators

[Mike Kluev via swift-evolution]

On 4 October 2017 at 14:24, Alex Blewitt  wrote:

> On 4 October 2017 at 13:41, Alex Blewitt  wrote:
>
>>
>> The difference between the & and && operators isn't to do with the
>> implicit conversions; it's to do with whether both sides of the expression
>> are evaluated or not.
>>
>
> However, you can wrap the second argument in an @autoclosure, which means
> it replaces the body of the expression with a function that evaluates the
> expression automatically:
>
> infix operator &&&: LogicalConjunctionPrecedence
>
> func &&&(left: Bool, right: @autoclosure () -> Bool) -> Bool {
> return left && right()
> }
>

great. as you just shown, the difference of short-circuiting or not is not
inside the operator declaration itself (like it is defined in C)
but in the actual operator implementation, so we can have:

infix operator &&&: LogicalConjunctionPrecedence

func &&&(left: Bool, right: @autoclosure () -> Bool) -> Bool {
return left && right()
}

func &&&(left: Int, right: Int) -> Int {
return left & right
}

where the logical one short-circuits and bit-wise one doesn't.

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

Re: [swift-evolution] A path forward on rationalizing unicode identifiers and operators

[Mike Kluev via swift-evolution]

On 4 October 2017 at 13:41, Alex Blewitt  wrote:

>
> The difference between the & and && operators isn't to do with the
> implicit conversions; it's to do with whether both sides of the expression
> are evaluated or not.
>
> false && system('rm -rf')
>
> You really don't want to do that if both sides are executed ...
>

actually, thanks for bringing this up as it leads up to a question:

how in swift do i define my &&& operator (that i may need for whatever
reason, e.g. logging) that will short-circuit
the calculation of right hand side if the left hand side is false?

infix operator &&&: LogicalConjunctionPrecedence

func &&&(left: Bool, right: Bool) -> Bool {
return left && right
}

as written it doesn't short-circuit. is it possible at all in swift?

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

Re: [swift-evolution] A path forward on rationalizing unicode identifiers and operators

[Mike Kluev via swift-evolution]

On 4 October 2017 at 13:41, Alex Blewitt <alb...@apple.com> wrote:

> On 4 Oct 2017, at 11:42, Mike Kluev via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> speaking of &&, was it just a copy-paste from C or is there a more
> fundamental reason to use that instead of &? in C they had to use two
> different operators because of the implicit int <-> bool promotions, but in
> swift "true & false" vs "1 & 2" would have been distinguishable.
>
>
> The difference between the & and && operators isn't to do with the
> implicit conversions; it's to do with whether both sides of the expression
> are evaluated or not.
>
> false && system('rm -rf')
>
> You really don't want to do that if both sides are executed ...
>

true. however what would stop the hypothetical "logical &" operator to not
evaluate the right hand side if the left
side is false similar to how && behaves? yes, it would make it more
different to the "bitwise &" operator, but they are
already a bit different.

(it was always backwards to me even in C: bitwise *single* & is for and-ing
*multiple* bit pairs, whilst a
*multi-character* && is for and-ing a single bool pair.)

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

Re: [swift-evolution] Swift and actors

[Mike Kluev via swift-evolution]

on Wed, 4 Oct 2017 00:16:14 +0200 Benjamin Garrigues <
benjamin.garrig...@gmail.com> wrote:

> Same goes for actors and blocking calls : if you're dealing with a few
coarsed
> grained actors that handle a large state and communicate over an
unreliable
> medium ( such as a network) , you're going to have a very different need
than
> if all your actors run on the same cpu and each handle a very small part
of
> your logic and data. In the second case you're using actors for thread
safety
> and not really to manage failure or lag in actor to actor communications.

exactly my thoughts. unreliably UDP-style "best effort" delivery approach
which
is at the core of actors and "thread safety problems and their solutions on
a single
or multi core CPU box" are two different tasks at hand IMHO. unless i
misunderstand something fundamental here, which is of course possible.

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

Re: [swift-evolution] A path forward on rationalizing unicode identifiers and operators

[Mike Kluev via swift-evolution]

on Tue, 3 Oct 2017 11:00:33 -0600 Dave DeLong 
  wrote:

> Because, ideally, I’d love to be able to do:
>
> infix operator and: LogicalConjunctionPrecedence // or whatever the
precedence is called
> func and(lhs: Bool, rhs: Bool) → Bool { return lhs && rhs }
>
> let truthyValue = true and false

+1 (i like your thinking, even if it is unlikely to happen in swift)

(noteworthy, your example used "RIGHTWARDS ARROW" (U+2192) instead of ->,
whether on purpose or not.)

speaking of &&, was it just a copy-paste from C or is there a more
fundamental reason to use that instead of &? in C they had to use two
different operators because of the implicit int <-> bool promotions, but in
swift "true & false" vs "1 & 2" would have been distinguishable.

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

Re: [swift-evolution] Beyond Typewriter-Styled Code in Swift, Adoption of Symbols

[Mike Kluev via swift-evolution]

on Fri, 1 Sep 2017 00:40:25 +0200 André Videla 
wrote:

> Furthermore, I would argue that using `+` for matrices is more consistent
than the current definition of `+`.
> Indeed, the operator `+` is both used for combining numbers and combining
arrays/strings.
> The inconsistency comes from the fact that it is expected that `+` is a
commutative operator,
> but concatenation is not a commutative operation. Therefore the semantics
of `+` varies
> depending on the types that it’s used on. And, in my opinion, this
inconsistency is to be
> avoided when dealing with operators. Not to mention that nothing prevent
a library to override
> `+` with any nonsensical behaviour.

how would you multiply matrices, or multiply matrix by a number? let's say
you will use * for that. but matrix x matrix multiplication is not
commutative (while matrix x number is). would you propose to use ** instead?

if i have:

func * (m: Matrix, n: Double) -> Matrix

with * somehow marked "commutative", shall i be able using it as n*M
straight away without having explicit:

func * (n: Double, m: Matrix) -> Matrix

while using + for string concatenation is a long standing tradition it
is indeed a bit awkward (as awkward as 1 + 2 = 12 would be)

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

Re: [swift-evolution] ability to derive a class from a struct or other value type

[Mike Kluev via swift-evolution]

On 23 June 2017 at 23:18, Tony Allevato  wrote:

class C1: C2  ==>  C1() is C2 == true
> class C1: P  ==>  C1() is P == true
> class C1: S  ==>  C1() is S == false?
>

ok. changing the rule then:

C() is S == true

foo(x) acts the same way as foo(x.super)
bar() acts the same way as bar()

i am not quite sure i am getting the answers along the lines of "use
protocol forwarding" instead. i have no protocol to begin with. for a
preexisting value type (e.g. OS provided) it would be a nightmare to create
and maintain the corresponding protocol.

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

Re: [swift-evolution] ability to derive a class from a struct or other value type

[Mike Kluev via swift-evolution]

On 23 June 2017 at 18:31, Tony Allevato  wrote:

>
> Imagine something like this:
>
> struct BaseStruct { ... }
> class ExtendsStruct: BaseStruct { ... }
>
> func foo(x: BaseStruct) { ... }
> func bar(x: inout BaseStruct) { ... }
>
> var x = ExtendsStruct(...)
> foo(x)
> bar()
>

would be:

foo(x) // same as foo(x.super)  for which it easy to see what's going on
bar() // same as bar() for which it is easy to see what's going on


> What is the behavior in each of these cases? Do foo and bar get a
> value-type slice of x? Is that slice the same memory as is occupied by x,
> or is it a copy? When bar mutates its argument, does it modify the same
> memory occupied by x?
>

all these questions are easily answered if you consider the equivalent
manual implementation...


> Let's go back to step 1: what's your use case for wanting inheritance
> between a class and a struct vs. something like protocol forwarding?
>

i don't control the preexisting value type in general case, so there is no
protocol around to hijack.

essentially this proposal allows your own or preexisting value type to act
as a reference type without having any code or upfront provisions. no more,
no less. if you ever had a thought similar to: "i need String / Data / Rect
/ etc but the one that's reference type" this device will be for you.

class ClassString: String {}
class ClassData: Data {}
class ClassCGRect: CGRect {}

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

Re: [swift-evolution] ability to derive a class from a struct or other value type

[Mike Kluev via swift-evolution]

on Fri Jun 23 05:26:11 CDT 2017 Haravikk swift-evolution at haravikk.me
wrote:

> Not sure what you mean by added indirection here, the following seems
perfectly straightforward to me:
>
>  protocol Foo {
>  var someValue:Int { get set }
>  func a() -> Any?
>  }
>
>  extension Foo {
>  func a() -> Any? { return self.someValue }
>  }
>
>  struct ValueSemantics:Foo { var someValue:Int }
>  class ReferenceSemantics:Foo {
>  var someValue:Int { return nil }
>  }
>
> There is no added access overhead here, the only difference is that the
protocol itself leaves it up to
> implementations whether someValue is stored or computed.

in real cases there would be more variables:

//
protocol P1 {   // #noise
var var1: Int { get set }   // #noise
var var2: Int { get set }   // #noise
// ...  // #noise x 100
var var100: Int { get set } // #noise

func foo1() -> Int  // #noise
func foo2() -> Int  // #noise
// ...  // #noise x 100
func foo100() -> Int// #noise
}

extension P1 {  // #noise
func foo1() -> Int { return var1 * 2 }
func foo2() -> Int { return var2 * 2 }
// ...
func foo100() -> Int { return var100 * 2 }
}

struct S1: P1 {
var var1: Int   // #noise
var var2: Int   // #noise
// ...  // #noise x 100
var var100: Int // #noise
}

class C1: P1 {
var var1: Int = 0   // #noise
var var2: Int = 0   // #noise
// ...  // #noise x 100
var var100: Int = 0 // #noise
}
//


lots of noise and violations of DRY. you may try to mitigate it by putting
all those storage into another struct, that was the indirection i was
thinking about:

//
struct Pimpl {  // #noise
var var1: Int = 0
var var2: Int = 0
// ...
var var100: Int = 0

func foo1() -> Int { return var1 * 2 }
func foo2() -> Int { return var2 * 2 }
// ...
func foo100() -> Int { return var100 * 2 }
}

protocol P2 {   // #noise
var pimpl: Pimpl { get set }// #noise

func foo1() -> Int  // #noise
func foo2() -> Int  // #noise
// ...  // #noise x 100
func foo100() -> Int// #noise
}

extension P2 {  // #noise
func foo1() -> Int { return pimpl.var1 * 2 }// #indirection
func foo2() -> Int { return pimpl.var2 * 2 }// #indirection
// ...  // #indirection x
100
func foo100() -> Int { return pimpl.var100 * 2 }// #indirection
}

struct S2: P2 {
var pimpl: Pimpl// #noise

init() {
pimpl = Pimpl() // #noise
}
}

class C2: P2 {
var pimpl: Pimpl// #noise

init() {
pimpl = Pimpl() // #noise
}
}
//

while the proposed solution has minimal amount of noise:

//
struct S3 {
var var1: Int
var var2: Int
// ...
var var100: Int

func foo1() -> Int { return var1 * 2 }
func foo2() -> Int { return var2 * 2 }
// ...
func foo100() -> Int { return var100 * 2 }
}

class C3: S3 {
}
// ===

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

Re: [swift-evolution] a few initializer proposals

[Mike Kluev via swift-evolution]

On 23 June 2017 at 01:20, Xiaodi Wu > wrote:

> These issues which you have raised have been discussed thoroughly on this
> list some time ago. It was distilled into a very well written proposal,
> SE-0018, that was evaluated and deferred. I would recommend that you and
> all people who are interested in this topic review the initial pitch and
> the subsequent discussions that took place.
>
> At the conclusion of that process, any improvements for memberwise
> initialization were deemed out of scope for Swift 3. Subsequently, all
> sugar was out of scope for Swift 4 phase 1 and deemed to be extremely low
> priority for Swift 4 phase 2. Whether the topic will be in scope again is
> an open question.
>
> The summary of the core team's decision is unusually long and
> extraordinarily enlightening. The issues about this feature being out of
> scope are discussed as "meta-points," and an extensive amount of text
> explains the thought process behind that conclusion. Beyond that, however,
> the decision also explores a truly remarkable set of possible solutions to
> the underlying issue, and it raises very interesting (non-meta) points that
> would have to be carefully considered before any revised proposal.
>

thanks. interesting reading indeed:

https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160111/006469.html

"We can tackle this sort of sugar feature at any time, including in Swift
4.  The core team would like to defer talking about this for a couple of
months until the other things (property behaviors, resilience, and other
big changes) are behind us. "

that was written in Jan 2016, a year and a half ago. time to resurrect?

personally i am not too mad about the "path forward" outcome at the bottom.
looks a bit too verbose, a bit too complicated and a bit too "over
engineered", but that's in my humble imho. personally i'd tend to more
simple measures, e.g. if there is "let x = 0" and it looks a problem if we
override it (as it does indeed) - just don't have those "let's" it in the
default memberwise initializer parameter list - done.

btw. don't blame syntax sugar, it's not without value when it helps
eliminating 200 or even 2 lines.

speaking of "kicking the can down the road" - i trust this is a valuable
approach still... it is very hard (and almost impossible) to do it right
straight away... whether there will be needed 10 iterations until it's
right or 3, or what particular swift version it is in - not that important.

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

Re: [swift-evolution] ability to derive a class from a struct or other value type

[Mike Kluev via swift-evolution]

On 23 June 2017 at 02:43, Tony Allevato > wrote:

> There's been talk about "protocol forwarding" that I think would achieve a
> lot of these goals, without the sharp edges involved trying to define
> inheritance between a class and a struct. The proposed feature would
> eliminate the boilerplate you're talking about.
>
> I'm on my phone so I can't pull up links to old discussions, but Matthew
> Johnson is who was pushing it so you may want to look back at what he's
> said on the topic.
>

thanks, i skimmed through it now and will have a closer look later.
does it address (2) though? (preexisting value types we can't change)

as to the sharp edges: i do not see a single one in the "manual"
implementation of this approach and the idea of this proposal is that it is
equivalent to the manual implementation...

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

Re: [swift-evolution] a few initializer proposals

[Mike Kluev via swift-evolution]

On 23 June 2017 at 02:39, Mike Kluev  wrote:

>
> if a single private var has no implicit / explicit default value then
> default member wise initialiser is not created (#change) and attempt to
> opt-in to have one gives an error. let's call it proposal #5. this
> particular one is not a backward compatible change, the old code will have
> to be modified.
>

alternatively:

in case of private members with no implicit / explicit default values, we
may have a private memberwise initialiser with all private member
parameters as well. you can create your own public initializer and call
through the private memberwise initializer if needed

struct S {
  var a: Int
  var b: Int = 0

  private var c: Int
  private var d: Int?

// autogenerated (#change)
//
//  private init(a: Int, b: Int = 0, c: Int, d: Int? = nil) {   // private
//self.a = a
//self.b = b
//self.c = c
//self.d = d
//  }

  init(... whatever ...) {
self.init(a: , b: ., c: , d: )
  }
}

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

Re: [swift-evolution] a few initializer proposals

[Mike Kluev via swift-evolution]

On 23 June 2017 at 00:36, Brian King > wrote:

> A similar syntax has already been proposed and has been `deferred`. There
> are a few other links to discussion in the proposal.
>
> https://github.com/apple/swift-evolution/blob/master/
> proposals/0018-flexible-memberwise-initialization.md
>

thank you Brian.

i like the "default value" idea in those proposals. speaking of lazy vars,
maybe just to not have them in the default memberwise initializer param
list at all:

// this is NOT how the language behaves currently:

struct S {
var a: Int
var b: Int = 0
var c: Int?
var d: Int? = nil // same as c
var e: Int!
lazy var f: Int = { return 0 } ()

//  expected "reasonable" default memberwise initializer autogenerated or
opt-in-ed:
//
//  init(
//  a: Int,
//  b: Int = 0, // got default value #change
//  c: Int? = nil,  // got implicit default value #change
//  d: Int? = nil,  // got default value #change
//  e: Int! // no default value - safer
//  // f is absent due to lazy #change
//  )
//  {
//  self.a = a
//  self.b = b
//  self.c = c
//  self.d = d
//  self.e = e
//  // f is absent due to lazy #change
//  }
}

speaking of private var members, if they have an implicit or explicit
default value:

private var g: Int = ...
private var h: Int?
private var i: Int? = ...
private var j: Int!
private var k: Int! = ...

they can be omitted from the parameter list of the default memberwise
initialiser (#change) similar to how lazy vars are omitted above.
if a single private var has no implicit / explicit default value then
default member wise initialiser is not created (#change) and attempt to
opt-in to have one gives an error. let's call it proposal #5. this
particular one is not a backward compatible change, the old code will have
to be modified.

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