Re: [swift-evolution] [Discussion] Swift for Data Science / ML / Big Data analytics

[Richard Wei via swift-evolution]

> On Nov 1, 2017, at 21:13, Chris Lattner via swift-evolution 
>  wrote:
> 
>> On Nov 1, 2017, at 3:20 AM, Richard Wei > > wrote:
 
 Since you bring it up, Python exceptions will be annoying - As with other 
 languages, Python can throw from an arbitrary expression.  Modeling 
 everything as throws in Swift would be super-annoying and unergonomic for 
 the programmer, because we'd require 'try' everywhere.  Thoughts on what 
 to do about that are welcome!
>>> 
>>> Requiring ‘try’ on every statement is annoying, but not having the ability 
>>> to catch python exceptions is annoying too. We could probably make python 
>>> exception handling an opt-in feature. For example:
>>> 
>>> try Python.do {
>>> let a = np.array([1, 2, 3])
>>> let b = np.array([[2], [4]])
>>> print(a.dot(b)) // matrix mul with incompatible shapes
>>> }
>>> catch let error as PythonException {
>>> // Handle PythonError.valueError(“objects are not aligned”)
>>> }
>> 
>> To correct my example:
>> 
>> do {
>> try Python.do {
>> let a = np.array([1, 2, 3])
>> let b = np.array([[2], [4]])
>> print(a.dot(b)) // matrix mul with incompatible shapes
>> }
>> }
>> catch let error as PythonException {
>> // Handle PythonError.valueError(“objects are not aligned”)
>> }
>> 
>> Maybe ‘Python.do {}’ should be called something like ‘Python.safely {}’.
> 
> That’s a super interesting way to model this.  I’ll need to ponder on it 
> more, but  it is certainly a nice ergonomic solution.
> 
> Question though: how does it work?  Say the first np.array call threw a 
> python exception:
> 
>> try Python.do {
>> let a = np.array([1, 2, 3])
>> let b = np.array([[2], [4]])
>> print(a.dot(b)) // matrix mul with incompatible shapes
>> }
> 
> 
> We can definitely make the python glue code notice it, catch it and squirrel 
> it away somewhere, but without compiler hacks we couldn’t make it jump out of 
> the closure.  This means that np.array would have to return something, and 
> the calls below it would still execute, or am I missing something?

We make PythonObjects internally nullable (only in the exception-caught state). 
The second np.array would just return a null PythonObject.

To be specific, we define three states in the python overlay:
- Normal state: PythonObjects are guaranteed to be non-null. Any exception 
traps.
- Exception-catching state: PythonObjects are still guaranteed to be non-null. 
Any exception triggers the exception-caught state.
- Exception-caught state: PythonObjects are nullable — all python expressions 
return a null PythonObject.

The exception-catching state is entered during the execution of Python.do’s 
body.

-Richard

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



signature.asc
Description: Message signed with OpenPGP
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Discussion] Swift for Data Science / ML / Big Data analytics

[Chris Lattner via swift-evolution]

> On Nov 1, 2017, at 3:20 AM, Richard Wei  wrote:
>>> 
>>> Since you bring it up, Python exceptions will be annoying - As with other 
>>> languages, Python can throw from an arbitrary expression.  Modeling 
>>> everything as throws in Swift would be super-annoying and unergonomic for 
>>> the programmer, because we'd require 'try' everywhere.  Thoughts on what to 
>>> do about that are welcome!
>> 
>> Requiring ‘try’ on every statement is annoying, but not having the ability 
>> to catch python exceptions is annoying too. We could probably make python 
>> exception handling an opt-in feature. For example:
>> 
>> try Python.do {
>> let a = np.array([1, 2, 3])
>> let b = np.array([[2], [4]])
>> print(a.dot(b)) // matrix mul with incompatible shapes
>> }
>> catch let error as PythonException {
>> // Handle PythonError.valueError(“objects are not aligned”)
>> }
> 
> To correct my example: 
> 
> do { 
> try Python.do {
> let a = np.array([1, 2, 3])
> let b = np.array([[2], [4]])
> print(a.dot(b)) // matrix mul with incompatible shapes
> }
> }
> catch let error as PythonException {
> // Handle PythonError.valueError(“objects are not aligned”)
> }
> 
> Maybe ‘Python.do {}’ should be called something like ‘Python.safely {}’.

That’s a super interesting way to model this.  I’ll need to ponder on it more, 
but  it is certainly a nice ergonomic solution.

Question though: how does it work?  Say the first np.array call threw a python 
exception:

> try Python.do {
> let a = np.array([1, 2, 3])
> let b = np.array([[2], [4]])
> print(a.dot(b)) // matrix mul with incompatible shapes
> }


We can definitely make the python glue code notice it, catch it and squirrel it 
away somewhere, but without compiler hacks we couldn’t make it jump out of the 
closure.  This means that np.array would have to return something, and the 
calls below it would still execute, or am I missing something?

-Chris


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

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

[Lee M via swift-evolution]

I suggested something similar a little while ago:
https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170327/034767.html
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] “Integer” protocol?

[David Sweeris via swift-evolution]

> On Nov 1, 2017, at 14:54, Kelvin Ma via swift-evolution 
>  wrote:
> 
> 
> 
>> On Wed, Nov 1, 2017 at 12:15 PM, Xiaodi Wu via swift-evolution 
>>  wrote:
>>> On Wed, Nov 1, 2017 at 07:24 Daryle Walker  wrote:
>> 
>>> 
>>> 
>>> Sent from my iPad
>>> 
 On Oct 31, 2017, at 10:55 PM, Xiaodi Wu  wrote:
 
 Right, these issues were discussed when the proposal was introduced and 
 reviewed three times. In brief, what was once proposed as `Integer` was 
 renamed `BinaryInteger` to avoid confusion in name between `Integer` and 
 `Int`. It was also found to better reflect the semantics of the protocol, 
 as certain functions treated the value not merely as an integer but 
 operated specifically on its binary representation (for instance, the 
 bitwise operators).
 
 Do not confuse integers from their representation. Integers have no 
 intrinsic radix and all integers have a binary representation. This is 
 distinct from floating-point protocols, because many real values 
 representable exactly as a decimal floating-point value cannot be 
 represented exactly as a binary floating-point value.
>>> 
>>> Abstractly, integers have representations in nearly all real radixes. But 
>>> mandating base-2 properties for a numeric type that uses something else 
>>> (ternary, negadecimal, non-radix, etc.) in its storage is definitely 
>>> non-trivial. Hence the request for intermediate protocols that peel off the 
>>> binary requirements. 
>> 
>> Not only binary properties, but specifically two’s-complement binary 
>> properties. You are correct that some operations require thought for 
>> implementation if your type uses ternary storage, or for any type that does 
>> not specifically use two’s-complement representation internally, but having 
>> actually implemented them I can assure you it is not difficult to do 
>> correctly without even a CS degree.
>> 
>> Again, one must distinguish between the actual representation in storage and 
>> semantics, which is what Swift protocols guarantee. The protocols are 
>> totally agnostic to the internal storage representation. The trade-off for 
>> supporting ternary _semantics_ is an additional set of protocols which 
>> complicates understanding and use in generic algorithms. I am not aware of 
>> tritwise operations being sufficiently in demand.
> 
> Before everyone gets carried away with these protocols, can I ask what the 
> real use case for ternary integers is? Also I’m not a fan of bikeshedding 
> protocols for things that don’t exist (yet).

I can’t imagine it’d ever get far enough for me to care about Swift’s stance on 
the issue, but I want to build a 9-“trit” breadboard computer some day, just 
for my own edification/amusement.

(FWIW, while I’m not 100% on how the integer protocols ended up, this isn’t the 
part that I’d change)

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

Re: [swift-evolution] “Integer” protocol?

[Kelvin Ma via swift-evolution]

On Wed, Nov 1, 2017 at 12:15 PM, Xiaodi Wu via swift-evolution <
swift-evolution@swift.org> wrote:

> On Wed, Nov 1, 2017 at 07:24 Daryle Walker  wrote:
>
>>
>>
>> Sent from my iPad
>>
>> On Oct 31, 2017, at 10:55 PM, Xiaodi Wu  wrote:
>>
>> Right, these issues were discussed when the proposal was introduced and
>> reviewed three times. In brief, what was once proposed as `Integer` was
>> renamed `BinaryInteger` to avoid confusion in name between `Integer` and
>> `Int`. It was also found to better reflect the semantics of the protocol,
>> as certain functions treated the value not merely as an integer but
>> operated specifically on its binary representation (for instance, the
>> bitwise operators).
>>
>> Do not confuse integers from their representation. Integers have no
>> intrinsic radix and all integers have a binary representation. This is
>> distinct from floating-point protocols, because many real values
>> representable exactly as a decimal floating-point value cannot be
>> represented exactly as a binary floating-point value.
>>
>>
>> Abstractly, integers have representations in nearly all real radixes. But
>> mandating base-2 properties for a numeric type that uses something else
>> (ternary, negadecimal, non-radix, etc.) in its storage is definitely
>> non-trivial. Hence the request for intermediate protocols that peel off the
>> binary requirements.
>>
>
> Not only binary properties, but specifically two’s-complement binary
> properties. You are correct that some operations require thought for
> implementation if your type uses ternary storage, or for any type that does
> not specifically use two’s-complement representation internally, but having
> actually implemented them I can assure you it is not difficult to do
> correctly without even a CS degree.
>
> Again, one must distinguish between the actual representation in storage
> and semantics, which is what Swift protocols guarantee. The protocols are
> totally agnostic to the internal storage representation. The trade-off for
> supporting ternary _semantics_ is an additional set of protocols which
> complicates understanding and use in generic algorithms. I am not aware of
> tritwise operations being sufficiently in demand.
>

Before everyone gets carried away with these protocols, can I ask what the
real use case for ternary integers is? Also I’m not a fan of bikeshedding
protocols for things that don’t exist (yet).
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Adam Kemp via swift-evolution]

> On Nov 1, 2017, at 11:09 AM, Mike Kluev via swift-evolution 
>  wrote:
> 
> 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?

Swift doesn’t have headers so this doesn’t really make sense here. The idea of 
a module is to be able to provide someone an immutable binary with a public 
interface. Someone consuming your code via a module won’t be able to modify the 
contents of that module and shouldn’t be able to access private methods of 
classes in that module or add new private fields or methods to classes in that 
module. I think we all agree on that. A module that your code uses is immutable 
to you.

But people who are building that module and already editing code within that 
module can and should be able to modify a class in that module any way they 
want. That should be obvious, right? That person can choose to directly edit 
the class in its main definition file, but (with partial classes as I’ve 
described) they could also choose to mark that class as partial and then add to 
it from a different swift file from within the same module. As a maintainer of 
that module there is absolutely nothing wrong with this. That’s why it’s 
important that this only be possible within that module.___
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] Logging facade

[Max Moiseev via swift-evolution]

Hi Maik,

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.

Max

> On Nov 1, 2017, at 4:44 AM, Maik Koslowski via swift-evolution 
>  wrote:
> 
> Hey!
> 
> I haven’t found anything in the history of this mail list about this topic.
> 
> What do you think about having a logging facade within the standard library 
> (like SLF in Java)?
> SLF4J is not within the standard library in Java, but it is well used and I’d 
> like to have something like that within the standard library to have a 
> standardized way for logging. This change would be purely additive.
> 
> - Maik
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

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

Re: [swift-evolution] [draft] Target environment platform condition

[Graydon Hoare via swift-evolution]

> On Oct 27, 2017, at 5:06 AM, Karl Wagner via swift-evolution 
>  wrote:
> 
> Yeah, but by extension, every since compile-time flag is also an “axis of 
> configuration”. What makes these few worthy of special language integration 
> and compiler support?

The "environment" field is an optional 4th component of the 
(not-quite-accurately-named) target-triple. This is not new, it's a thing lots 
of toolchains have some more-or-less standard support for (different toolchains 
use it for different purposes: simulator-ness, ABI, libc variation, etc.)

Swift's grammar for compilation conditions[1] provides three different types of 
leaf node:

  - Boolean literals
  - Identifiers, representing user-provided ("-D") command-line flags
  - Platform conditions, representing language version and 3 existing 
target-triple components

There's currently no way to write a compilation condition that depends on the 
4th field (environment) of the target-triple. This proposal is to surface that 
4th field in the same place the other 3 fields are surfaces: as a platform 
condition.

Conflated with this, the conversation in this thread seems to have ventured 
into asking -- independently of the question of how to express the environment 
field as a compilation condition -- whether it's right to express 
simulator-ness as a target-triple component at all, rather than as a 
preprocessor symbol. This ship has, however, already sailed: a patch expressing 
this choice entered LLVM a week ago[2], on the justification that the 
simulators are literally separate SDKs: from the perspective of the compiler, 
they're about as different as targeting different OSs.

-Graydon

[1] 
https://developer.apple.com/library/content/documentation/Swift/Conceptual/Swift_Programming_Language/Statements.html#//apple_ref/swift/grammar/compilation-condition
 

[2] https://reviews.llvm.org/D39143 

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

Re: [swift-evolution] “Integer” protocol?

[Xiaodi Wu via swift-evolution]

On Wed, Nov 1, 2017 at 07:24 Daryle Walker  wrote:

>
>
> Sent from my iPad
>
> On Oct 31, 2017, at 10:55 PM, Xiaodi Wu  wrote:
>
> Right, these issues were discussed when the proposal was introduced and
> reviewed three times. In brief, what was once proposed as `Integer` was
> renamed `BinaryInteger` to avoid confusion in name between `Integer` and
> `Int`. It was also found to better reflect the semantics of the protocol,
> as certain functions treated the value not merely as an integer but
> operated specifically on its binary representation (for instance, the
> bitwise operators).
>
> Do not confuse integers from their representation. Integers have no
> intrinsic radix and all integers have a binary representation. This is
> distinct from floating-point protocols, because many real values
> representable exactly as a decimal floating-point value cannot be
> represented exactly as a binary floating-point value.
>
>
> Abstractly, integers have representations in nearly all real radixes. But
> mandating base-2 properties for a numeric type that uses something else
> (ternary, negadecimal, non-radix, etc.) in its storage is definitely
> non-trivial. Hence the request for intermediate protocols that peel off the
> binary requirements.
>

Not only binary properties, but specifically two’s-complement binary
properties. You are correct that some operations require thought for
implementation if your type uses ternary storage, or for any type that does
not specifically use two’s-complement representation internally, but having
actually implemented them I can assure you it is not difficult to do
correctly without even a CS degree.

Again, one must distinguish between the actual representation in storage
and semantics, which is what Swift protocols guarantee. The protocols are
totally agnostic to the internal storage representation. The trade-off for
supporting ternary _semantics_ is an additional set of protocols which
complicates understanding and use in generic algorithms. I am not aware of
tritwise operations being sufficiently in demand.


> To your specific question about bitwise operators: their semantics are
> with respect to the two's-complement binary representation of the integer
> regardless of the actual internal representation. `~` returns the one's
> complement of the two's-complement binary representation of the integer.
> FWIW, this is exactly what `mpn_com()` does in GNU MP for
> arbitrary-precision integers.
>
>
> To continue your own analogy, integers by themselves don’t have radix (or
> reduced-radix) complements. The complements depend on a fixed width, since
> they’re based on Radix ** Width modulo arithmetic (or Radix ** Width - 1
> for the reduced-radix complement).
>
> 15 has a two’s complement under a binary representation with N bits (where
> N is at least 4). It has a ones’ complement too. Doing any complement of 15
> without an N is non-sensical; the result effectively would have an infinite
> number of ones at its beginning. I guess GNU-MP is stopping at the width of
> the original number’s storage, but that doesn’t make it right (although
> it’s more practical).  That’s why complements should be under the
> fixed-width protocols, not the general integer ones.
>

The two’s-complement representation of a negative number contains an
infinite number of leading zeros when the bit width is infinite. Bitwise
operators have consistent semantics with this definition. Neither GNU MP,
nor a conformant sign-magnitude arbitrary-width type in Swift, performs
actual bitwise operations on the internal storage, but returns the result
that would be obtained by performing those operations on the notionally
infinite two’s-complement binary representation of the integer, which is
not the internal storage representation.

The binary representation of 15 is 0b. For an infinite-width type, the
one’s complement is 0b1...1. That is the binary representation of -16.
So, `~15 as BigInt == -16`.

Again, one must distinguish semantics from representation. The bitwise
operators have two’s-complement semantics independent of internal
representation.

The very existence of BinaryInteger is proof of allowing protocols for
> types that don’t exist in the Standard Library (yet). (In other words, if
> protocols had to be justified with a current algorithm or type to be in the
> SL, then BinaryInteger should be purged since there’s no current type that
> uses it without using FixedWidthInteger too.) I just think the hierarchy
> needs a little more tweaking.
>

Yes, it’s meant to allow for an arbitrary-width integer type, a prototype
of which exists in the Swift repository. It is very much possible to write
such a type that conforms to all the requirements of BinaryInteger.


> On Tue, Oct 31, 2017 at 7:23 PM, Max Moiseev via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>> Just for the reference. There was a lengthy discussion here in the
>> mailing list back 

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

[Adam Kemp via swift-evolution]

> On Nov 1, 2017, at 8:54 AM, Zach Wolfe via swift-evolution 
>  wrote:
> 
> I like what this idea attempts to do, but have you thought of simply allowing 
> extensions of types within the same module to access private members and 
> declare stored properties?

The advantage of the extra keyword is that it makes it opt-in, which means you 
can know by looking at the class whether there are other places that have 
access to your private methods/fields/etc.

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

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

[Adam Kemp via swift-evolution]

> On Nov 1, 2017, at 8:28 AM, Mike Kluev  wrote:
> 
> name and ledger are essential in this proposal.
> 
> no name -> 
> no ledger (how to reference it?) -> 

What purpose does the “ledger" serve? I’m not sure what this even means.

> anyone can write parts of your class -> 

Anyone in the same module, but only if you explicitly declare your class as 
partial in the first place.

Impartial.swift:
class Impartial {}
Impartial.extra.swift:
partial class Impartial {} // error

Partial.swift:
partial class Partial {}
Partial.extra.swift:
partial class Partial {} // OK
Partial.othermodule.swift:
partial class Partial {} // Error

> 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

[Zach Wolfe via swift-evolution]

I like what this idea attempts to do, but have you thought of simply allowing 
extensions of types within the same module to access private members and 
declare stored properties? Adding a whole new construct to the language—while 
technically not source-breaking—would in practice change what is considered to 
be the idiomatic “Swifty” way of extending your own types, forcing people who 
care about such things to revisit their code for (imo) no good reason.

As a separate point, I’m strongly against the requirement that continuations be 
named and declared within the original type declaration or other continuations. 
As an optional categorization feature I’d be ok with it, but naming is hard, 
and forcing me to come up with a name every time I wish to isolate 
functionality of my types will push me away from doing it in the first place. 
Not to mention when I inevitably change one of my horrible continuation names, 
I will have to change it in two places (or more in the cross-platform example)!

Also on the naming point, you mention being able to refer to continuations by 
name. Can you give an example where that would be useful?
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[BJ Homer via swift-evolution]

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.

-BJ

> On Nov 1, 2017, at 9:28 AM, Mike Kluev via swift-evolution 
>  wrote:
> 
> 
> 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

___
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

[Adam Kemp via swift-evolution]

I don’t see why “parts” would need to be named. That seems overly complex for 
little benefit. 

> On Nov 1, 2017, at 7:43 AM, Mike Kluev via swift-evolution 
>  wrote:
> 
>> 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
___
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

[swift-evolution] [Potential Idea] How to indicate a trivial strong-typedef?

[Daryle Walker via swift-evolution]

Here’s a quick review of a strong-“typedef” idea I’ve mentioned here:

typecopy MyNewType: OriginalValueType, AnyProtocolsIWant {
// Direct member declarations
// “publish MemberFromOriginalType” for all overloads (or the singular item for 
non-functions)
// “publish MemberWithSignatureFromOriginalType” to pick out one subset of 
overloads
// “publish MemberWithSignatureAndParameterNamesFromOriginalType” to pick out 
one overload
// “publish ProtocolThatOriginalTypeConfromsTo"
}

(The name “typecopy” is changed from “alter”.)

All type-copies automatically conform to the new system AnyTypeCopy protocol, 
which derives from RawRepresentable. It just adds the “CoreRawValue” type. This 
type alias matches RawValue if that is a non-typecopy; otherwise it aliases 
that type copy’s CoreRawValue type. AnyTypeCopy cannot be added to non-typecopy 
types. Any protocol that derives from it can only be applied to typecopy types. 
 Type-copies are value types, and can only shadow structures, enumerations, 
other type-copies, tuples, and fixed-size arrays (if added).

The initializer used to conform to RawRepresentable is the type’s designated 
initializer. It’s the only one that can access “super.” Any other initializers 
added must be convenience and reference the designated one. (Published 
initializers are considered convenience.) The designated initializer can be 
fail-able to model subtypes. The designated initializer can pass on an altered 
value to model quotient types (or any other crazy mapping scheme); including 
being fail-able too (i.e. a quotient type of a subtype).

Of course, the designated initializer could do neither changes nor filtering:

typecopy MyResourceID: Int16, Hashable {
init(rawValue: RawValue) { super = rawValue }
publish Equatable
var hashValue: Int { get {return rawValue.hashValue & 0x01} }
}

Since every valid state of Int16 is also a valid state of MyResourceID, and 
without remapping, this type-copy is a trivial copy of its source. Besides 
downcasts (and cross-casts) never being fail-able, all sorts of other 
type-punning and related optimizations should be possible. (Upcasts are always 
trivial, even when the designated initializer isn’t.) We should be able to 
easily copy/type-pun between Array with Array, where T is 
either Int16 or another type-copy that (eventually) trivially shadows Int16. 
(Of course, this applies to Unsafe*Pointer or fixed-size arrays (if added) 
too.) These optimizations can’t be done with non-trivial type copies, since 
downcasts (and the downcast parts of cross-casts) need to have their designated 
initializers called for each element.

1. Now we get to the question in the Subject. Before now, I just wanted the 
compiler to see the definition of the designated initializer to determine if 
the type-copy is trivial or not. Now I realize that may have problems. One is 
that it may not be easy for the compiler to check if a given initializer 
matches the form I gave in the “MyResourceID” example. Another is that if the 
user prints out a prototype summary of the type, with members but without their 
definitions, s/he would have no idea if the type-copy was trivial or not.

I’m wondering if we should define trivial-ness with a keyword added to the 
definition:

typecopy MyResourceID1 trivial: Int16, Hashable {
// Initializer not given
publish Equatable
var hashValue: Int { get{return rawValue.hashValue & 0x01} }
}

typecopy MyResourceID2: Int16, Hashable {
trivial init(rawValue: RawValue)  // Looks incomplete, but it’s actually the 
full thing
publish Equatable
var hashValue: Int { get{return rawValue.hashValue & 0x01} }
}

typecopy MyResourceID3: Int16, Hashable {
init(rawValue: RawValue) = trivial
publish Equatable
var hashValue: Int { get{return rawValue.hashValue & 0x01} }
}

I kind-of like the look of the second, but it may be confusing to (new) users 
since there’s no code block after the initializer declaration. My next-liked 
look is the first one, but I’m not sure where the “trivial” should go (before 
“typecopy”, after it, current spot, or before the original type’s name after 
the colon). The third choice looks the weirdest to me, but it’s probably the 
easiest parsing-wise. It does remind me of the C++ class built-in 
life-management overrides.

(Now completing the post, maybe option 3 isn’t the easiest to parse. We go from 
“init” then Code-Block to “init” then either Code-Block or “= trivial”.)

For actual use, I’m leaning on placing “trivial” right before the original 
type’s name but after the colon. What does everyone else think?

1a. If “trivial” is added to the “typecopy” line, should explicitly defining a 
designated initializer anyway be banned? I’m leaning towards yes.

2. If no initializers are declared, either directly or with a publish, then a 
designated initializer is automatically added. It would have the same form as 
the one I gave in the example. If “trivial” goes inside the initializer’s 
declaration instead of the “typecopy” 

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

[Wallacy via swift-evolution]

Partial (like in C#) is good enough.

Em qua, 1 de nov de 2017 às 09:52, Mike Kluev via swift-evolution <
swift-evolution@swift.org> escreveu:

> 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
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] “Integer” protocol?

[Daryle Walker via swift-evolution]

Sent from my iPad

> On Oct 31, 2017, at 10:55 PM, Xiaodi Wu  wrote:
> 
> Right, these issues were discussed when the proposal was introduced and 
> reviewed three times. In brief, what was once proposed as `Integer` was 
> renamed `BinaryInteger` to avoid confusion in name between `Integer` and 
> `Int`. It was also found to better reflect the semantics of the protocol, as 
> certain functions treated the value not merely as an integer but operated 
> specifically on its binary representation (for instance, the bitwise 
> operators).
> 
> Do not confuse integers from their representation. Integers have no intrinsic 
> radix and all integers have a binary representation. This is distinct from 
> floating-point protocols, because many real values representable exactly as a 
> decimal floating-point value cannot be represented exactly as a binary 
> floating-point value.

Abstractly, integers have representations in nearly all real radixes. But 
mandating base-2 properties for a numeric type that uses something else 
(ternary, negadecimal, non-radix, etc.) in its storage is definitely 
non-trivial. Hence the request for intermediate protocols that peel off the 
binary requirements. 

> To your specific question about bitwise operators: their semantics are with 
> respect to the two's-complement binary representation of the integer 
> regardless of the actual internal representation. `~` returns the one's 
> complement of the two's-complement binary representation of the integer. 
> FWIW, this is exactly what `mpn_com()` does in GNU MP for arbitrary-precision 
> integers.

To continue your own analogy, integers by themselves don’t have radix (or 
reduced-radix) complements. The complements depend on a fixed width, since 
they’re based on Radix ** Width modulo arithmetic (or Radix ** Width - 1 for 
the reduced-radix complement). 

15 has a two’s complement under a binary representation with N bits (where N is 
at least 4). It has a ones’ complement too. Doing any complement of 15 without 
an N is non-sensical; the result effectively would have an infinite number of 
ones at its beginning. I guess GNU-MP is stopping at the width of the original 
number’s storage, but that doesn’t make it right (although it’s more 
practical).  That’s why complements should be under the fixed-width protocols, 
not the general integer ones. 

The very existence of BinaryInteger is proof of allowing protocols for types 
that don’t exist in the Standard Library (yet). (In other words, if protocols 
had to be justified with a current algorithm or type to be in the SL, then 
BinaryInteger should be purged since there’s no current type that uses it 
without using FixedWidthInteger too.) I just think the hierarchy needs a little 
more tweaking. 


> 
> On Tue, Oct 31, 2017 at 7:23 PM, Max Moiseev via swift-evolution 
>  wrote:
>> Just for the reference. There was a lengthy discussion here in the mailing 
>> list back when the proposal was introduced:
>> https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170109/thread.html#30191
>> 
>> Max
>> 
>>> On Oct 31, 2017, at 5:15 PM, Daryle Walker via swift-evolution 
>>>  wrote:
>>> 
>>> Looking at Apple’s Swift (4) docs at their SDK site, shouldn’t there be an 
>>> “Integer” protocol between Numeric and BinaryInteger? Without that, there’s 
>>> no solution for Integer types that are either a non-binary radix or a 
>>> non-radix system (besides being over-broad with Numeric).
>>> 
>>> What would move there are: isSigned, quotientAndRemainder, signum, %, %=, 
>>> /, and /=.
>>> 
>>> Also, how is ~ supposed to work in a BinaryInteger that is not a 
>>> FixedWidthInteger? Extend the high bits to infinity? Maybe that operator 
>>> should move to the derived protocol.
>>> 
>>> Oh, why can’t a non-binary Integer type be fixed-width? FixedWidthInteger 
>>> should be renamed “FixedWidthBinaryInteger,” which derives from 
>>> BinaryInteger and a new version of FixedWidthInteger. The new version peels 
>>> off: max, min, addingReportingOverflow, dividedReportingOverflow, 
>>> dividingFullWidth, multipliedFullWidth, multipliedReportingOverflow, 
>>> remainderReportingOverflow, and subtractingReportingOverflow. There’s also 
>>> a “digitWidth” type property, analogous to “bitWidth”.
>>> 
>>> Sent from my iPad
>>> ___
>>> swift-evolution mailing list
>>> swift-evolution@swift.org
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>> 
>> 
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>> 
> 
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] 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

[swift-evolution] Logging facade

[Maik Koslowski via swift-evolution]

Hey!

I haven’t found anything in the history of this mail list about this topic.

What do you think about having a logging facade within the standard library 
(like SLF in Java)?
SLF4J is not within the standard library in Java, but it is well used and I’d 
like to have something like that within the standard library to have a 
standardized way for logging. This change would be purely additive.

- Maik

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

Re: [swift-evolution] [Discussion] Swift for Data Science / ML / Big Data analytics

[Richard Wei via swift-evolution]

> On Nov 1, 2017, at 03:14, Richard Wei via swift-evolution 
>  wrote:
> 
> 
> 
>> On Oct 31, 2017, at 21:31, Chris Lattner via swift-evolution 
>> > wrote:
>> 
>> Also, for sake of discussion, we’d have to figure out what the type of 
>> MemberLookupResultType would be for Python.  I can see several choices:
>> 
>> 1) Make it return a  "PythonObject!”
>> 2) Make it strict, returning a PythonObject or trapping.
>> 3) Make PythonObject itself nullable internally and return a null 
>> PythonObject.
>> 
>> #1 matches Python semantics directly, because it allows clients who care to 
>> check, but those who don't can ignore it.  The only problem I anticipate is 
>> that it will break things like:
>> 
>> let x = foo.bar
>> let y = x.thing   // fails, because x implicitly promoted to PythonObject?
>>  
>> #3 is gross and cuts against lots of things in Swift (recall when 
>> UnsafePointer itself was implicitly nullable, lets not go back to those bad 
>> old days).  I think that #2 is the least bad tradeoff.
> 
> I agree, PythonObject-or-die is the right trade-off.
> 
>> 
>> Yes, something like this is what I had in mind, but I think that 
>> functionName should only be required to be StringLiteralConvertible (no need 
>> to actually synthesize a real swift string).
>> 
>> 
>> Since you bring it up, Python exceptions will be annoying - As with other 
>> languages, Python can throw from an arbitrary expression.  Modeling 
>> everything as throws in Swift would be super-annoying and unergonomic for 
>> the programmer, because we'd require 'try' everywhere.  Thoughts on what to 
>> do about that are welcome!
> 
> Requiring ‘try’ on every statement is annoying, but not having the ability to 
> catch python exceptions is annoying too. We could probably make python 
> exception handling an opt-in feature. For example:
> 
> try Python.do {
> let a = np.array([1, 2, 3])
> let b = np.array([[2], [4]])
> print(a.dot(b)) // matrix mul with incompatible shapes
> }
> catch let error as PythonException {
> // Handle PythonError.valueError(“objects are not aligned”)
> }

To correct my example: 

do { 
try Python.do {
let a = np.array([1, 2, 3])
let b = np.array([[2], [4]])
print(a.dot(b)) // matrix mul with incompatible shapes
}
}
catch let error as PythonException {
// Handle PythonError.valueError(“objects are not aligned”)
}

Maybe ‘Python.do {}’ should be called something like ‘Python.safely {}’.

-Richard

> 
> Python.do enables exception handling for statements in the body, declared as
> func `do`(_ body: () throws -> T) throws -> T
> 
> When we execute python-throwing statements inside a Python.do{}, 
> PythonException gets thrown. Otherwise, it traps.
> 
> The ‘Python.do’ function would ask the python overlay to enter an 
> "error-catching" state when executing the body closure. We make PythonObjects 
> internally nullable, but guarantee that they are non-null (or trap) when the 
> overlay is not in the “error-caught” state. When a python exception is thrown 
> in the error-catching state, the overlay enters the error-caught state and 
> propagates null through any python computation in the body closure. After the 
> body is executed, throw that python exception.
> 
> However, if there’s a throwing Swift statement after the throwing python 
> statement in the body, the python exception won’t be caught first… So having 
> the body as a non-throwing closure may be a better idea.
> 
> -Richard
> 
>> 
>>> 
>>> class Dog:
>>> 
>>> def __init__(self, name):
>>> self.name = name
>>> self.tricks = []# creates a new empty list for each dog
>>> 
>>> def add_trick(self, trick):
>>> self.tricks.append(trick)
>>> 
>>> With your don’t-modify-the-compiler approach, how can I create a Dog 
>>> instance and add a trick? I probably need to look up the class by name, 
>>> call __init__ manually, etc.
>>> 
>>>   let dogClass = python_getClassByName(“Dog”) // implemented in the Python 
>>> “overlay’, I guess
>>>   let dog = python_createInstance(dogClass)  // implemented in the Python 
>>> “overlay’, I guess
>>>   dog.__init__(“Brianna”)  // uses CustomCallable’s callMember
>>>   dog.add_trick(“Roll over”)  // uses CustomCallable’s callMember
>> 
>> I-am-not-a-python-expert, but I'd expect this to work:
>> 
>>  let dogModule = Python.import("DogModule")
>>  dogModule.Dog("jckarter").add_trick("SILGenGen”)
>>  let dog = dogModule.Dog(“Brianna”)
>>  dog.add_trick(“Roll over)
>> 
>> or equivalently:
>> 
>>  let Dog = Python.import(“DogModule.Dog")
>>  Dog("jckarter").add_trick("SILGenGen”)
>>  let dog = Dog(“Brianna”)
>>  dog.add_trick(“Roll over)
>> 
>> Seems pretty nice to me, with zero “Swift compiler knowledge of Python” 
>> required.
>> 
>> 
>>> With compiler integration, 
>>> 
>>> class Dog : PythonObject {
>>>   init(_ 

Re: [swift-evolution] [Discussion] Swift for Data Science / ML / Big Data analytics

[Richard Wei via swift-evolution]

> On Oct 31, 2017, at 21:31, Chris Lattner via swift-evolution 
>  wrote:
> 
> Also, for sake of discussion, we’d have to figure out what the type of 
> MemberLookupResultType would be for Python.  I can see several choices:
> 
> 1) Make it return a  "PythonObject!”
> 2) Make it strict, returning a PythonObject or trapping.
> 3) Make PythonObject itself nullable internally and return a null 
> PythonObject.
> 
> #1 matches Python semantics directly, because it allows clients who care to 
> check, but those who don't can ignore it.  The only problem I anticipate is 
> that it will break things like:
> 
> let x = foo.bar
> let y = x.thing   // fails, because x implicitly promoted to PythonObject?
>  
> #3 is gross and cuts against lots of things in Swift (recall when 
> UnsafePointer itself was implicitly nullable, lets not go back to those bad 
> old days).  I think that #2 is the least bad tradeoff.

I agree, PythonObject-or-die is the right trade-off.

> 
> Yes, something like this is what I had in mind, but I think that functionName 
> should only be required to be StringLiteralConvertible (no need to actually 
> synthesize a real swift string).
> 
> 
> Since you bring it up, Python exceptions will be annoying - As with other 
> languages, Python can throw from an arbitrary expression.  Modeling 
> everything as throws in Swift would be super-annoying and unergonomic for the 
> programmer, because we'd require 'try' everywhere.  Thoughts on what to do 
> about that are welcome!

Requiring ‘try’ on every statement is annoying, but not having the ability to 
catch python exceptions is annoying too. We could probably make python 
exception handling an opt-in feature. For example:

try Python.do {
let a = np.array([1, 2, 3])
let b = np.array([[2], [4]])
print(a.dot(b)) // matrix mul with incompatible shapes
}
catch let error as PythonException {
// Handle PythonError.valueError(“objects are not aligned”)
}

Python.do enables exception handling for statements in the body, declared as
func `do`(_ body: () throws -> T) throws -> T

When we execute python-throwing statements inside a Python.do{}, 
PythonException gets thrown. Otherwise, it traps.

The ‘Python.do’ function would ask the python overlay to enter an 
"error-catching" state when executing the body closure. We make PythonObjects 
internally nullable, but guarantee that they are non-null (or trap) when the 
overlay is not in the “error-caught” state. When a python exception is thrown 
in the error-catching state, the overlay enters the error-caught state and 
propagates null through any python computation in the body closure. After the 
body is executed, throw that python exception.

However, if there’s a throwing Swift statement after the throwing python 
statement in the body, the python exception won’t be caught first… So having 
the body as a non-throwing closure may be a better idea.

-Richard

> 
>> 
>> class Dog:
>> 
>> def __init__(self, name):
>> self.name = name
>> self.tricks = []# creates a new empty list for each dog
>> 
>> def add_trick(self, trick):
>> self.tricks.append(trick)
>> 
>> With your don’t-modify-the-compiler approach, how can I create a Dog 
>> instance and add a trick? I probably need to look up the class by name, call 
>> __init__ manually, etc.
>> 
>>   let dogClass = python_getClassByName(“Dog”) // implemented in the Python 
>> “overlay’, I guess
>>   let dog = python_createInstance(dogClass)  // implemented in the Python 
>> “overlay’, I guess
>>   dog.__init__(“Brianna”)  // uses CustomCallable’s callMember
>>   dog.add_trick(“Roll over”)  // uses CustomCallable’s callMember
> 
> I-am-not-a-python-expert, but I'd expect this to work:
> 
>   let dogModule = Python.import("DogModule")
>   dogModule.Dog("jckarter").add_trick("SILGenGen”)
>   let dog = dogModule.Dog(“Brianna”)
>   dog.add_trick(“Roll over)
> 
> or equivalently:
> 
>   let Dog = Python.import(“DogModule.Dog")
>   Dog("jckarter").add_trick("SILGenGen”)
>   let dog = Dog(“Brianna”)
>   dog.add_trick(“Roll over)
> 
> Seems pretty nice to me, with zero “Swift compiler knowledge of Python” 
> required.
> 
> 
>> With compiler integration, 
>> 
>>  class Dog : PythonObject {
>>init(_ name: Pythonable)
>>func add_trick(_ trick: Pythonable)
>>  }
> 
> Something like this is possible, but would be substantially more work, be 
> substantially more invasive, and would set the precedent that every other 
> dynamic language would get support hacked directly into Swift.  The only 
> reason I can see this being useful is if we wanted to support the optional 
> typing annotations in Python.  While this would be "nice to have", I think 
> the cost/benefit tradeoff involved is totally wrong for Swift. 
> 
>> With either the true “Python importer” solution or this code-generation 
>> solution, you at least get some level of code 

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

[Eagle Offshore via swift-evolution]

"Continuation" already means something else in computer programming.  I would 
suggest you find another term.

https://en.wikipedia.org/wiki/Continuation


> On Oct 30, 2017, at 6:12 PM, Mike Kluev via swift-evolution 
>  wrote:
> 
> 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

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