Re: [swift-evolution] Import Conditionals

[Benjamin Spratling via swift-evolution]

Howdy,

There is already an accepted but not implemented proposal to determine whether 
a module can be imported and conditionally compile accordingly.
https://github.com/apple/swift-evolution/blob/master/proposals/0075-import-test.md

While the accepted change is certainly not as compact as your notation, it has 
the advantage that it supports more functionality.  I could, for example, 
include code in a file for UIKit, Cocoa, WatchKit and ostensibly some Linux UI 
framework depending on my target platform.  If my functionality is intended 
around adding a single consistent feature to a Type in each module, then this 
is how I want to organize my code.

Besides, “||” is so JavaScript.  In Swift it would be “??”, and it would 
potentially need to chain because there are more than 2 supported platforms.

Finally, I don’t see how you handle failure to import a module.  Does compile 
fail, or do you provide your own implementation of the desired functionality?  
When Apple adds a module on one platform but not on another, then I might need 
to write my own implementation for platforms on which it is missing, but depend 
on system integrated performance on the platforms they provide it for.  
“canimport” provides for either using other existing # patterns, but your 
proposal does not.

So I recommend checking out the already-accepted proposal.  But if you still 
need the syntax to get smaller, at least move to “??” so it looks like Swift 
instead of some other language.

-Ben


> On Oct 17, 2016, at 5:05 PM, Sean Alling via swift-evolution 
>  wrote:
> 
> Description
> 
> In an effort to both (1) reduce boilerplate code, and (2) promote 
> cross-platform reusability I propose that we implement the following Import 
> Conditional Operators: 
> 
> `||` and `&&`
> 
> Currently, import conditionals must be implemented like so:
> 
> ```
> #if os(Linux) || os(FreeBSD)
>   import Glibc
> #else
>   import Darwin
> #endif
> ```
> 
> With import conditional operators this would be condensed to:
> 
> ```
> import Glibc || Darwin
> ```
> 
> The first library/framework (Glibc) would be imported if found and the the 
> second (Darwin) only in the event the first should fail.
> 
> Other Caveats:
> 
> (A) —  we could limit this to one conditional operator per import line OR we 
> could implement order of operations. Obviously, there are tradeoffs of both 
> that we should discuss.
> 
> (B) — if-conditional statements currently explicitly show the import 
> conditions (i.e., os(Linux) || os(FreeBSD)) this would be a detriment to this 
> new feature. I would argue that the reduction of boilerplate code would in 
> itself be worth this abstraction.
> 
> 
> --
> Sean Alling
> 
> ___
> 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] [Review] SE-0144: Allow Single Dollar Sign as a Valid Identifier

[Rien via swift-evolution]

“culturally offensive” is not a logical argument.
A programming language should be logically consistent no matter how many 
cultures are offended by it.
If Swift is driven by SJW’s then very quickly it will cease to be an effective 
language.

Having said that, I cannot think of a logical reason not to allow the $ as a 
variable name.
I also cannot think of a good reason to use a single character variable name. 
Let alone a symbol. Let even further alone a symbol that is used in many other 
languages for a specific purpose.

So while Swift may allow the $ sign for logical consistency, using it as a 
variable name would disqualify the programmer imo.

Rien.

> On 18 Oct 2016, at 08:25, Jean-Denis Muys via swift-evolution 
>  wrote:
> 
> While I already tersely supported this proposal, following all the negative 
> reactions, I feel compelled to revisit my position. The main reason is that 
> it strikes me that most points of view so far, including mine, were really 
> culturally short sighted, and far too much US-centric.
> 
> I totally agree that '$' being use by one (or even several) piece of code is 
> not reason enough to change the language. But I also think that it being used 
> by only one piece of code is no reason to reject the change.
> 
> Most of us, including me, have been blinded by two things:
> 
> 1- the use of the $ sign in other programming languages
> 2- the use of the $ sign in Swift as a prefix for implicitly declared closure 
> parameters
> 
> I think this second use is not Swifty at all. It clearly (to me) would fail 
> the litmus test "if it wasn't there, would you add it to the language?". Of 
> course, it has been blessed by time, and it has *become* Swifty, by usage 
> because it's a useful feature, despite the choice of its syntax being so ugly 
> (to my non-american eyes).
> 
> Similarly, I believe the use of the $ in other language should not be a guide 
> in the decision here, either positively, nor negatively. We may pay some mild 
> attention to the concern that we should perhaps avoid some confusion. I 
> haven't seen much of that.
> 
> Now for the elephant in the room: '$' is a currency symbol. As such it should 
> be handled like any other currency symbol. Thinking otherwise would be very 
> culturally offensive.
> 
> So can I use € as an variable name in Swift? According to Xcode 8.1B3, yes.
> Can I use any currency symbol as an variable name in Swift? According to 
> Xcode 8.1B3, not quite, but almost all of them.
> 
> According to Mac OS "Emoji and Symbols" browser, there are 37 currency 
> symbols in Unicode:
> 
> let currencyAndSymbols = "$€¥¢£₽₨₩฿₺₮₱₭₴₦৲৳૱௹﷼₹₲₪₡₫៛₵₢₸₤₳₥₠₣₰₧₯₶"
> I tried every one of them as a variable name. All were accepted, except 3: ¥, 
> ¢, £:
> 
> // let ¥ = 1 // error: expected pattern
> 
> Note the poor error message.
> 
> Here are 33 successful attempts:
> 
> let $ = 1
> let € = 1
> let ₽ = 1
> let ₨ = 1
> let ₩ = 1
> let ฿ = 1
> let ₺ = 1
> let ₮ = 1
> let ₱ = 1
> let ₭ = 1
> let ₴ = 1
> let ₦ = 1
> let ৲ = 1
> let ৳ = 1
> let ૱ = 1
> let ௹ = 1
> let ₹ = 1
> let ₲ = 1
> let ₪ = 1
> let ₡ = 1
> let ₫ = 1
> let ៛ = 1
> let ₵ = 1
> let ₢ = 1
> let ₸ = 1
> let ₤ = 1
> let ₳ = 1
> let ₥ = 1
> let ₠ = 1
> let ₣ = 1
> let ₰ = 1
> let ₧ = 1
> let ₯ = 1
> let ₶ = 1
> 
> print("₶ = \(₶)")
> print(₶+₶+₶)
> 
> And finally, there is the very weird Rial Sign: ﷼
> It is ok to use it as an variable name too (again, according to Xcode8.1B3).
> But when trying to use it, Xcode switches to right-to-left mode, which makes 
> for strange (for my occidental eyes) behaviour and display. All the following 
> is OK in Xcode:
> 
> // unusual Xcode right-to-left behavior with Rial Sign
> let ﷼ = 21
> 
> print("﷼= \(﷼)") // will print ﷼= 21
> 
> Of course, this is just a data point, and Xcode8.1B3 should not be the 
> arbiter here. But I believe whether Swift accepts currency symbols as 
> variable names should be consistent. Either it accepts all of them, or it 
> includes all of them.
> 
> I see no reason to exclude them. On the contrary, it was a design feature of 
> Swift to relieve use from the shackles of the ASCII character set.
> 
> In conclusion, I believe this proposal must be accepted, and actually 
> expanded to include ¥, ¢, £, and also to make it explicit that currency 
> symbols can be used in variable names as first and only character, as first 
> of many characters, and at any position.
> 
> This would make $0, $1, $2… legal variable names. I believe this is OK.
> 
> What would happen to implicitly declared closure parameters then? Nothing. 
> They would continue to be implicitly declared in the context of closures that 
> do not declare their parameters explicitly, similarly to `self` being 
> implicitly declared in the context of a class. A user willing to use $0 there 
> would be facing a name collision, which is OK. 
> 
> Note that such a change is purely additive: no legal source code today would 
> fail with this change.
> 
> I hope that at the v

Re: [swift-evolution] [Review] SE-0144: Allow Single Dollar Sign as a Valid Identifier

[Jean-Denis Muys via swift-evolution]

While I already tersely supported this proposal, following all the negative
reactions, I feel compelled to revisit my position. The main reason is that
it strikes me that most points of view so far, including mine, were really
culturally short sighted, and far too much US-centric.

I totally agree that '$' being use by one (or even several) piece of code
is not reason enough to change the language. But I also think that it being
used by only one piece of code is no reason to reject the change.

Most of us, including me, have been blinded by two things:

1- the use of the $ sign in other programming languages
2- the use of the $ sign in Swift as a prefix for implicitly declared
closure parameters

I think this second use is not Swifty at all. It clearly (to me) would fail
the litmus test "if it wasn't there, would you add it to the language?". Of
course, it has been blessed by time, and it has *become* Swifty, by usage
because it's a useful feature, despite the choice of its syntax being so
ugly (to my non-american eyes).

Similarly, I believe the use of the $ in other language should not be a
guide in the decision here, either positively, nor negatively. We may pay
some mild attention to the concern that we should perhaps avoid some
confusion. I haven't seen much of that.

Now for the elephant in the room: '$' is a currency symbol. As such it
should be handled like any other currency symbol. Thinking otherwise would
be very culturally offensive.

So can I use € as an variable name in Swift? According to Xcode 8.1B3, yes.
Can I use any currency symbol as an variable name in Swift? According to
Xcode 8.1B3, not quite, but almost all of them.

According to Mac OS "Emoji and Symbols" browser, there are 37 currency
symbols in Unicode:

let currencyAndSymbols = "$€¥¢£₽₨₩฿₺₮₱₭₴₦৲৳૱௹﷼₹₲₪₡₫៛₵₢₸₤₳₥₠₣₰₧₯₶"
I tried every one of them as a variable name. All were accepted, except 3:
¥, ¢, £:

// let ¥ = 1 // error: expected pattern

Note the poor error message.

Here are 33 successful attempts:

let $ = 1

let € = 1

let ₽ = 1

let ₨ = 1

let ₩ = 1

let ฿ = 1

let ₺ = 1

let ₮ = 1

let ₱ = 1

let ₭ = 1

let ₴ = 1

let ₦ = 1

let ৲ = 1

let ৳ = 1

let ૱ = 1

let ௹ = 1

let ₹ = 1

let ₲ = 1

let ₪ = 1

let ₡ = 1

let ₫ = 1

let ៛ = 1

let ₵ = 1

let ₢ = 1

let ₸ = 1

let ₤ = 1

let ₳ = 1

let ₥ = 1

let ₠ = 1

let ₣ = 1

let ₰ = 1

let ₧ = 1

let ₯ = 1

let ₶ = 1

print("₶ = \(₶)")

print(₶+₶+₶)

And finally, there is the very weird Rial Sign: ﷼
It is ok to use it as an variable name too (again, according to Xcode8.1B3).
But when trying to use it, Xcode switches to right-to-left mode, which
makes for strange (for my occidental eyes) behaviour and display. All the
following is OK in Xcode:

// unusual Xcode right-to-left behavior with Rial Sign

let ﷼ = 21


print("﷼= \(﷼)") // will print ﷼= 21

Of course, this is just a data point, and Xcode8.1B3 should not be the
arbiter here. But I believe whether Swift accepts currency symbols as
variable names should be consistent. Either it accepts all of them, or it
includes all of them.

I see no reason to exclude them. On the contrary, it was a design feature
of Swift to relieve use from the shackles of the ASCII character set.

In conclusion, I believe this proposal must be accepted, and actually
expanded to include ¥, ¢, £, and also to make it explicit that currency
symbols can be used in variable names as first and only character, as first
of many characters, and at any position.

This would make $0, $1, $2… legal variable names. I believe this is OK.

What would happen to implicitly declared closure parameters then? Nothing.
They would continue to be implicitly declared in the context of closures
that do not declare their parameters explicitly, similarly to `self` being
implicitly declared in the context of a class. A user willing to use $0
there would be facing a name collision, which is OK.

Note that such a change is purely additive: no legal source code today
would fail with this change.

I hope that at the very least, I opened a new perspective on this proposal,
and I hope we can find a way to be less culturally biased.

Jean-Denis

* What is your evaluation of the proposal?

+1. However, it should be expanded to include all Unicode currency symbols.

* Is the problem being addressed significant enough to warrant a
change to Swift?

Very much so, because it reveals a significant inconsistency in the way the
language handles characters for identifiers.

* Does this proposal fit well with the feel and direction of Swift?

Very much so, considering the language made a point to support unicode
characters in identifiers, and '$' should behave consistently with the
other Unicode currency symbols.

* If you have used other languages or libraries with a similar
feature, how do you feel that this proposal compares to those?

In the specific case, this is irrelevant. We are in territory only treaded
by Swift

* How much effort did you put int

Re: [swift-evolution] [pitch] "import" declaration, support for comma-separated modules

[Georgios Moschovitis via swift-evolution]

> I'd almost always prefer to have another three lines of a protocolvisible, 
> than three lines of imports. 

Maybe you just need an editor that can fold the imports (e.g. JetBrains)
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Import Conditionals

[Karl via swift-evolution]

I disagree. What about when you need to disambiguate?

Currently you’d need to use ‘Darwin.connect(...)’ or ‘Glibc.connect(…)’. 
Merging them both in to one ‘Libc’ module would make that much easier.

> On 18 Oct 2016, at 01:07, Sean Alling via swift-evolution 
>  wrote:
> 
> Yeah I saw that thread. I think (a) this is a better solution and (b) this is 
> applicable for use cases other than specifically Glibc/Darwin.
> 
> -Sean
> 
> Sent from my iPhone
> 
> On Oct 17, 2016, at 19:01, Saagar Jha  > wrote:
> 
>> I believe there was a draft to merge all the "Libc" modules; let me see if I 
>> can find that.
>> 
>> On Mon, Oct 17, 2016 at 3:06 PM Sean Alling via swift-evolution 
>> mailto:swift-evolution@swift.org>> wrote:
>> Description
>> 
>> In an effort to both (1) reduce boilerplate code, and (2) promote 
>> cross-platform reusability I propose that we implement the following Import 
>> Conditional Operators: 
>> 
>> `||` and `&&`
>> 
>> Currently, import conditionals must be implemented like so:
>> 
>> ```
>> #if os(Linux) || os(FreeBSD)
>>  import Glibc
>> #else
>>  import Darwin
>> #endif
>> ```
>> 
>> With import conditional operators this would be condensed to:
>> 
>> ```
>> import Glibc || Darwin
>> ```
>> 
>> The first library/framework (Glibc) would be imported if found and the the 
>> second (Darwin) only in the event the first should fail.
>> 
>> Other Caveats:
>> 
>> (A) —  we could limit this to one conditional operator per import line OR we 
>> could implement order of operations. Obviously, there are tradeoffs of both 
>> that we should discuss.
>> 
>> (B) — if-conditional statements currently explicitly show the import 
>> conditions (i.e., os(Linux) || os(FreeBSD)) this would be a detriment to 
>> this new feature. I would argue that the reduction of boilerplate code would 
>> in itself be worth this abstraction.
>> 
>> 
>> --
>> Sean Alling
>> 
>> ___
>> 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] Import Conditionals

[Sean Alling via swift-evolution]

Yeah I saw that thread. I think (a) this is a better solution and (b) this is 
applicable for use cases other than specifically Glibc/Darwin.

-Sean

Sent from my iPhone

> On Oct 17, 2016, at 19:01, Saagar Jha  wrote:
> 
> I believe there was a draft to merge all the "Libc" modules; let me see if I 
> can find that.
> 
>> On Mon, Oct 17, 2016 at 3:06 PM Sean Alling via swift-evolution 
>>  wrote:
>> Description
>> 
>> In an effort to both (1) reduce boilerplate code, and (2) promote 
>> cross-platform reusability I propose that we implement the following Import 
>> Conditional Operators: 
>> 
>> `||` and `&&`
>> 
>> Currently, import conditionals must be implemented like so:
>> 
>> ```
>> #if os(Linux) || os(FreeBSD)
>>  import Glibc
>> #else
>>  import Darwin
>> #endif
>> ```
>> 
>> With import conditional operators this would be condensed to:
>> 
>> ```
>> import Glibc || Darwin
>> ```
>> 
>> The first library/framework (Glibc) would be imported if found and the the 
>> second (Darwin) only in the event the first should fail.
>> 
>> Other Caveats:
>> 
>> (A) —  we could limit this to one conditional operator per import line OR we 
>> could implement order of operations. Obviously, there are tradeoffs of both 
>> that we should discuss.
>> 
>> (B) — if-conditional statements currently explicitly show the import 
>> conditions (i.e., os(Linux) || os(FreeBSD)) this would be a detriment to 
>> this new feature. I would argue that the reduction of boilerplate code would 
>> in itself be worth this abstraction.
>> 
>> 
>> --
>> Sean Alling
>> 
>> ___
>> 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] Import Conditionals

[Saagar Jha via swift-evolution]

I believe there was a draft to merge all the "Libc" modules; let me see if
I can find that.

On Mon, Oct 17, 2016 at 3:06 PM Sean Alling via swift-evolution <
swift-evolution@swift.org> wrote:

> *Description*
>
> In an effort to both (1) reduce boilerplate code, and (2) promote
> cross-platform reusability I propose that we implement the following *Import
> Conditional Operators*:
>
> *`||` *and `*&&`*
>
> Currently, import conditionals must be implemented like so:
>
> ```
> #if os(Linux) || os(FreeBSD)
> import Glibc
> #else
> import Darwin
> #endif
> ```
>
> With *import conditional operators* this would be condensed to:
>
> ```
> import Glibc || Darwin
> ```
>
> The first library/framework (Glibc) would be imported if found and the the
> second (Darwin) only in the event the first should fail.
>
> *Other Caveats:*
>
> *(A) —  *we could limit this to one conditional operator per import line
> OR we could implement order of operations. Obviously, there are tradeoffs
> of both that we should discuss.
>
> *(B) —* if-conditional statements currently explicitly show the import
> conditions (i.e., os(Linux) || os(FreeBSD)) this would be a detriment to
> this new feature. I would argue that the reduction of boilerplate code
> would in itself be worth this abstraction.
>
>
> --
> Sean Alling
>
> ___
> 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] Import Conditionals

[Sean Alling via swift-evolution]

Description

In an effort to both (1) reduce boilerplate code, and (2) promote 
cross-platform reusability I propose that we implement the following Import 
Conditional Operators: 

`||` and `&&`

Currently, import conditionals must be implemented like so:

```
#if os(Linux) || os(FreeBSD)
import Glibc
#else
import Darwin
#endif
```

With import conditional operators this would be condensed to:

```
import Glibc || Darwin
```

The first library/framework (Glibc) would be imported if found and the the 
second (Darwin) only in the event the first should fail.

Other Caveats:

(A) —  we could limit this to one conditional operator per import line OR we 
could implement order of operations. Obviously, there are tradeoffs of both 
that we should discuss.

(B) — if-conditional statements currently explicitly show the import conditions 
(i.e., os(Linux) || os(FreeBSD)) this would be a detriment to this new feature. 
I would argue that the reduction of boilerplate code would in itself be worth 
this abstraction.


--
Sean Alling

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

Re: [swift-evolution] Why doesn't removeLast() on Collection return an optional?

[Louis D'hauwe via swift-evolution]

I understand, pull request has been made. 
https://github.com/apple/swift/pull/5333 


> On 17 Oct 2016, at 23:20, Max Moiseev  wrote:
> 
> Hi Louis,
> 
> I believe, sometimes there are situations where you know for sure that your 
> collection is not empty. Maybe you are already in the context where the check 
> has been performed. In these cases there is no reason you’d have to pay the 
> price of an emptiness check once again.
> 
> Perhaps, it should be documented better, as in “popLast should generally be 
> preferred since it is safer to use. You should only opt for the removeLast if 
> you are certain the collection is not empty and performance is an issue”.
> 
> If you agree, mind sending us a pull request with such a documentation change?
> 
> Thanks!
> Max
> 
>> On Oct 17, 2016, at 2:19 PM, Louis D'hauwe > > wrote:
>> 
>> I see, the really issue I'm trying to bring up is that removeLast() can 
>> easily fail (and result in a fatal error).
>> And unless you read the documentation, that's not very obvious.
>> 
>> Maybe another approach would be to make removeLast() throw an exception if 
>> the collection is empty?
>> That way you can use "try" to safely remove the last item of a collection.
>> 
>> The reasoning behind this is that right now, to safely use removeLast(), you 
>> pretty much have to do something like this:
>> if !collection.isEmpty {
>>  collection.removeLast()
>> }
>> 
>> Having this method throw would allow to change the above to:
>> try collection.removeLast()
>> 
>> – Louis D'hauwe
>> 
>>> On 17 Oct 2016, at 22:52, Max Moiseev >> > wrote:
>>> 
>>> You can use popLast, that does exactly that: 
>>> https://github.com/apple/swift/blob/master/stdlib/public/core/BidirectionalCollection.swift#L213
>>>  
>>> 
>>> 
>>> Max
>>> 
 On Oct 17, 2016, at 1:14 PM, Louis D'hauwe via swift-evolution 
 mailto:swift-evolution@swift.org>> wrote:
 
 Regarding the removeLast() function on Collection:
 
 The current implementation 
 
  is:
 @discardableResult
 public mutating func removeLast() -> Iterator.Element {
let element = last!
self = self[startIndex..>>>return element
 }
 
 This makes it so that if you call removeLast() on an empty collection you 
 get a fatal error.
 ("fatal error: can't remove last element from an empty collection")
 
 The documentation for removeLast() 
 
  even has this noted:
 "The collection must not be empty.".
 
 Surely you could just remove the explicit unwrapping of 'last' and add a 
 guard statement? 
 
 As such:
 @discardableResult
 public mutating func removeLast() -> Iterator.Element? {
guard let element = last else {
return nil
}
self = self[startIndex..>>>return element
 }
 
 It sure seems more "Swifty" to alert at compile time that removing the 
 last item of a collection might fail, and make it return nil as a result.
 
 – Louis D'hauwe
 
 ___
 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] Why doesn't removeLast() on Collection return an optional?

[Max Moiseev via swift-evolution]

Hi Louis,

I believe, sometimes there are situations where you know for sure that your 
collection is not empty. Maybe you are already in the context where the check 
has been performed. In these cases there is no reason you’d have to pay the 
price of an emptiness check once again.

Perhaps, it should be documented better, as in “popLast should generally be 
preferred since it is safer to use. You should only opt for the removeLast if 
you are certain the collection is not empty and performance is an issue”.

If you agree, mind sending us a pull request with such a documentation change?

Thanks!
Max

> On Oct 17, 2016, at 2:19 PM, Louis D'hauwe  wrote:
> 
> I see, the really issue I'm trying to bring up is that removeLast() can 
> easily fail (and result in a fatal error).
> And unless you read the documentation, that's not very obvious.
> 
> Maybe another approach would be to make removeLast() throw an exception if 
> the collection is empty?
> That way you can use "try" to safely remove the last item of a collection.
> 
> The reasoning behind this is that right now, to safely use removeLast(), you 
> pretty much have to do something like this:
> if !collection.isEmpty {
>   collection.removeLast()
> }
> 
> Having this method throw would allow to change the above to:
> try collection.removeLast()
> 
> – Louis D'hauwe
> 
>> On 17 Oct 2016, at 22:52, Max Moiseev > > wrote:
>> 
>> You can use popLast, that does exactly that: 
>> https://github.com/apple/swift/blob/master/stdlib/public/core/BidirectionalCollection.swift#L213
>>  
>> 
>> 
>> Max
>> 
>>> On Oct 17, 2016, at 1:14 PM, Louis D'hauwe via swift-evolution 
>>> mailto:swift-evolution@swift.org>> wrote:
>>> 
>>> Regarding the removeLast() function on Collection:
>>> 
>>> The current implementation 
>>> 
>>>  is:
>>> @discardableResult
>>> public mutating func removeLast() -> Iterator.Element {
>>> let element = last!
>>> self = self[startIndex..>> return element
>>> }
>>> 
>>> This makes it so that if you call removeLast() on an empty collection you 
>>> get a fatal error.
>>> ("fatal error: can't remove last element from an empty collection")
>>> 
>>> The documentation for removeLast() 
>>> 
>>>  even has this noted:
>>> "The collection must not be empty.".
>>> 
>>> Surely you could just remove the explicit unwrapping of 'last' and add a 
>>> guard statement? 
>>> 
>>> As such:
>>> @discardableResult
>>> public mutating func removeLast() -> Iterator.Element? {
>>> guard let element = last else {
>>> return nil
>>> }
>>> self = self[startIndex..>> return element
>>> }
>>> 
>>> It sure seems more "Swifty" to alert at compile time that removing the last 
>>> item of a collection might fail, and make it return nil as a result.
>>> 
>>> – Louis D'hauwe
>>> 
>>> ___
>>> 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] Why doesn't removeLast() on Collection return an optional?

[Louis D'hauwe via swift-evolution]

I see, the really issue I'm trying to bring up is that removeLast() can easily 
fail (and result in a fatal error).
And unless you read the documentation, that's not very obvious.

Maybe another approach would be to make removeLast() throw an exception if the 
collection is empty?
That way you can use "try" to safely remove the last item of a collection.

The reasoning behind this is that right now, to safely use removeLast(), you 
pretty much have to do something like this:
if !collection.isEmpty {
collection.removeLast()
}

Having this method throw would allow to change the above to:
try collection.removeLast()

– Louis D'hauwe

> On 17 Oct 2016, at 22:52, Max Moiseev  wrote:
> 
> You can use popLast, that does exactly that: 
> https://github.com/apple/swift/blob/master/stdlib/public/core/BidirectionalCollection.swift#L213
>  
> 
> 
> Max
> 
>> On Oct 17, 2016, at 1:14 PM, Louis D'hauwe via swift-evolution 
>> mailto:swift-evolution@swift.org>> wrote:
>> 
>> Regarding the removeLast() function on Collection:
>> 
>> The current implementation 
>> 
>>  is:
>> @discardableResult
>> public mutating func removeLast() -> Iterator.Element {
>>  let element = last!
>>  self = self[startIndex..>  return element
>> }
>> 
>> This makes it so that if you call removeLast() on an empty collection you 
>> get a fatal error.
>> ("fatal error: can't remove last element from an empty collection")
>> 
>> The documentation for removeLast() 
>> 
>>  even has this noted:
>> "The collection must not be empty.".
>> 
>> Surely you could just remove the explicit unwrapping of 'last' and add a 
>> guard statement? 
>> 
>> As such:
>> @discardableResult
>> public mutating func removeLast() -> Iterator.Element? {
>>  guard let element = last else {
>>  return nil
>>  }
>>  self = self[startIndex..>  return element
>> }
>> 
>> It sure seems more "Swifty" to alert at compile time that removing the last 
>> item of a collection might fail, and make it return nil as a result.
>> 
>> – Louis D'hauwe
>> 
>> ___
>> 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] Why doesn't removeLast() on Collection return an optional?

[Dave Abrahams via swift-evolution]

on Mon Oct 17 2016, Louis D'hauwe  wrote:

> Regarding the removeLast() function on Collection:
>
> The current implementation
> 
> is:
> @discardableResult
> public mutating func removeLast() -> Iterator.Element {
>   let element = last!
>   self = self[startIndex..   return element
> }
>
> This makes it so that if you call removeLast() on an empty collection you get 
> a fatal error.
> ("fatal error: can't remove last element from an empty collection")
>
> The documentation for removeLast()
> 
> even has this noted:
> "The collection must not be empty.".
>
> Surely you could just remove the explicit unwrapping of 'last' and add a 
> guard statement? 
>
> As such:
> @discardableResult
> public mutating func removeLast() -> Iterator.Element? {
>   guard let element = last else {
>   return nil
>   }
>   self = self[startIndex..   return element
> }
>
> It sure seems more "Swifty" to alert at compile time that removing the last 
> item of a collection
> might fail, and make it return nil as a result.

see the popLast() method.

-- 
-Dave

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

Re: [swift-evolution] Why doesn't removeLast() on Collection return an optional?

[Max Moiseev via swift-evolution]

You can use popLast, that does exactly that: 
https://github.com/apple/swift/blob/master/stdlib/public/core/BidirectionalCollection.swift#L213
 


Max

> On Oct 17, 2016, at 1:14 PM, Louis D'hauwe via swift-evolution 
>  wrote:
> 
> Regarding the removeLast() function on Collection:
> 
> The current implementation 
> 
>  is:
> @discardableResult
> public mutating func removeLast() -> Iterator.Element {
>   let element = last!
>   self = self[startIndex..   return element
> }
> 
> This makes it so that if you call removeLast() on an empty collection you get 
> a fatal error.
> ("fatal error: can't remove last element from an empty collection")
> 
> The documentation for removeLast() 
> 
>  even has this noted:
> "The collection must not be empty.".
> 
> Surely you could just remove the explicit unwrapping of 'last' and add a 
> guard statement? 
> 
> As such:
> @discardableResult
> public mutating func removeLast() -> Iterator.Element? {
>   guard let element = last else {
>   return nil
>   }
>   self = self[startIndex..   return element
> }
> 
> It sure seems more "Swifty" to alert at compile time that removing the last 
> item of a collection might fail, and make it return nil as a result.
> 
> – Louis D'hauwe
> 
> ___
> 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] Why doesn't removeLast() on Collection return an optional?

[Louis D'hauwe via swift-evolution]

Regarding the removeLast() function on Collection:

The current implementation 

 is:
@discardableResult
public mutating func removeLast() -> Iterator.Element {
let element = last!
self = self[startIndex..https://github.com/apple/swift/blob/c3b7709a7c4789f1ad7249d357f69509fb8be731/stdlib/public/core/BidirectionalCollection.swift#L220>
 even has this noted:
"The collection must not be empty.".

Surely you could just remove the explicit unwrapping of 'last' and add a guard 
statement? 

As such:
@discardableResult
public mutating func removeLast() -> Iterator.Element? {
guard let element = last else {
return nil
}
self = self[startIndex..___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Pitch] Nested types in protocols (and nesting protocols in types)

[Adrian Zubarev via swift-evolution]

That option should not be disallowed. Here is a simple example you might want 
to build at some point:

protocol ProtocolName {
 
associatedtype AssociatedType
}

extension ProtocolName where AssociatedType == Int {
  
struct InnerType {}
}


-- 
Adrian Zubarev
Sent with Airmail

Am 17. Oktober 2016 um 20:30:58, Karl via swift-evolution 
(swift-evolution@swift.org) schrieb:

Is your vision that each conforming type would have to provide its own nested 
type as specified by the protocol?

Or could the protocol itself define a nested type and anything could use it?

protocol FloatingPoint: … {
    enum RoundingRule {
        // Do I put an implementation here?
    }
}

No, types which are defined inside the protocol are implemented there. 
Providing your own types to satisfy a conformance is what associated types are 
for.

If you wanted something like that, you could do it with a nested protocol + 
associated type:

protocol FloatingPoint {

    protocol _RoundingRule { func round(_ : Super) -> Super }
    associatedType RoundingRule : _RoundingRule
}

struct Float : FloatingPoint {

    enum RoundingRule : _RoundingRule {
        func round(_ val: Float) -> Float {
            /* switch self, perform rounding… */ 
        }
    }
}

That brings up an interesting point, though - we would need a way to refer to 
the outer protocol (I used “Super” here).

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

Re: [swift-evolution] [Pitch] Nested types in protocols (and nesting protocols in types)

[Karl via swift-evolution]

> On 17 Oct 2016, at 20:31, Adrian Zubarev via swift-evolution 
>  wrote:
> 
> That’s also on the line: 
> [https://github.com/apple/swift/blob/611fc78d28a5da97dd1bea40761b913b1077aef5/docs/GenericsManifesto.md#nested-generics
>  
> ](https://github.com/apple/swift/blob/611fc78d28a5da97dd1bea40761b913b1077aef5/docs/GenericsManifesto.md#nested-generics
>  
> )
> 
> -- 
> Adrian Zubarev
> Sent with Airmail
> 
> Am 17. Oktober 2016 um 20:26:47, T.J. Usiyan (griotsp...@gmail.com 
> ) schrieb:
> 
>> I want this feature. Both class in protocol and protocol in class could 
>> clean up many relationships but I think that a blocking concern is "How does 
>> this interact with generics?" Nesting types in generic types is already 
>> disallowed and how different is this feature from that?
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

And even partially implemented, behind the flag 
“-enable-experimental-nested-generic-types”. I don’t know what’s missing from 
it, but it seemed to work in some simple cases last time I tried.

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

Re: [swift-evolution] [Pitch] Nested types in protocols (and nesting protocols in types)

[Karl via swift-evolution]

> On 17 Oct 2016, at 20:13, Nevin Brackett-Rozinsky 
>  wrote:
> 
> I like it!
> 
> I haven’t thought through the ramifications regarding associated types yet 
> though.
> 

Associated types are tricky. The example I gave maybe wasn’t the most 
practical, as to use it you’d have to write something like:

class A : MyProto where T : A.Delegate, T.ExpectedContent == String {}

which then locks you to using one static type for your delegate. Moving the 
associatedType up a level to MyProto means we would implement it by writing:

class A : MyProto {
typealias ExpectedContent = String

var delegate : A.Delegate

func notify() {
delegate.receive(“a string”, for: .someCase)
}
}

class B : MyProto {
typealias ExpectedContent = Int

var delegate : B.Delegate

func notify() {
delegate.receive(42, for: .someCase)
}
}

Still, I think the general answer to protocols with associated types for this 
case is: “use a concrete type in its place”.

> Is your vision that each conforming type would have to provide its own nested 
> type as specified by the protocol?
> 
> Or could the protocol itself define a nested type and anything could use it?
> 
> protocol FloatingPoint: … {
> enum RoundingRule {
> // Do I put an implementation here?
> }
> }

No, types which are defined inside the protocol are implemented there. 
Providing your own types to satisfy a conformance is what associated types are 
for.

If you wanted something like that, you could do it with a nested protocol + 
associated type:

protocol FloatingPoint {

protocol _RoundingRule { func round(_ : Super) -> Super }
associatedType RoundingRule : _RoundingRule
}

struct Float : FloatingPoint {

enum RoundingRule : _RoundingRule {
func round(_ val: Float) -> Float {
/* switch self, perform rounding… */ 
}
}
}

That brings up an interesting point, though - we would need a way to refer to 
the outer protocol (I used “Super” here).

> 
> Nevin
> 
> 
> 
> On Mon, Oct 17, 2016 at 1:59 PM, Karl via swift-evolution 
> mailto:swift-evolution@swift.org>> wrote:
> I was just doing some googling, turns out there was a discussion about 
> nesting protocols in other types that seemed to go positively a long time 
> ago: 
> https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160425/016074.html
>  
> 
> 
> I would additionally like to propose that protocols be allowed to contain 
> nested types (including other protocols). Relevant ABI issue is that the 
> standard library contains enums for “FloatingPointRoundingRule”, 
> “FloatingPointClassification” and “FloatingPointSign”. They would probably be 
> better expressed as “FloatingPoint.RoundingRule”, “.Sign", etc.
> 
> so to summarise, newly legal would be:
> 
> class MyClass {
> 
> protocol Delegate {
> }
> }
> 
> and also:
> 
> protocol MyProto {
> 
> enum SomeValue {
> }
> 
> protocol Delegate {
> associatedType ExpectedContent
> 
>   func receive(_: ExpectedContent, for: SomeValue)
> 
> protocol SecondaryTarget {
> func receive(_ : ExpectedContent)
> }
> }
> }
> 
> When conforming to a nested protocol, you can just use the name of the 
> protocol:
> 
> class Host : MyProto.Delegate {
> }
> 
> Except if a protocol in the chain has associated types, then you must use a 
> concrete, conforming type instead (as you would in the first example — 
> MyClass.Delegate):
> 
> class SecondaryProcessor : Host.SecondaryTarget {
> }
> 
> If we’re good with this, I’ll write up a proposal.
> 
> - Karl
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org 
> https://lists.swift.org/mailman/listinfo/swift-evolution 
> 
> 
> 

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

Re: [swift-evolution] [Pitch] Nested types in protocols (and nesting protocols in types)

[Adrian Zubarev via swift-evolution]

That’s also on the line: 
[https://github.com/apple/swift/blob/611fc78d28a5da97dd1bea40761b913b1077aef5/docs/GenericsManifesto.md#nested-generics](https://github.com/apple/swift/blob/611fc78d28a5da97dd1bea40761b913b1077aef5/docs/GenericsManifesto.md#nested-generics)

-- 
Adrian Zubarev
Sent with Airmail

Am 17. Oktober 2016 um 20:26:47, T.J. Usiyan (griotsp...@gmail.com) schrieb:

I want this feature. Both class in protocol and protocol in class could clean 
up many relationships but I think that a blocking concern is "How does this 
interact with generics?" Nesting types in generic types is already disallowed 
and how different is this feature from that?___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Replace Fileprivate with Hidden + Import Hidden

[Rien via swift-evolution]

> On 17 Oct 2016, at 19:47, Jonathan Hull  wrote:
> 
> First, let me say, thank you for your feedback.  Just because I am arguing 
> against others' points does not mean that I don’t appreciate those points.
> 
>> On Oct 17, 2016, at 12:37 AM, Rien  wrote:
>> 
>> -1.
>> 
>> If an API designer wants to allow access to a “hidden’ member, he should be 
>> in control of that access.
> This seems to be one of the biggest internal arguments within the swift 
> community.  Who is in control of the use of frameworks?  The author or the 
> user?
> 
> I am trying to plot a middle path here which gives both a fair amount of 
> control.  I think that is part of why this proposal has been so unpopular, it 
> is a compromise between both extremes, and everyone hates a compromise.  
> Someone else just had the opinion that we should make everything public and 
> note in the documentation what should and should not be used.
> 
> And as I said before, API like UIGestureRecognizer's is currently impossible 
> to create solely in Swift.  There is a hole in Swift’s access system which we 
> will have to fix sometime during this phase.  I think a lot of people think 
> that submodules will magically solve all of our problems, (I want them too) 
> but the core issue here will remain (just with a little less frequency), and 
> we will be forced to go back to the drawing board in 6mo to a year. I am 
> hoping to prevent that.
> 
> 
>> The proposed chance simply opens up access completely and leads to API 
>> vulnerability.
> No, it only opens up access to API explicitly marked with ‘hidden’.  That is, 
> the framework author is explicitly saying: This API should only be used for 
> subclassing/extension (but they also realize it can be accessed).  The user 
> of that API has to explicitly acknowledge that intention by writing ‘import 
> hidden’.  API marked private or internal will not be opened beyond it’s scope 
> in any case.
> 
> As I said in another email, a potential further compromise would be to make 
> ‘hidden’ a separate axis, and allow things like ‘internal hidden’, where 
> access can only be opened up within the module.  Would that solve your issues 
> with the proposal?
> 
> I started out closer to your position, wanting more targeted permissions, but 
> I ultimately realized that this would be good enough for real world use.
> 
> 
>> (I am in favour of a “friend” solution, in which the API designer explicitly 
>> allows access to identified members of the API users.)
> But what happens when you need to be a friend and you don’t own the API?  I 
> get the thinking behind friend classes, but it is problematic in practice.

In that case, you don’t get to be a “friend”. Tough cookies. Life isn’t “fair”.
In an exact science like SW development, control must be hierarchical or 
singular. Any deviation, however small, will come back to bite.
Too many API developers have spend too much time to look for “errors” that 
inexperienced or unknowing API users caused because the API was too “open”. The 
API developer may think that “it is clearly documented”… but then again, look 
at stackoverflow…. people don’t read them, and the API developer will be held 
responsible for the error of others… if only in reputation...


>  As another poster mentioned, we basically have friend classes already, just 
> based on location of code.  The core issue I am trying to solve here cannot 
> be solved with more variation of the same, we need a counterpoint to it, and 
> then the two approaches can be mixed to get the desired balance/tradeoffs.

Balances and tradeoffs only get you deeper into the quicksand. Better not to 
tread there. Sometimes you have to say NO.

Rien.

PS: I do understand the lure, buts it’s (IMO) always better to resist.



> 
> Thanks,
> Jon
> 
> 
>> Rien.
>> 
>> 
>>> On 16 Oct 2016, at 22:34, Jonathan Hull via swift-evolution 
>>>  wrote:
>>> 
>>> I keep wanting a “protected” access level, but I must also admit that there 
>>> was something really elegant about Swift 2’s access scheme (and I think 
>>> most of us feel like the word ‘fileprivate’ feels out of place).  I was 
>>> thinking about how to mesh those two ideas, and I think I may have come up 
>>> with a solution.
>>> 
>>> I propose we replace ‘fileprivate’ with a new ‘hidden’ access level.  
>>> Hidden would work exactly the same way as fileprivate does now, but adds 
>>> the connotation that what is hidden can also be unhidden.  By adding 
>>> ‘import hidden TypeName’ to another file, that file also gains access to 
>>> all of the hidden items of that type (kind of like if it was in the same 
>>> file).
>>> 
>>> #FileA  
>>> import Foundation
>>> 
>>> Struct A {
>>> private var x:Int
>>> hidden var y:Int  //This is just like fileprivate, but can also 
>>> be shared with other files
>>> }
>>> 
>>> extension A {
>>> //y can be accessed here because they are in the same file
>>> }
>>> 
>>> 
>>> #Fil

Re: [swift-evolution] [Pitch] Nested types in protocols (and nesting protocols in types)

[T.J. Usiyan via swift-evolution]

I want this feature. Both class in protocol and protocol in class could
clean up many relationships but I think that a blocking concern is "How
does this interact with generics?" Nesting types in generic types is
already disallowed and how different is this feature from that?

On Mon, Oct 17, 2016 at 2:20 PM, Adrian Zubarev via swift-evolution <
swift-evolution@swift.org> wrote:

> Two weeks ago there was a similar pitch here https://lists.swift.org/
> pipermail/swift-evolution/Week-of-Mon–20161003/027643.html
> 
>
> In general I’m in favor of this feature, but I don’t know any technical
> issues this might have or does already have.
>
> As I said in the other thread.
>
>-
>
>I’m for nested everything.
>-
>
>Nested extensions to reduce noise at some point, BUT this should not
>remove extension A.B { … } completely.
>
>class A {
>
>class B { … }
>
>extension B { … } // extends A.B
>}
>
>-
>
>We already have A.B syntax for extensions, why don’t we allow it for
>type declarations to reduce nesting (sometimes you don’t want to cluster
>everything)? Basically something like class A.B { … } would be a
>shortcut for extension A { class B { … } } and is bounded by the
>access modifier of A. (This is probably additive.)
>
>
>
> --
> Adrian Zubarev
> Sent with Airmail
>
> Am 17. Oktober 2016 um 19:59:54, Karl via swift-evolution (
> swift-evolution@swift.org) schrieb:
>
> I was just doing some googling, turns out there was a discussion about
> nesting protocols in other types that seemed to go positively a long time
> ago: https://lists.swift.org/pipermail/swift-evolution/
> Week-of-Mon-20160425/016074.html
>
> I would additionally like to propose that protocols be allowed to contain
> nested types (including other protocols). Relevant ABI issue is that the
> standard library contains enums for “FloatingPointRoundingRule”,
> “FloatingPointClassification” and “FloatingPointSign”. They would probably
> be better expressed as “FloatingPoint.RoundingRule”, “.Sign", etc.
>
> so to summarise, newly legal would be:
>
> class MyClass {
>
> protocol Delegate {
> }
> }
>
> and also:
>
> protocol MyProto {
>
> enum SomeValue {
> }
>
> protocol Delegate {
> associatedType ExpectedContent
>
> func receive(_: ExpectedContent, for: SomeValue)
>
> protocol SecondaryTarget {
> func receive(_ : ExpectedContent)
> }
> }
> }
>
> When conforming to a nested protocol, you can just use the name of the
> protocol:
>
> class Host : MyProto.Delegate {
> }
>
> Except if a protocol in the chain has associated types, then you must use
> a concrete, conforming type instead (as you would in the first example —
> MyClass.Delegate):
>
> class SecondaryProcessor : Host.SecondaryTarget {
> }
>
> If we’re good with this, I’ll write up a proposal.
>
> - Karl
> ___
> 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] Replace Fileprivate with Hidden + Import Hidden

[Charles Srstka via swift-evolution]

> On Oct 17, 2016, at 12:47 PM, Jonathan Hull via swift-evolution 
>  wrote:
> 
>> On Oct 17, 2016, at 12:37 AM, Rien > > wrote:
>> 
>> -1.
>> 
>> If an API designer wants to allow access to a “hidden’ member, he should be 
>> in control of that access.
> This seems to be one of the biggest internal arguments within the swift 
> community.  Who is in control of the use of frameworks?  The author or the 
> user?

To me, it seems that if the author has control already. If s/he needs to hide 
symbols from outside the framework, the “internal” keyword already exists for 
that.

Charles

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

Re: [swift-evolution] [Pitch] Nested types in protocols (and nesting protocols in types)

[Charles Srstka via swift-evolution]

Extremely strong +1.

I’ve got a bunch of Objective-C-style really long type names of the sort 
“MyProtocol”, “MyProtocolSomeTypeEnum”, “MyProtocolSomeOptionsEnum”, etc. It 
would be really nice to make those Swiftier.

Charles

> On Oct 17, 2016, at 12:59 PM, Karl via swift-evolution 
>  wrote:
> 
> I was just doing some googling, turns out there was a discussion about 
> nesting protocols in other types that seemed to go positively a long time 
> ago: 
> https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160425/016074.html
>  
> 
> 
> I would additionally like to propose that protocols be allowed to contain 
> nested types (including other protocols). Relevant ABI issue is that the 
> standard library contains enums for “FloatingPointRoundingRule”, 
> “FloatingPointClassification” and “FloatingPointSign”. They would probably be 
> better expressed as “FloatingPoint.RoundingRule”, “.Sign", etc.
> 
> so to summarise, newly legal would be:
> 
> class MyClass {
> 
> protocol Delegate {
> }
> }
> 
> and also:
> 
> protocol MyProto {
> 
> enum SomeValue {
> }
> 
> protocol Delegate {
> associatedType ExpectedContent
> 
>   func receive(_: ExpectedContent, for: SomeValue)
> 
> protocol SecondaryTarget {
> func receive(_ : ExpectedContent)
> }
> }
> }
> 
> When conforming to a nested protocol, you can just use the name of the 
> protocol:
> 
> class Host : MyProto.Delegate {
> }
> 
> Except if a protocol in the chain has associated types, then you must use a 
> concrete, conforming type instead (as you would in the first example — 
> MyClass.Delegate):
> 
> class SecondaryProcessor : Host.SecondaryTarget {
> }
> 
> If we’re good with this, I’ll write up a proposal.
> 
> - Karl
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

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

Re: [swift-evolution] [Pitch] Nested types in protocols (and nesting protocols in types)

[Adrian Zubarev via swift-evolution]

Two weeks ago there was a similar pitch here 
https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon–20161003/027643.html

In general I’m in favor of this feature, but I don’t know any technical issues 
this might have or does already have.

As I said in the other thread.

I’m for nested everything.

Nested extensions to reduce noise at some point, BUT this should not remove 
extension A.B { … } completely.

class A {
 
class B { … }
 
extension B { … } // extends A.B
}
We already have A.B syntax for extensions, why don’t we allow it for type 
declarations to reduce nesting (sometimes you don’t want to cluster 
everything)? Basically something like class A.B { … } would be a shortcut for 
extension A { class B { … } } and is bounded by the access modifier of A. (This 
is probably additive.)



-- 
Adrian Zubarev
Sent with Airmail

Am 17. Oktober 2016 um 19:59:54, Karl via swift-evolution 
(swift-evolution@swift.org) schrieb:

I was just doing some googling, turns out there was a discussion about nesting 
protocols in other types that seemed to go positively a long time ago: 
https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160425/016074.html

I would additionally like to propose that protocols be allowed to contain 
nested types (including other protocols). Relevant ABI issue is that the 
standard library contains enums for “FloatingPointRoundingRule”, 
“FloatingPointClassification” and “FloatingPointSign”. They would probably be 
better expressed as “FloatingPoint.RoundingRule”, “.Sign", etc.

so to summarise, newly legal would be:

class MyClass {

    protocol Delegate {
    }
}

and also:

protocol MyProto {

    enum SomeValue {
    }

    protocol Delegate {
        associatedType ExpectedContent

func receive(_: ExpectedContent, for: SomeValue)

        protocol SecondaryTarget {
            func receive(_ : ExpectedContent)
        }
    }
}

When conforming to a nested protocol, you can just use the name of the protocol:

class Host : MyProto.Delegate {
}

Except if a protocol in the chain has associated types, then you must use a 
concrete, conforming type instead (as you would in the first example — 
MyClass.Delegate):

class SecondaryProcessor : Host.SecondaryTarget {
}

If we’re good with this, I’ll write up a proposal.

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

Re: [swift-evolution] [Pitch] Nested types in protocols (and nesting protocols in types)

[Nevin Brackett-Rozinsky via swift-evolution]

I like it!

I haven’t thought through the ramifications regarding associated types yet
though.

Is your vision that each conforming type would have to provide its own
nested type as specified by the protocol?

Or could the protocol itself define a nested type and anything could use it?

protocol FloatingPoint: … {
enum RoundingRule {
// Do I put an implementation here?
}
}

Nevin



On Mon, Oct 17, 2016 at 1:59 PM, Karl via swift-evolution <
swift-evolution@swift.org> wrote:

> I was just doing some googling, turns out there was a discussion about
> nesting protocols in other types that seemed to go positively a long time
> ago: https://lists.swift.org/pipermail/swift-evolution/
> Week-of-Mon-20160425/016074.html
>
> I would additionally like to propose that protocols be allowed to contain
> nested types (including other protocols). Relevant ABI issue is that the
> standard library contains enums for “FloatingPointRoundingRule”,
> “FloatingPointClassification” and “FloatingPointSign”. They would probably
> be better expressed as “FloatingPoint.RoundingRule”, “.Sign", etc.
>
> so to summarise, newly legal would be:
>
> class MyClass {
>
> protocol Delegate {
> }
> }
>
> and also:
>
> protocol MyProto {
>
> enum SomeValue {
> }
>
> protocol Delegate {
> associatedType ExpectedContent
>
> func receive(_: ExpectedContent, for: SomeValue)
>
> protocol SecondaryTarget {
> func receive(_ : ExpectedContent)
> }
> }
> }
>
> When conforming to a nested protocol, you can just use the name of the
> protocol:
>
> class Host : MyProto.Delegate {
> }
>
> Except if a protocol in the chain has associated types, then you must use
> a concrete, conforming type instead (as you would in the first example —
> MyClass.Delegate):
>
> class SecondaryProcessor : Host.SecondaryTarget {
> }
>
> If we’re good with this, I’ll write up a proposal.
>
> - Karl
>
> ___
> 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] [Pitch] Nested types in protocols (and nesting protocols in types)

[Karl via swift-evolution]

I was just doing some googling, turns out there was a discussion about nesting 
protocols in other types that seemed to go positively a long time ago: 
https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160425/016074.html
 


I would additionally like to propose that protocols be allowed to contain 
nested types (including other protocols). Relevant ABI issue is that the 
standard library contains enums for “FloatingPointRoundingRule”, 
“FloatingPointClassification” and “FloatingPointSign”. They would probably be 
better expressed as “FloatingPoint.RoundingRule”, “.Sign", etc.

so to summarise, newly legal would be:

class MyClass {

protocol Delegate {
}
}

and also:

protocol MyProto {

enum SomeValue {
}

protocol Delegate {
associatedType ExpectedContent

func receive(_: ExpectedContent, for: SomeValue)

protocol SecondaryTarget {
func receive(_ : ExpectedContent)
}
}
}

When conforming to a nested protocol, you can just use the name of the protocol:

class Host : MyProto.Delegate {
}

Except if a protocol in the chain has associated types, then you must use a 
concrete, conforming type instead (as you would in the first example — 
MyClass.Delegate):

class SecondaryProcessor : Host.SecondaryTarget {
}

If we’re good with this, I’ll write up a proposal.

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

Re: [swift-evolution] Replace Fileprivate with Hidden + Import Hidden

[Jonathan Hull via swift-evolution]

First, let me say, thank you for your feedback.  Just because I am arguing 
against others' points does not mean that I don’t appreciate those points.

> On Oct 17, 2016, at 12:37 AM, Rien  wrote:
> 
> -1.
> 
> If an API designer wants to allow access to a “hidden’ member, he should be 
> in control of that access.
This seems to be one of the biggest internal arguments within the swift 
community.  Who is in control of the use of frameworks?  The author or the user?

I am trying to plot a middle path here which gives both a fair amount of 
control.  I think that is part of why this proposal has been so unpopular, it 
is a compromise between both extremes, and everyone hates a compromise.  
Someone else just had the opinion that we should make everything public and 
note in the documentation what should and should not be used.

And as I said before, API like UIGestureRecognizer's is currently impossible to 
create solely in Swift.  There is a hole in Swift’s access system which we will 
have to fix sometime during this phase.  I think a lot of people think that 
submodules will magically solve all of our problems, (I want them too) but the 
core issue here will remain (just with a little less frequency), and we will be 
forced to go back to the drawing board in 6mo to a year. I am hoping to prevent 
that.


> The proposed chance simply opens up access completely and leads to API 
> vulnerability.
No, it only opens up access to API explicitly marked with ‘hidden’.  That is, 
the framework author is explicitly saying: This API should only be used for 
subclassing/extension (but they also realize it can be accessed).  The user of 
that API has to explicitly acknowledge that intention by writing ‘import 
hidden’.  API marked private or internal will not be opened beyond it’s scope 
in any case.

As I said in another email, a potential further compromise would be to make 
‘hidden’ a separate axis, and allow things like ‘internal hidden’, where access 
can only be opened up within the module.  Would that solve your issues with the 
proposal?

I started out closer to your position, wanting more targeted permissions, but I 
ultimately realized that this would be good enough for real world use.


> (I am in favour of a “friend” solution, in which the API designer explicitly 
> allows access to identified members of the API users.)
But what happens when you need to be a friend and you don’t own the API?  I get 
the thinking behind friend classes, but it is problematic in practice.  As 
another poster mentioned, we basically have friend classes already, just based 
on location of code.  The core issue I am trying to solve here cannot be solved 
with more variation of the same, we need a counterpoint to it, and then the two 
approaches can be mixed to get the desired balance/tradeoffs.

Thanks,
Jon


> Rien.
> 
> 
>> On 16 Oct 2016, at 22:34, Jonathan Hull via swift-evolution 
>>  wrote:
>> 
>> I keep wanting a “protected” access level, but I must also admit that there 
>> was something really elegant about Swift 2’s access scheme (and I think most 
>> of us feel like the word ‘fileprivate’ feels out of place).  I was thinking 
>> about how to mesh those two ideas, and I think I may have come up with a 
>> solution.
>> 
>> I propose we replace ‘fileprivate’ with a new ‘hidden’ access level.  Hidden 
>> would work exactly the same way as fileprivate does now, but adds the 
>> connotation that what is hidden can also be unhidden.  By adding ‘import 
>> hidden TypeName’ to another file, that file also gains access to all of the 
>> hidden items of that type (kind of like if it was in the same file).
>> 
>> #FileA   
>>  import Foundation
>> 
>>  Struct A {
>>  private var x:Int
>>  hidden var y:Int  //This is just like fileprivate, but can also 
>> be shared with other files
>>  }
>> 
>>  extension A {
>>  //y can be accessed here because they are in the same file
>>  }
>> 
>>  
>> #FileB
>>  import Foundation
>>  import hidden A  //This allows the entire file to see A’s hidden 
>> variables
>> 
>>  extension A {
>>  //y can be accessed here because of the ‘import hidden’ 
>> declaration
>>  }
>> 
>> 
>> #FileC
>>  import Foundation
>> 
>>  extension A {
>>  //y can NOT be seen or accessed here because it is hidden
>>  }
>> 
>> 
>> I think this is a fairly elegant solution to our protected dilemma, which 
>> also feels in sync with Swift 2’s file-based scheme.  The key features:
>>  • Extensions no longer need to be piled in the same file if it is 
>> getting too long
>>  • Subclasses can be in their own file, but still have access to the 
>> necessary parts of their superclass
>>  • It communicates the author’s intent that the items are not meant to 
>> be visible to its users, but that it is expected to be used for 
>> extension/subclassing
>>  • It requires an explicit statement ‘import hi

Re: [swift-evolution] [pitch] "import" declaration, support for comma-separated modules

[Charles Constant via swift-evolution]

> Having one import per line is much more readable and maintainable

This depends on how much importance you give to "import" declarations. If
you feel they equally important as the rest of your code, I can understand
why you would want to see them. I don't.

My preference is to see as much of the rest of my code as possible. I don't
spend nearly as much time checking which modules I imported, as I do
editing functions and classes. I'd almost always prefer to have another
three lines of a protocol visible, than three lines of imports. Except that
the imports will be visible anyways, just - and even this is arguable in
many cases - harder to read.

> I never understood the desire for *extreme* vertical conciseness

It's probably *because* I use more vertical space than most people, that
losing screen real-estate to "import" declarations bothers me.


On Mon, Oct 17, 2016 at 8:40 AM, Said Sikira via swift-evolution <
swift-evolution@swift.org> wrote:

> -1. I disagree.
>
> Having one import per line is much more readable and maintainable
> especially when you have statements like `import func Framework.someMethod`.
>
> Being able to use `let a, b, c, …` doesn’t have to do anything with
> importing modules since those are completely different features of the
> language.
>
> On October 17, 2016 at 5:22:02 PM, Jay Abbott via swift-evolution (
> swift-evolution@swift.org) wrote:
>
> -1 - I don't like this.
>
> I never understood the desire for *extreme* vertical conciseness, it tends
> to make code less readable in general and definitely makes diffs a lot
> harder harder to read.
>
>
> On Sun, 16 Oct 2016 at 11:26 Anton Zhilin via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>> Purely additive feature, not for Swift 4 Phase 1.
>> And a -1 from me for reasons already mentioned.
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Replace Fileprivate with Hidden + Import Hidden

[Jonathan Hull via swift-evolution]

> On Oct 16, 2016, at 8:19 PM, David Waite  wrote:
> 
> fileprivate (and internal, in a sense) are really in the “friend” camp. 
> Rather than declaring particular types are friends, these require code 
> locality - in the same file in the case of fileprivate, in the same module in 
> the case of internal.
> 
> This does mean that the more stringent you wish to control internals, the 
> more code gets stuffed into a file or module - but could actually be 
> considered a benefit, as depending on internals naturally makes code highly 
> coupled.
> 
> That reason is why I’m not exactly fan of expanding ‘friend’-style 
> permissions further - this could completely disguise the level of effort 
> needed to change ‘hidden’ code in one class.

I think that is a valid point.  There is a tradeoff.  Being able to spread an 
API over more files means that there are more files to change when you need to 
make a change (and there is always a chance that you forget a file).  My 
argument would be that this allows the author to choose the tradeoff for 
themselves in each situation, whereas right now the choice is being made for 
them.  


> I’m against allowing hidden cross-module. If external code is explicitly 
> allowed to depend on ‘hidden’ API, then its still API which would be expected 
> to be stably maintained. Why not just make it public with appropriate caveats?

Yes, I think it would be expected to be stably maintained… but any sort of 
protected-style access is going to be the same, as you need a stable API to 
build subclasses/extensions on.  There are several reasons for encapsulation 
beyond making it easier to update API.  My main reason for wanting this is to 
be able to hide the levers which could get things into an inconsistent state 
internally, while still allowing for the few cases where that access is needed 
for efficient implementation.  Safe by default, with override.

I do suppose, at the expense of a little more complexity, we could make 
‘hidden' a separate axis of control.  That is, you could have ‘public hidden’, 
‘internal hidden’, and ‘private hidden’, with private hidden being exactly the 
same as today’s fileprivate (C# has protected internal, etc… so it isn’t 
unprecedented). That way, an author could choose the tradeoff between 
maintenance burden and extensibility.

Thanks,
Jon


> -DW
> 
>> On Oct 16, 2016, at 2:34 PM, Jonathan Hull via swift-evolution 
>>  wrote:
>> 
>> I keep wanting a “protected” access level, but I must also admit that there 
>> was something really elegant about Swift 2’s access scheme (and I think most 
>> of us feel like the word ‘fileprivate’ feels out of place).  I was thinking 
>> about how to mesh those two ideas, and I think I may have come up with a 
>> solution.
>> 
>> I propose we replace ‘fileprivate’ with a new ‘hidden’ access level.  Hidden 
>> would work exactly the same way as fileprivate does now, but adds the 
>> connotation that what is hidden can also be unhidden.  By adding ‘import 
>> hidden TypeName’ to another file, that file also gains access to all of the 
>> hidden items of that type (kind of like if it was in the same file).
>> 
>> #FileA   
>>  import Foundation
>> 
>>  Struct A {
>>  private var x:Int
>>  hidden var y:Int  //This is just like fileprivate, but can also 
>> be shared with other files
>>  }
>> 
>>  extension A {
>>  //y can be accessed here because they are in the same file
>>  }
>> 
>>  
>> #FileB
>>  import Foundation
>>  import hidden A  //This allows the entire file to see A’s hidden 
>> variables
>> 
>>  extension A {
>>  //y can be accessed here because of the ‘import hidden’ 
>> declaration
>>  }
>> 
>> 
>> #FileC
>>  import Foundation
>> 
>>  extension A {
>>  //y can NOT be seen or accessed here because it is hidden
>>  }
>> 
>> 
>> I think this is a fairly elegant solution to our protected dilemma, which 
>> also feels in sync with Swift 2’s file-based scheme.  The key features:
>>  • Extensions no longer need to be piled in the same file if it is 
>> getting too long
>>  • Subclasses can be in their own file, but still have access to the 
>> necessary parts of their superclass
>>  • It communicates the author’s intent that the items are not meant to 
>> be visible to its users, but that it is expected to be used for 
>> extension/subclassing
>>  • It requires an explicit statement ‘import hidden’ to access the 
>> hidden variables. Safe by default, with override.
>>  • It is not bound by module boundaries  (i.e. you could use it for 
>> subclassing classes from an imported module)
>>  • Roughly the same length as ‘private’ and ‘public’ so various 
>> declarations packed together are much easier to read (fileprivate breaks 
>> reading rhythm)  
>> 
>> Worth a formal proposal?
>> 
>> Thanks,
>> Jon
>> 
>> 
>> 
>> ___
>> swift-ev

Re: [swift-evolution] [Proposal] Enums with stored properties

[Kenny Leung via swift-evolution]

I’ve wondered this for a while now. Why must enums implement RawRepresentable?

-Kenny


> On Oct 12, 2016, at 4:37 AM, Karl via swift-evolution 
>  wrote:
> 
> You can already use structs as raw types. You just have to implement the 
> RawRepresentable conformance yourself.
> 
> RawRep doesn’t affect the enum’s storage, and the shorthand syntax we’ve got 
> saying “case a = 42” and so on is just for the compiler to synthesise a 
> couple of switch statements. The only reason the type needs to be a 
> string/integer literal in that case is so that we can check uniqueness and 
> solve the most common case. If you write your own implementation, you can 
> handle the more nuanced stuff there.
> 
> I don’t think there are any restrictions at all on RawRepresentable.RawType 
> (not even Comparable). It can be anything you like.
> 
> Karl
> 
>> On 12 Oct 2016, at 13:22, Mateusz Malczak via swift-evolution 
>>  wrote:
>> 
>> I agree, we dont event have to add a new language syntax to get this
>> feature. Using structs as rawTypes would do the trick but
>> 
>> 1. it should be possible to use struct initializer to define enum cases
>> struct MyStruct {
>> var width: Int
>> var height: Int
>> init(width: Int, height: Int) { ... }
>> }
>> 
>> enum MyEnum: MyStruct
>> {
>> case myStructCase1(width: 30, height: 30)
>> case myStructCase2(width: 60, height: 60)
>> ...
>> }
>> 
>> 2. calling .rawVaue should not be required in such case to access
>> stored properties
>> 
>> let e = MyEnum.myStructCase1
>> let width = e.width // instead of e.rawValue.width
>> 
>> Immutability of all properties in enum struct type is already
>> implemented in Swift.
>> At the same time .rawValue stays as it is for primitive types.
>> 
>> --
>> | Mateusz Malczak
>> +---
>> 
>> 
>> 2016-10-12 13:02 GMT+02:00 J.E. Schotsman via swift-evolution
>> :
>>> 
>>> On 12 Oct 2016, at 09:41,Mateusz Malczak wrote:
>>> 
>>> 
>>> That's exactly what this proposal is about. I would like to
>>> keep all enum properties but add an extra feature, so that enums can
>>> store some extra data.
>>> 
>>> 
>>> If technically possible I would prefer to directly use types for enum cases.
>>> Reducing a type to a tuple loses the computed properties and methods of the
>>> type.
>>> The types must be equatable I suppose.
>>> 
>>> The current enum rawValues are just indexes or keys which the compiler can
>>> autogenerate (like it does for enums without a raw type).
>>> Of course the raw values can be used in some smart way, like for sorting or
>>> grouping cases, but this can all be done with general types - and better at
>>> that.
>>> 
>>> So basically you have a struct type and an enum which is just a set of
>>> static lets of the struct type.
>>> struct MyStruct {}
>>> enum MyEnum: MyStruct
>>> {
>>> case myStruct1
>>> case myStruct2
>>> ...
>>> }
>>> 
>>> MyStruct need not be created specifically for the enum; it might be useful
>>> on its own.
>>> MyEnum can have additional computed properties and methods which are needed
>>> for the enumerated values only.
>>> 
>>> The cases can be accessed like MyStruct instances. No need for .rawValue
>>> except in the case of primitive types. Even there there is room for sugar
>>> (if a variable is already known to be of type Int we can assign an enum:Int
>>> case to it with implied .rawValue).
>>> 
>>> Jan E.
>>> 
>>> 
>>> 
>>> ___
>>> swift-evolution mailing list
>>> swift-evolution@swift.org
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>> 
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

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

Re: [swift-evolution] [swift-build-dev] Proposal: Package Manager Version Pinning

[Marcin Krzyzanowski via swift-evolution]

Daniel, it's all right, "There are only two hard things in Computer
Science: cache invalidation and *naming things*."


--
Marcin

On Fri, Oct 14, 2016 at 6:25 PM, Daniel Dunbar via swift-build-dev <
swift-build-...@swift.org> wrote:

> Let's not change this thread into a discussion of English. :)
>
>  - Daniel
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [pitch] "import" declaration, support for comma-separated modules

[Said Sikira via swift-evolution]

-1. I disagree.

Having one import per line is much more readable and maintainable
especially when you have statements like `import func Framework.someMethod`.

Being able to use `let a, b, c, …` doesn’t have to do anything with
importing modules since those are completely different features of the
language.

On October 17, 2016 at 5:22:02 PM, Jay Abbott via swift-evolution (
swift-evolution@swift.org) wrote:

-1 - I don't like this.

I never understood the desire for *extreme* vertical conciseness, it tends
to make code less readable in general and definitely makes diffs a lot
harder harder to read.


On Sun, 16 Oct 2016 at 11:26 Anton Zhilin via swift-evolution <
swift-evolution@swift.org> wrote:

> Purely additive feature, not for Swift 4 Phase 1.
> And a -1 from me for reasons already mentioned.
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [pitch] "import" declaration, support for comma-separated modules

[Jay Abbott via swift-evolution]

-1 - I don't like this.

I never understood the desire for *extreme* vertical conciseness, it tends
to make code less readable in general and definitely makes diffs a lot
harder harder to read.


On Sun, 16 Oct 2016 at 11:26 Anton Zhilin via swift-evolution <
swift-evolution@swift.org> wrote:

> Purely additive feature, not for Swift 4 Phase 1.
> And a -1 from me for reasons already mentioned.
> ___
> 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] Replace Fileprivate with Hidden + Import Hidden

[Jay Abbott via swift-evolution]

Oops, correction:

@unshelter(self); or
@unshelter(aWotsit)
// Inside a Wotsit or a Wotsit subclass this would work, y becomes
available.

Should be:

@unshelter(aThing)
// Inside a Wotsit or a Wotsit subclass this would work, y becomes
available.


On Mon, 17 Oct 2016 at 13:38 Jay Abbott  wrote:

> I'm not sure of my own opinions on this one as I can see good points on
> both sides. There also seem to be a variety of different discussions with
> similar concerns. So at the risk of confusing things I'm suggesting another
> idea, with the hope/intention of promoting some deeper thought and helping
> us figure out what is needed/wanted.
>
> I will use the word 'sheltered' here, apologies if that is confusing, it
> just means protected/hidden/whatever but without any existing notions of
> what those might mean. It might not be the best word either, I just picked
> it from a list of synonyms for 'protected'.
>
> Class authors can (now) if they want provide their own way to explicitly
> access some private members through a public interface:
>
> public class Thing {
> private var x: Int
> public var shelteredX: Int {
> get { return x }
> set { x = newValue }
> }
> }
>
> But this isn't ideal as it just causes excess boilerplate code and doesn't
> hide it from anyone or suggest they shouldn't normally use it (other than
> the explicit naming). However, perhaps the compiler could help with this
> type of pattern as follows:
>
> public class Thing {
> sheltered var x: Int {
> get { return x } // not sure how this would work - x is also the
> backing ivar so you don't have to declare it twice as _x and x.
> set { x = newValue }
> }
>// accessors provided - internal access to x is direct, sheltered
> access is via accessors
>
> sheltered var y: Int
> // No accessors provided, sheltered access to y is direct
> }
>
> For members with 'sheltered' access:
> * Don't by default allow access to the sheltered members or accessors -
> they are equivalent to private (or maybe fileprivate)
> * Provide a way to expose them in a given scope
> * I think it can be applied to methods too
>
> For example:
> var aThing = Thing()
> aThing.x = 7 // NOT ALLOWED: x is sheltered.
> @unshelter(aThing) // aThing is unsheltered in the remainder of its scope.
> aThing.x = 7 // NOW ALLOWED
>
> One good thing is that this is very explicit where you use it.
>
> Sheltered groups might also be a thing:
>
> Definition:
> sheltered var x: Int
> sheltered var y: Int
> Usage:
> @unshelter(aThing)
> // x is available, y isn't
> @unshelter(aThing)
> // x and y are available
>
> "Subclasses" and "Wotsits" are author-defined identifiers, not keywords.
> This is a bit like friends and protected, but using an honesty system,
> where friends can easily declare themselves as friends by unsheltering all
> the Wotsits group, and subclasses (not enforced) would unshelter the
> Subclasses group. That is, the author's intentions are clear, but other
> classes can abuse it to get access. If the author doesn't want to allow
> abuse, they can do this:
>
> Definition:
> sheltered var x: Int
> sheltered var y: Int
>
> Usage:
> @unshelter(self); or
> @unshelter(anOtherThing)
> // Works inside a Thing subclass, x becomes available. The scope in which
> @unshelter is used must match the type of the shelter group.
>
> @unshelter(self); or
> @unshelter(aWotsit)
> // Inside a Wotsit or a Wotsit subclass this would work, y becomes
> available.
>
> I'm just spitballing here, this isn't fully thought through. Perhaps a
> where clause would be better instead of a type annotation for the shelter
> groups, so you could list multiple types that are allowed to unshelter that
> group. You might be able to abuse it still by putting something in an
> extension of an allowed class, so that may need some further thought.
>
> This is of course more complex that other proposed solutions, I'm just
> trying to combine all the desires people seem to have and see what people
> think - do we want more control and are happy with a bit more complexity?
> or should it be simple and less control? Personally I actually don't have
> much of an opinion on it because I haven't used Swift enough yet to come a
> cropper of such things.
>
>
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Replace Fileprivate with Hidden + Import Hidden

[Jay Abbott via swift-evolution]

I'm not sure of my own opinions on this one as I can see good points on
both sides. There also seem to be a variety of different discussions with
similar concerns. So at the risk of confusing things I'm suggesting another
idea, with the hope/intention of promoting some deeper thought and helping
us figure out what is needed/wanted.

I will use the word 'sheltered' here, apologies if that is confusing, it
just means protected/hidden/whatever but without any existing notions of
what those might mean. It might not be the best word either, I just picked
it from a list of synonyms for 'protected'.

Class authors can (now) if they want provide their own way to explicitly
access some private members through a public interface:

public class Thing {
private var x: Int
public var shelteredX: Int {
get { return x }
set { x = newValue }
}
}

But this isn't ideal as it just causes excess boilerplate code and doesn't
hide it from anyone or suggest they shouldn't normally use it (other than
the explicit naming). However, perhaps the compiler could help with this
type of pattern as follows:

public class Thing {
sheltered var x: Int {
get { return x } // not sure how this would work - x is also the
backing ivar so you don't have to declare it twice as _x and x.
set { x = newValue }
}
   // accessors provided - internal access to x is direct, sheltered access
is via accessors

sheltered var y: Int
// No accessors provided, sheltered access to y is direct
}

For members with 'sheltered' access:
* Don't by default allow access to the sheltered members or accessors -
they are equivalent to private (or maybe fileprivate)
* Provide a way to expose them in a given scope
* I think it can be applied to methods too

For example:
var aThing = Thing()
aThing.x = 7 // NOT ALLOWED: x is sheltered.
@unshelter(aThing) // aThing is unsheltered in the remainder of its scope.
aThing.x = 7 // NOW ALLOWED

One good thing is that this is very explicit where you use it.

Sheltered groups might also be a thing:

Definition:
sheltered var x: Int
sheltered var y: Int
Usage:
@unshelter(aThing)
// x is available, y isn't
@unshelter(aThing)
// x and y are available

"Subclasses" and "Wotsits" are author-defined identifiers, not keywords.
This is a bit like friends and protected, but using an honesty system,
where friends can easily declare themselves as friends by unsheltering all
the Wotsits group, and subclasses (not enforced) would unshelter the
Subclasses group. That is, the author's intentions are clear, but other
classes can abuse it to get access. If the author doesn't want to allow
abuse, they can do this:

Definition:
sheltered var x: Int
sheltered var y: Int

Usage:
@unshelter(self); or
@unshelter(anOtherThing)
// Works inside a Thing subclass, x becomes available. The scope in which
@unshelter is used must match the type of the shelter group.

@unshelter(self); or
@unshelter(aWotsit)
// Inside a Wotsit or a Wotsit subclass this would work, y becomes
available.

I'm just spitballing here, this isn't fully thought through. Perhaps a
where clause would be better instead of a type annotation for the shelter
groups, so you could list multiple types that are allowed to unshelter that
group. You might be able to abuse it still by putting something in an
extension of an allowed class, so that may need some further thought.

This is of course more complex that other proposed solutions, I'm just
trying to combine all the desires people seem to have and see what people
think - do we want more control and are happy with a bit more complexity?
or should it be simple and less control? Personally I actually don't have
much of an opinion on it because I haven't used Swift enough yet to come a
cropper of such things.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Out of scope][Gibberish]

[Jeremy Pereira via swift-evolution]

So sorry, I meant to delete Swift-evolution from the cc list but forgot.

Apologies for the off topic post.


> On 17 Oct 2016, at 10:12, Jeremy Pereira  
> wrote:
> 
> 
>> On 14 Oct 2016, at 20:11, Ted F.A. van Gaalen via swift-evolution 
>>  wrote:
>> 
>> 
>>> On 14 Oct 2016, at 07:16, Daniel Duan via swift-evolution 
>>>  wrote:
>>> 
>>> 1. “honor” is mis-spelled in “weird queen’s dialect”.
>> 
>> I'm sorry, but I throw an exception at this; when you say "weird queen's 
>> dialect" do you mean… English?
> 
> I think he was just trying to be funny. As an Englishman, I don’t take 
> offence.
> 
>> I don't go around referring to the other variation as "weird can't spell 
>> dialect" (but maybe I should) 😛
>> The u in words like honour is what makes it pronounced like "onner" rather 
>> than "hone-ore", same with colour being "culler" rather than "coal-ore". 
>> Sorry but it really annoys me when people consider the English version of 
>> English to be the weird one, as the clue is literally in the name as to 
>> which version is correct.
> 
> Well it’s actually an interesting question. It’s fairer to say that the 
> language forked back when people started moving from Britain to the Americas. 
> After that it evolved and diverged on both sides of the Atlantic. You can’t 
> argue that one side or the other is wrong, particularly as, throughout most 
> of the period when the British were colonising the USA, there was no standard 
> spelling for English.
> 
> 
>> This is why it still galls me that the language in macOS is "British 
>> English" yet the other one is just "English" rather than "American English" 
>> or whatever, it's a hideous double standard.
> 
> I just checked my Mac. I’m currently using a language that it refers to as 
> English (UK). Amongst the many alternatives I could choose is English (US). 
> There is no option that is just called “English”.
> 
> 
>> 
> 

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

Re: [swift-evolution] [Out of scope][Gibberish]

[Jeremy Pereira via swift-evolution]

> On 14 Oct 2016, at 20:11, Ted F.A. van Gaalen via swift-evolution 
>  wrote:
> 
> 
>> On 14 Oct 2016, at 07:16, Daniel Duan via swift-evolution 
>>  wrote:
>> 
>> 1. “honor” is mis-spelled in “weird queen’s dialect”.
> 
> I'm sorry, but I throw an exception at this; when you say "weird queen's 
> dialect" do you mean… English?

I think he was just trying to be funny. As an Englishman, I don’t take offence.

> I don't go around referring to the other variation as "weird can't spell 
> dialect" (but maybe I should) 😛
> The u in words like honour is what makes it pronounced like "onner" rather 
> than "hone-ore", same with colour being "culler" rather than "coal-ore". 
> Sorry but it really annoys me when people consider the English version of 
> English to be the weird one, as the clue is literally in the name as to which 
> version is correct.

Well it’s actually an interesting question. It’s fairer to say that the 
language forked back when people started moving from Britain to the Americas. 
After that it evolved and diverged on both sides of the Atlantic. You can’t 
argue that one side or the other is wrong, particularly as, throughout most of 
the period when the British were colonising the USA, there was no standard 
spelling for English.


> This is why it still galls me that the language in macOS is "British English" 
> yet the other one is just "English" rather than "American English" or 
> whatever, it's a hideous double standard.

I just checked my Mac. I’m currently using a language that it refers to as 
English (UK). Amongst the many alternatives I could choose is English (US). 
There is no option that is just called “English”.


> 

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

Re: [swift-evolution] Replace Fileprivate with Hidden + Import Hidden

[Rien via swift-evolution]

-1.

If an API designer wants to allow access to a “hidden’ member, he should be in 
control of that access.
The proposed chance simply opens up access completely and leads to API 
vulnerability.

(I am in favour of a “friend” solution, in which the API designer explicitly 
allows access to identified members of the API users.)

Rien.


> On 16 Oct 2016, at 22:34, Jonathan Hull via swift-evolution 
>  wrote:
> 
> I keep wanting a “protected” access level, but I must also admit that there 
> was something really elegant about Swift 2’s access scheme (and I think most 
> of us feel like the word ‘fileprivate’ feels out of place).  I was thinking 
> about how to mesh those two ideas, and I think I may have come up with a 
> solution.
> 
> I propose we replace ‘fileprivate’ with a new ‘hidden’ access level.  Hidden 
> would work exactly the same way as fileprivate does now, but adds the 
> connotation that what is hidden can also be unhidden.  By adding ‘import 
> hidden TypeName’ to another file, that file also gains access to all of the 
> hidden items of that type (kind of like if it was in the same file).
> 
> #FileA
>   import Foundation
> 
>   Struct A {
>   private var x:Int
>   hidden var y:Int  //This is just like fileprivate, but can also 
> be shared with other files
>   }
> 
>   extension A {
>   //y can be accessed here because they are in the same file
>   }
> 
>   
> #FileB
>   import Foundation
>   import hidden A  //This allows the entire file to see A’s hidden 
> variables
> 
>   extension A {
>   //y can be accessed here because of the ‘import hidden’ 
> declaration
>   }
> 
> 
> #FileC
>   import Foundation
> 
>   extension A {
>   //y can NOT be seen or accessed here because it is hidden
>   }
> 
> 
> I think this is a fairly elegant solution to our protected dilemma, which 
> also feels in sync with Swift 2’s file-based scheme.  The key features:
>   • Extensions no longer need to be piled in the same file if it is 
> getting too long
>   • Subclasses can be in their own file, but still have access to the 
> necessary parts of their superclass
>   • It communicates the author’s intent that the items are not meant to 
> be visible to its users, but that it is expected to be used for 
> extension/subclassing
>   • It requires an explicit statement ‘import hidden’ to access the 
> hidden variables. Safe by default, with override.
>   • It is not bound by module boundaries  (i.e. you could use it for 
> subclassing classes from an imported module)
>   • Roughly the same length as ‘private’ and ‘public’ so various 
> declarations packed together are much easier to read (fileprivate breaks 
> reading rhythm)  
> 
> Worth a formal proposal?
> 
> Thanks,
> Jon
> 
> 
> 
> ___
> 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