Re: [swift-evolution] 'T != Type' in where clause

[Nicolas Fezans via swift-evolution]

+1
I would also welcome to be able to use "or" and "and" logical operators
(not only the not operator) on these constraints.
I have sometimes generic functions whose code is identical but is written
twice: first with 'where T=P1' and then with 'where T=P2', being able to
write for instance 'where T=(P1 or P2)' would be very handy IMO.
One could often argue that additional protocols and extensions could be
defined as a workaround to the situation I just mentioned but it seems
often a bit of an overkill to me when you only have a couple of functions
with that combination of requirements.


Nicolas

On Tue, Feb 28, 2017 at 7:53 AM, Nicholas Maccharoli via swift-evolution <
swift-evolution@swift.org> wrote:

> + 1
>  I personally find this frustrating, but at the same time Im curious as to
> what the argument against
> introducing this is.
>
> - Nick
>
> On Tue, Feb 28, 2017 at 3:21 PM, David Sweeris via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>>
>>
>>
>> Sent from my iPhone
>> > On Feb 27, 2017, at 16:34, Rex Fenley via swift-evolution <
>> swift-evolution@swift.org> wrote:
>> >
>> > I often find myself running into situations where I'll receive
>> "Ambiguous use of..." for overloaded functions or operators. In every case
>> these situations would be easily solved if I could specify "Generic !=
>> CertainType" in the where clause of one of the overloads so I can
>> disambiguate the cases. Could this be added to language?
>>
>> + all the 1s, along with something like "where !(T: Foo)"
>>
>> IIRC, the topic has come up before, though I couldn't (quickly) find it
>> and don't recall what the response was (other than some variation of "no",
>> since we don't have it).
>>
>> - Dave Sweeris
>>
>>
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>
>
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] 'T != Type' in where clause

[Nicholas Maccharoli via swift-evolution]

+ 1
 I personally find this frustrating, but at the same time Im curious as to
what the argument against
introducing this is.

- Nick

On Tue, Feb 28, 2017 at 3:21 PM, David Sweeris via swift-evolution <
swift-evolution@swift.org> wrote:

>
>
>
> Sent from my iPhone
> > On Feb 27, 2017, at 16:34, Rex Fenley via swift-evolution <
> swift-evolution@swift.org> wrote:
> >
> > I often find myself running into situations where I'll receive
> "Ambiguous use of..." for overloaded functions or operators. In every case
> these situations would be easily solved if I could specify "Generic !=
> CertainType" in the where clause of one of the overloads so I can
> disambiguate the cases. Could this be added to language?
>
> + all the 1s, along with something like "where !(T: Foo)"
>
> IIRC, the topic has come up before, though I couldn't (quickly) find it
> and don't recall what the response was (other than some variation of "no",
> since we don't have it).
>
> - Dave Sweeris
>
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Pitch] Typed throws

[Karl Wagner via swift-evolution]

> On 28 Feb 2017, at 02:43, Matthew Johnson via swift-evolution 
>  wrote:
> 
> 
> 
> Sent from my iPad
> 
> On Feb 27, 2017, at 7:19 PM, Daniel Leping  > wrote:
> 
>> Well, as Dave pointed, you can very rarely recover from an error, which IMO 
>> is absolutely true.
>> 
>> If your operation fails you don't really care unless you can recover. And 
>> you know your cases, which you can recover from (in reality one usually does 
>> it in optimization phase, though).
>> 
>> What else do you need the type of error for at the very end of your call 
>> stack? In 90% you will tell the user "ah, sorry, something happened. Come 
>> back later" and log the error (if you haven't forgot it).
>> 
>> In most cases the errors are not for recovering. They neither are to be 
>> presented to users. They are for developers to read the log/crash 
>> report/whatever else and analyze it. Most of the errors are for debugging 
>> purposes.
>> 
>> I don't want to deal with cumbersome code the purpose of which is to just 
>> "obey the language rules". Unless I know how to recover I would rethrow it. 
>> Than catch at the top of the stack and log + show the user a nice "sorry" 
>> message without getting techy.
> 
> In order to provide a helpful experience to end users an app needs to know 
> about what might have caused the error and therefore what might (or might 
> not) resolve it, allowing the operation to succeed on a subsequent attempt.  
> This can influence the strategy an app uses to avoid bothering the user if it 
> might be resolvable without user intervention and can also influence the 
> content of the message presented to users if that is necessary.  
> 

Errors are certainly useful, but the key distinction (IMO) is that callers 
should never rely on an error happening or not. They are typically highly 
implementation and hence version-specific. I think that means specific errors 
shouldn’t be part of the function signature.

That doesn’t mean you can’t handle the error. A function that throws is one 
that reserves the right to fail; maybe you can resolve the problem, but maybe 
you can’t. That means your enclosing operation also needs to be prepared to 
fail for reasons beyond _its_ control, and so on. At some point your entire 
UI-level sub-operation (like opening the file, downloading the data from the 
network) just fails, and you decide whether or not the user needs to be told of 
that and how to do so.

> Indeed, many apps don't bother with this kind of detail and just treat all 
> errors the same.  Personally, I find that to be an unfortunate state of 
> affairs both as a user and as a developer.
> 
> Types can be useful in conveying this kind of information and abstracting low 
> level details that are not helpful at higher levels in the stack.  Of course 
> types are not the only way to convey this information.  But my experience is 
> that untyped errors often result in libraries with poor documentation of 
> error cases and not enough consideration of the error handling experience of 
> users of the library in general.   That makes it very difficult to handle 
> errors well.  I have experiences like this in several languages and on 
> several platforms, including Apple's.  

I’m not sure that types are really the best abstraction for “the list of errors 
that can be thrown by this function”. They’re fine for error themselves, but 
not for per-function error-lists IMO. Most of our types are way too rigid for 
this to be easy to live with.

If I understand what you’re saying, the core problem can be summarised as: "I 
don’t know/can’t easily communicate which errors this function throws”. Really, 
it is a documentation problem; it's too onerous to document every individual 
throwing function, even with our very pretty markdown-like syntax. I’m just not 
sure that the relatively rigid type-system is the solution.

Now, if we look at this from a documentation perspective: obviously, the 
compiler _typically_ can't generate documentation for you, because it doesn’t 
know what your types/functions are meant for. Error documentation, though, is 
different: the compiler *can* often know the specific errors which get thrown 
(or rethrown from a call to another function from whom it can get that 
information); and even when it can’t know that, often it can at least know the 
specific type of error. We could enhance the compiler libraries to track that; 
I spent half a day modifying the existing error-checker in Sema to prove the 
concept and it’s close.

Swift libraries don’t have header files, so third-parties will only ever see 
your documentation as generated by some tool which integrates the compiler. 
That means the compiler can “improve” the documentation when it is lacking. For 
yourself, if you care about explicitly writing out the errors which get thrown 
and you’re not working with an IDE, you could enable 

Re: [swift-evolution] [swift-build-dev] [Draft] Package Manager Manifest API Redesign

[David Hart via swift-evolution]

> On 28 Feb 2017, at 01:50, Daniel Dunbar  wrote:
> 
> Hi David,
> 
> We discussed the leading-dot & capitalization issue today again... this was 
> already something we weren't really happy about, but had chosen to live with 
> (using the "identity" rule to determine what was a type and what wasn't). 
> However, as we talked it over more we:
> 1. Felt that for the product types, using .library vs .Library would be 
> reasonable and consistent with a user model of thinking of these like enums 
> (even though they won't actually be in practice, we will use factory 
> functions on Product to make the dot work and keep the space extensible).
> 2. Realized that using .target would be a useful change to make now if we 
> ever ended up needing to make the Targets array polymorphic (not something we 
> plan to do now, but it never hurts to have it be extensible).
> so we decided to go ahead and revise to a model where we use leading-dot + 
> lowercase for everything (except Package), including reverting 
> SystemPackageProvider to the `.brew(...)` style syntax.

Sounds great! When you send it through proposal, can you include an example 
Package with all properties set so we can see the new API in use?

Thanks!

> Thanks for the feedback!
>  - Daniel
> 
>> On Feb 27, 2017, at 2:21 AM, Ankit Aggarwal via swift-build-dev 
>>  wrote:
>> 
>> Hi David,
>> 
>> Thanks for the feedback! Comments inline:
>> 
>> 
>>> On Sun, Feb 26, 2017 at 5:08 AM, David Hart via swift-build-dev 
>>>  wrote:
>>> Was looking forward to this :) here are my comments:
>>> 
 On 25 Feb 2017, at 01:35, Rick Ballard via swift-evolution 
  wrote:
 
 Hi all,
 
 Ankit, Daniel, Anders, Boris and I have a draft proposal in progress for a 
 Package.swift manifest API redesign for the Package Manager. We'll welcome 
 comments or discussion at this time. My hope is that we can get this 
 polished up and ready for evolution within the next week or so, but we'll 
 see how the conversation goes!
 
 You can see the proposal in progress at 
 https://github.com/aciidb0mb3r/swift-evolution/blob/manifest-api-redesign/proposals/-package-manager-manifest-api-redesign.md.
  I'm also including the current version inline in this email.
 
 Thanks,
 
- Rick
 
 # Package Manager Manifest API Redesign
 
 * Proposal: [SE-](-package-manager-manifest-api-redesign.md)
 * Author: [Ankit Aggarwal](https://github.com/aciidb0mb3r)
 * Review Manager: TBD
 * Status: **Discussion**
 
 ## Introduction
 
 This is a proposal for redesigning the `Package.swift` manifest APIs 
 provided
 by Swift Package Manager.  
 This proposal only redesigns the existing public APIs and does not add any
 new functionality; any API to be added for new functionality will happen in
 separate proposals.
 
 ## Motivation
 
 The `Package.swift` manifest APIs were designed prior to the [API Design
 Guidelines] (https://swift.org/documentation/api-design-guidelines/), and 
 their
 design was not reviewed by the evolution process. Additionally, there are
 several small areas which can be cleaned up to make the overall API more
 "Swifty".
 
 We would like to redesign these APIs as necessary to provide clean,
 conventions-compliant APIs that we can rely on in the future. Because we
 anticipate that the user community for the Swift Package Manager will grow
 considerably in Swift 4, we would like to make these changes now, before
 more packages are created using the old API.
 
 ## Proposed solution
 
 Note: Access modifier is omitted from the diffs and examples for brevity. 
 The
 access modifier is `public` for all APIs unless specified.
 
 * Remove `successor()` and `predecessor()` from `Version`.
 
These methods neither have well defined semantics nor are used a lot
(internally or publicly). For e.g., the current implementation of
`successor()` always just increases the patch version.
 
 

  View diff
  
```diff
struct Version {
-func successor() -> Version
 
-func predecessor() -> Version
}
```

 
 * Make all properties of `Package` and `Target` mutable.
 
Currently, `Package` has three immutable and four mutable properties, 
 and
`Target` has one immutable and one mutable property. We propose to make 
 all
properties mutable to allow complex customization on the package object
after initial declaration.
 

  View diff and example
  
 
  Diff:
```diff
final class Target {
-let name: String
+var name: String

Re: [swift-evolution] 'T != Type' in where clause

[David Sweeris via swift-evolution]

Sent from my iPhone
> On Feb 27, 2017, at 16:34, Rex Fenley via swift-evolution 
>  wrote:
> 
> I often find myself running into situations where I'll receive "Ambiguous use 
> of..." for overloaded functions or operators. In every case these situations 
> would be easily solved if I could specify "Generic != CertainType" in the 
> where clause of one of the overloads so I can disambiguate the cases. Could 
> this be added to language?

+ all the 1s, along with something like "where !(T: Foo)"

IIRC, the topic has come up before, though I couldn't (quickly) find it and 
don't recall what the response was (other than some variation of "no", since we 
don't have it).

- Dave Sweeris


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

Re: [swift-evolution] [Pitch] Typed throws

[David Waite via swift-evolution]

> On Feb 27, 2017, at 2:08 PM, Matthew Johnson  wrote:
> 
>> 
>> On Feb 27, 2017, at 1:46 PM, David Waite via swift-evolution 
>> > wrote:
>> 
>> Add more layers, and it can be very mysterious why a call failed. Java at 
>> least captures stack traces in this case to aid in technical support in 
>> diagnosing the error.
>> 
>> Wrapping exceptions also prevents an aggregate of errors from different 
>> subsystems being handled as a category, such as having a catch block handle 
>> RecoverableError generically
>> 
>> An interesting solution that has emerged in Ruby to keep library authors 
>> from wrapping exceptions is by decorating the existing exception. Exceptions 
>> are caught via pattern matching (same as in Swift), so rather than wrap an 
>> extension, they extend the error instance with a library-specific module 
>> (e.g. swift protocol). So while the error may be a IOError in ruby, you can 
>> still catch it via ‘rescue JSONError’
> 
> If I understand this correctly it sounds like introducing a library would 
> create protocols to categorize errors and add retroactive conformances to 
> these protocols for errors thrown by its dependencies?  That is an 
> interesting approach.  But it requires knowing the concrete types of the 
> possible errors all the way down the stack (you can’t add a conformance to an 
> existential).  This seems very problematic to me, especially in a language 
> where creating new error types is as easy as it is in Swift.

I believe it is something that even Objective C can’t do; extend a single 
instance of a type to support a protocol.

You can still do really interesting things with categories of errors, such as 
extend existing types to support a protocol, and putting categorization logic 
on third party errors yourself.

That breaks though if every library does

struct MyError: Error {
   let innerError: Error
}

in order to have a typed throw. 

> Error handling is messy, there’s no doubt about that.  I would like to have 
> as many tools at my disposal as possible.  Error types is one of those tools.

I’m still trying to mentally put together the elevator pitch for typed throws. 
How do I explain to new/junior developers and developers coming from other 
languages when to do typed throws, and when not to?

-DW

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

Re: [swift-evolution] [Draft] Refining identifier and operator symbology (take 2)

[Xiaodi Wu via swift-evolution]

On Mon, Feb 27, 2017 at 10:07 PM, Nevin Brackett-Rozinsky via
swift-evolution  wrote:

> I think the most important goal is to end up with the right set of
> operator and identifier characters for *Swift*. The Unicode guidelines are
> a useful tool for that purpose, and get us a long way toward where we want
> to be. However at the end of the day we should weigh our success by how
> well we have done for Swift, not by how rigidly we adhere to Unicode
> recommendations.
>
> Our treatment of emoji is a great example: the right thing for Swift is
> different from the right thing for Unicode, so we choose to do what works
> best for Swift. This proposal captures that very well.
>

In fact, I'm greatly dissatisfied with how this proposal captures emoji.
Having come up with that scheme, I suspect that it is deficient in subtle
or obvious ways that are not yet apparent to me. This is why I have asked
for feedback along those lines. Note that for emoji, too, I have
deliberately resisted the one-by-one inclusion of certain characters that
are excluded by Unicode categories, of which there are a (small) handful.
My very strong personal preference, though soundly rejected, would have
been to remove the security and forward compatibility headache of support
emoji altogether. It does not in my opinion hold its own weight.

Matching what Unicode does should be a means for us, not an end. A stepping
> stone we can use when it helps. Unicode’s categorizations should inform
> and guide out decisions, not constrain them.
>

Well, now we are talking about overarching principles. The aim of this
proposal is in fact to assert that Swift's identifiers and operators should
be rationalized in a way that is constrained by Unicode recommendations.
Just as Swift aims to provide full support for correct Unicode handling in
strings by default, this proposal aims to align the valid characters to
current and future Unicode recommendations as tightly as possible. It is
anticipated that it should break a very small amount of actual code (if
any). It permits Swift to evolve with new developments in Unicode in the
future essentially "for free." In exchange we accept imperfections in
Unicode as imperfections in Swift. I argue that we should do so because our
own imperfections in understanding international character sets will
necessarily be greater than that of Unicode experts working systematically.

With regard to the fact that reclassifying the infinity and empty set
> symbols would be a breaking change, that is all the more reason to do it
> now, for Swift 4, before it is too late. Those two characters have come up
> in every iteration of this discussion on Swift Evolution that I can recall,
> and I have not heard anyone argue that they ought to be operators. I think
> it is safe to consider them low-hanging fruit.
>

Disagree. As mentioned in the proposal, no attempt is made to expand the
set of valid identifier characters to include non-emoji pictographs or
symbols.  If we adopt your approach, infinity and empty set would be the
only non-emoji non-"human language" symbols deliberately allowed in
identifiers, an approach no more consistent that the previous proposal to
include only the cow and dog emoji. The alternative is to go through a vast
swath of symbols character-by-character to determine which is sufficiently
"noun-like" to be an identifier, as Unicode does not and (as far as I can
tell) will never expand UAX#31 to include such symbols among identifiers.

As I mentioned, it would be also be inconsistent to consider excluding only
these two characters and not related characters, such as variations on the
infinity symbol, from the set of valid operators. Very quickly, the
necessity of doing a character-by-character debate balloons to encompass
the entire character set. I continue to believe that this is absolutely the
wrong approach.


> Nevin
>
> ___
> 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] 'T != Type' in where clause

[Robert Bennett via swift-evolution]

I'm also annoyed by this, so I second this proposal.

To give an explicit example of the kind of code that can lead to frustration 
and a desire for "T != Type":

protocol P1 {}

protocol P2 {
// Now, any type conforming to P1 and P2 may not be added to itself
static func +(lhs: Self, rhs: T) -> Self
static func +(lhs: T, rhs: Self) -> Self
}

struct S: P1, P2 {
static func +(lhs: S, rhs: T) -> S { return lhs }
static func +(lhs: T, rhs: S) -> S { return rhs }
}

let s1 = S()
let s2 = S()

print(s1 + s2) // ambiguous use of operator '+'


If I understand, this would be the desired capability:

protocol P1 {}

protocol P2 {
// Now, there's no ambiguity
static func +(lhs: Self, rhs: T) -> Self
static func +(lhs: T, rhs: Self) -> Self
static func +(lhs: Self, rhs: Self) -> Self
}

struct S: P1, P2 {
static func +(lhs: T, rhs: S) -> S {
return rhs
}
static func +(lhs: S, rhs: T) -> S {
return lhs
}
static func +(lhs: S, rhs: S) -> S {
return lhs
}
}

Some thought would have to be given to how to handle subtype relationships — 
probably you would use the polymorphic type of the object at the call site.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Draft] Refining identifier and operator symbology (take 2)

[Nevin Brackett-Rozinsky via swift-evolution]

I think the most important goal is to end up with the right set of operator
and identifier characters for *Swift*. The Unicode guidelines are a useful
tool for that purpose, and get us a long way toward where we want to be.
However at the end of the day we should weigh our success by how well we
have done for Swift, not by how rigidly we adhere to Unicode recommendations
.

Our treatment of emoji is a great example: the right thing for Swift is
different from the right thing for Unicode, so we choose to do what works
best for Swift. This proposal captures that very well.

Matching what Unicode does should be a means for us, not an end. A stepping
stone we can use when it helps. Unicode’s categorizations should inform and
guide out decisions, not constrain them.

With regard to the fact that reclassifying the infinity and empty set
symbols would be a breaking change, that is all the more reason to do it
now, for Swift 4, before it is too late. Those two characters have come up
in every iteration of this discussion on Swift Evolution that I can recall,
and I have not heard anyone argue that they ought to be operators. I think
it is safe to consider them low-hanging fruit.

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

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0155: Normalize Enum Case Representation

[Brent Royal-Gordon via swift-evolution]

-- 
Brent Royal-Gordon
Sent from my iPhone
> On Feb 27, 2017, at 10:39 AM, Matthew Johnson via swift-evolution 
>  wrote:

> 
> Here is an example of the kind of thing I have in mind:
> 
> enum PlayerState {
>   case stopped
>   sub case playing(with track: Track)
> 
>// type of the playing case looks something like this:
>struct Playing { let track: Track }
> 
>// the case value constructor looks something like this
>static func playing(with track: Track) -> Playing {
>return Playing(track: track)
>}
> }

Consider a different desugaring that leads to a different conclusion:

enum PlayerState {
  case struct stopped {
init() {}
// I have some truly remarkable thoughts 
// on types like this one, which this margin
// is too narrow to contain.
  }
  case struct playing {
let track: Track
init(track: Track) {
  self.track = track
}
}

In this design, because the associated values on a case are really defining an 
initializer on a type, it would be against Swift conventions to use a parameter 
label like `with` instead of the actually-meaningful `track`. So the solution 
to this kind of problem is simply "Don't do that". 

-- 
Brent Royal-Gordon
Sent from my iPhone
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0155: Normalize Enum Case Representation

[Xiaodi Wu via swift-evolution]

Having watched this conversation from the sidelines, I just wanted to chime
in from a more distant view:

Originally, I thought this proposal was very nice because it made a good
argument as to why enum cases would benefit from being function-like. It
follows naturally that form should follow function, and therefore it's hard
to argue that the syntax shouldn't be "rectified."

But, given the latest discussions, it seems that there's a bunch of
round-peg-square-hole efforts going on precisely because enum cases
*aren't* very function-like in some key respects:

- John McCall gives a cogent reason why parameter names and argument labels
would be inconsistently used if they are put to the purpose that some have
proposed here for enum cases.

- There's a lot of bikeshedding as to pattern matching with argument
labels, as it seems that people generally agree that always requiring them
in that scenario would make the experience of using enums worse rather than
better. In fact, it seems that what's cited as a shortcoming in the
original proposal ("labels in patterns aren't enforced") is precisely what
we're trying to invent new sugar to duplicate.

Now, since we clearly want enum cases to be tuple-like in some respects
(pattern matching) but function-like in other respects, is swinging from
one extreme ("cases are tuples!") to the other ("cases are functions!") the
right thing to do? Does it really make the language more "consistent"?


On Mon, Feb 27, 2017 at 4:10 PM, Matthew Johnson via swift-evolution <
swift-evolution@swift.org> wrote:

>
> > On Feb 27, 2017, at 4:07 PM, Dave Abrahams via swift-evolution <
> swift-evolution@swift.org> wrote:
> >
> >
> > on Mon Feb 27 2017, Joe Groff  wrote:
> >
> >>> On Feb 24, 2017, at 9:26 PM, Daniel Duan  wrote:
> >>>
> >>> Before I start revising this proposal, there are a couple of open
> questions I’d like to discuss
> >> with the community and the core team.
> >>>
> >>> The first question relates to the purpose of having a “internal”
> >>> argument name. There are applications of such names in GADT (if we
> >>> ever get there) and perhaps the case-as-subtype-of-the-enum stories
> >>> on the list right now. Out side of these scenarios, however, such
> >>> names has few chances to be used. The one I can come up with, which
> >>> is also the “open” part of the question, is this: we can use the
> >>> internal names in pattern matching, as opposed to using the
> >>> labels. This seems to align with the subtyping/GADT use cases. Is
> >>> this a desirable outcome?
> >>
> >> Why would GADTs make internal argument names useful?
> >
> > I'll probably never win this fight, but I'm trying to get people to use
> > “parameter name” and “argument label” as the preferred terms.
>
> I like this terminology.  I’ll start using it.  Thanks for making an
> attempt to get everyone on the same page!  :)
>
> >
> >> They seem completely useless to me. Their "internal"-ness is
> >> compromised if you try to hang semantics off of them—they shouldn't
> >> have any impact on use sites.
> >>
> >>> The second open question is the syntax for “overloaded” cases. If we
> >>> decide to allow them, what should the patterns matching them look
> >>> like? I can think of one obvious-ish design where we make the
> >>> pattern look like the declaration and require types for
> >>> disambiguation. So the most verbose form of pattern would look
> >>> something like
> >>>
> >>> ```
> >>> case let .baseName(label0 name0: Type0, label1 name1: Type1)
> >>> ```
> >>
> >> By "overloaded", do you mean "same name different types", or "same
> >> base name, different argument names"?
> >
> > When you write "argument name," do you mean parameter name or argument
> > label?  This is an example of why I'd like us to settle on the other
> > terminology.
> >
> >> I think we should have a consistent naming model where the latter is
> >> never considered overloading. As an affordance to make pattern
> >> matching more concise, it seems reasonable to me to maybe say that a
> >> binding pattern matches a label with the same name, so that `case
> >> .foo(let bar, let bas)` can match `.foo(bar:bas:)`.
> >
> > SGTM
> >
> > --
> > -Dave
> > ___
> > 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] [Draft] Refining identifier and operator symbology (take 2)

[Xiaodi Wu via swift-evolution]

On Sun, Feb 26, 2017 at 11:50 AM, Nevin Brackett-Rozinsky via
swift-evolution  wrote:

> This looks very good Xiaodi, and I have a few thoughts about it.
>
> First, is the intent that Swift will follow future changes to Unicode
> operator recommendations, or that Swift will choose a “frozen in time” set
> of Unicode recommendations to adopt? If the former, then we will likely see
> source-breaking changes as Unicode evolves. And if the latter, then Swift’s
> choices are apt to diverge even more from Unicode’s over time.
>

Great question. I guess the text leaves the mechanics of forward
compatibility unsaid. The answer is: both.

With respect to Unicode identifiers, UAX#31 guarantees future compatibility
for ID_Start and ID_Continue. That is, anything that is currently valid in
ID_Start will be valid in ID_Start for all time. It is reasonable to expect
that the same experts will adopt that approach for their operator
recommendations in the future. Indeed, they have set themselves up fairly
well for this already: UAX#31 also guarantees that Pattern_Syntax
characters will never be moved into ID_Start or ID_Continue. Therefore, we
also have a guarantee that the approach for Swift's operators proposed here
will *never* overlap with Swift's identifier characters even as Unicode
evolves.

Second, it is well-established that programming operators do not have to be
> mathematical. For example, Swift uses the punctuation marks ‘!’, ‘?’, and
> ‘&’ as operators in its standard library. The approach described in your
> proposal does an excellent job at covering the core mathematical operator
> characters in Unicode, however it does not appear to make such an effort
> toward non-mathematical operators.
>
> Of particular note, given that ‘?’, ‘¿’, and ‘‽’ are operator characters,
> it seems inconsistent to omit ‘⸘’. Similarly, with ‘&’ an operator, one
> would expect ‘⅋’ to be as well. I see that “expanding the set of operator
> characters” is listed as a non-goal, however that does not make it an
> anti-goal, and the proposal indeed expands the set by adding ‘\’. Likewise
> “rectifying Unicode shortcomings” is listed as a non-goal, although the
> proposal incorporates some 16 characters for Swift 3 compatibility.
>

Expanding the set of valid operator characters by adding `\` is not a goal
for this proposal. However, it so happens that UTR#25 explicitly mentions
`\` as an operator. In fact, UTR#25 lists every one of Swift's ASCII
operators as mathematical operators not classified as [:Math:], minus `?`
but plus `\`. Therefore, if we agree that the alignment of Swift to Unicode
recommendations as closely as possible is a desirable goal, the most
intellectually honest set of ASCII operators would include `\`. Now, if
Swift-specific implementation concerns preclude its inclusion, then I
personally wouldn't fight it.

The proposal makes no attempt to define a "non-mathematical operator"
because, again, Unicode has no such definition--yet. There is no approach
of which I'm aware to achieving consensus on that topic, short of either
(a) waiting for more expert hands over at the Unicode Consortium; or (b) a
character-by-character survey of all symbols in Unicode by non-experts (I
count myself here) on this list, which is an explicit anti-goal of this
proposal. In anticipation of Unicode completing its work, this proposal
advances a design that (as I write above) makes possible the adoption of
future Unicode recommendations in a source-compatible way. The chief
mechanism by which this is guaranteed is by not assigning non-[:Math:]
Pattern_Syntax characters (emoji excepted) to either identifiers or
operators. It addresses the most common concern of those responding to an
earlier version of this proposal, who argued against restricting operators
in the interim to only ASCII characters (which would also be a
source-compatible approach that makes room for future Unicode
recommendations) because there is a set of non-ASCII characters that have
unambiguously the characteristics of "operatorlikeness" useful to enable a
more math-like syntax. The proposal here makes no effort to expand our
understanding of what an operator is beyond what's required for the Swift
standard library plus Unicode's somewhat imperfect classification of
mathematical symbols. Indeed, the proposal makes explicit the expectation
that Unicode experts will undertake that task.

The 20 characters included for Swift 3 compatibility have as their
objective only the preservation of Swift 3 source compatibility. They
represent an educated guess (based on public code samples and messages to
this list) as to what symbols are most likely to be used in real, shipping
Swift code, absent arguments against inclusion on other grounds. They are
not intended to represent any attempt at rationalization in alignment with
some Unicode-recommended criterion. As I mentioned, I'm eager to hear
feedback to the effect that some real, shipping code would be 

Re: [swift-evolution] [Pitch] Typed throws

[Matthew Johnson via swift-evolution]

Sent from my iPad

> On Feb 27, 2017, at 8:21 PM, Dave Abrahams  wrote:
> 
> 
>> on Mon Feb 27 2017, Matthew Johnson  wrote:
>> 
>> If you don't believe typed errors will improve your code or if you
>> just don't want to deal with typed errors, just don't use them!
> 
> As I've tried to point out, it's not that simple.  You have to consider
> the complexity cost of adding a feature, whether people will be able to
> understand how to use it properly and when to avoid it, and what effect
> that use will have on the programming ecosystem.

I guess I believe the community is pretty wise about this kind of thing and 
have confidence in it to use this well especially if we are willing to refine 
the model as we learn from experience.  Who knows, maybe I'm too optimistic.

> 
> -- 
> -Dave

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

Re: [swift-evolution] [Pitch] Typed throws

[Dave Abrahams via swift-evolution]

on Mon Feb 27 2017, Matthew Johnson  wrote:

> If you don't believe typed errors will improve your code or if you
> just don't want to deal with typed errors, just don't use them!

As I've tried to point out, it's not that simple.  You have to consider
the complexity cost of adding a feature, whether people will be able to
understand how to use it properly and when to avoid it, and what effect
that use will have on the programming ecosystem.

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

Re: [swift-evolution] [Pitch] Typed throws

[Dave Abrahams via swift-evolution]

on Mon Feb 27 2017, Daniel Leping  wrote:

> Well, as Dave pointed, you can very rarely recover from an error, which IMO
> is absolutely true.
>
> If your operation fails you don't really care unless you can recover. And
> you know your cases, which you can recover from (in reality one usually
> does it in optimization phase, though).
>
> What else do you need the type of error for at the very end of your call
> stack? In 90% you will tell the user "ah, sorry, something happened. Come
> back later" and log the error (if you haven't forgot it).
>
> In most cases the errors are not for recovering. They neither are to be
> presented to users. They are for developers to read the log/crash
> report/whatever else and analyze it. Most of the errors are for debugging
> purposes.

Disagreed, sorry.  When I said that recovery is rare, I meant that it is
generally done in a very few functions, not that it is rarely possible
at all.  If something goes wrong when editing a document, for example
full or network failure, you simply recover its previous state from the
undo stack.  Errors are *for* recoverable conditions.  If you're not
going to recover you might as well trap and save all the unwinding and
invariant preservation logic.

> I don't want to deal with cumbersome code the purpose of which is to just
> "obey the language rules". Unless I know how to recover I would rethrow it.
> Than catch at the top of the stack and log + show the user a nice "sorry"
> message without getting techy.
>
> On Tue, 28 Feb 2017 at 1:12 Matthew Johnson via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>>
>> > On Feb 27, 2017, at 5:01 PM, Dave Abrahams  wrote:
>> >
>> >
>> > on Mon Feb 27 2017, Matthew Johnson  wrote:
>> >
>> >>> On Feb 27, 2017, at 4:20 PM, Dave Abrahams 
>> wrote:
>> >>>
>> >>>
>> >>> I'm sorry, I don't see any substantive difference, based on what you've
>> >>> written here, between this feature and const.
>> >>
>> >> Let me give it one more shot and then I’ll drop it.  :)
>> >>
>> >> Const is viral because if an API does not declare its arguments const
>> >> it cannot be used by a caller who has a const argument.
>> >
>> > Unless the caller casts away const, thus erasing information that was
>> > previously encoded in the type system.
>>
>> Yes, of course.
>>
>> >
>> >> It is required in order to make an API as generally useful as
>> >> possible.
>> >>
>> >> Typed errors are not viral in this way because no callers are
>> >> prevented from calling an API regardless of whether it declares error
>> >> types or just throws Error like we have today.
>> >
>> > Unless the caller can recover (which is *very* rare) or it catches and
>> > rethrows one of the errors *it* declares, thus erasing information that
>> > was previously encoded in the type system.
>>
>> I view this as being fundamentally different than casting away const.
>> Casting away const says “I know better than the types”.
>>
>> Converting an error to a different type is extremely different.  It much
>> more similar to any other kind of value wrapper a library might create in
>> order to shield its users from being coupled to its implementation details
>> / dependencies.  This is not a way *around* the type system in the sense
>> that casting away const is.  It is a way of *using* the type system
>> (hopefully) to your advantage.
>>
>>
>>
>> >
>> >> Pressure to declare error types in your signature in order to make
>> >> your function as generally useful as possible does not exist.  Each
>> >> function is free to declare error types or not according to the
>> >> contract it wishes to expose.
>> >>
>> >> An argument can be made that community expectations might develop that
>> >> good APIs should declare error types and they could be considered
>> >> viral in this sense because any API that is simply declared `throws`
>> >> is dropping type information.  But I think this overstates the case.
>> >> The community appears to be very sensitive to the problems that can
>> >> arise when error types are too concrete, especially across module
>> >> boundaries.  I think we can learn to use the tool where it works well
>> >> and to avoid it where it causes problems.
>> >>
>> >>>
>> >>> --
>> >>> -Dave
>> >>
>> >
>> > --
>> > -Dave
>>
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>

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

Re: [swift-evolution] [Pitch] Typed throws

[Matthew Johnson via swift-evolution]

Sent from my iPad

> On Feb 27, 2017, at 7:19 PM, Daniel Leping  wrote:
> 
> Well, as Dave pointed, you can very rarely recover from an error, which IMO 
> is absolutely true.
> 
> If your operation fails you don't really care unless you can recover. And you 
> know your cases, which you can recover from (in reality one usually does it 
> in optimization phase, though).
> 
> What else do you need the type of error for at the very end of your call 
> stack? In 90% you will tell the user "ah, sorry, something happened. Come 
> back later" and log the error (if you haven't forgot it).
> 
> In most cases the errors are not for recovering. They neither are to be 
> presented to users. They are for developers to read the log/crash 
> report/whatever else and analyze it. Most of the errors are for debugging 
> purposes.
> 
> I don't want to deal with cumbersome code the purpose of which is to just 
> "obey the language rules". Unless I know how to recover I would rethrow it. 
> Than catch at the top of the stack and log + show the user a nice "sorry" 
> message without getting techy.

In order to provide a helpful experience to end users an app needs to know 
about what might have caused the error and therefore what might (or might not) 
resolve it, allowing the operation to succeed on a subsequent attempt.  This 
can influence the strategy an app uses to avoid bothering the user if it might 
be resolvable without user intervention and can also influence the content of 
the message presented to users if that is necessary.  

Indeed, many apps don't bother with this kind of detail and just treat all 
errors the same.  Personally, I find that to be an unfortunate state of affairs 
both as a user and as a developer.

Types can be useful in conveying this kind of information and abstracting low 
level details that are not helpful at higher levels in the stack.  Of course 
types are not the only way to convey this information.  But my experience is 
that untyped errors often result in libraries with poor documentation of error 
cases and not enough consideration of the error handling experience of users of 
the library in general.   That makes it very difficult to handle errors well.  
I have experiences like this in several languages and on several platforms, 
including Apple's.  

Typed errors are certainly no panacea but I believe they can be an important 
tool.  Experience in other languages has shown that to be the case for many 
people writing many kinds of software.

If you don't believe typed errors will improve your code or if you just don't 
want to deal with typed errors, just don't use them!  You will be able to 
continue using untyped throws just as you do today.  You can even do this if 
you use libraries that throw typed errors.


> 
>> On Tue, 28 Feb 2017 at 1:12 Matthew Johnson via swift-evolution 
>>  wrote:
>> 
>> > On Feb 27, 2017, at 5:01 PM, Dave Abrahams  wrote:
>> >
>> >
>> > on Mon Feb 27 2017, Matthew Johnson  wrote:
>> >
>> >>> On Feb 27, 2017, at 4:20 PM, Dave Abrahams  wrote:
>> >>>
>> >>>
>> >>> I'm sorry, I don't see any substantive difference, based on what you've
>> >>> written here, between this feature and const.
>> >>
>> >> Let me give it one more shot and then I’ll drop it.  :)
>> >>
>> >> Const is viral because if an API does not declare its arguments const
>> >> it cannot be used by a caller who has a const argument.
>> >
>> > Unless the caller casts away const, thus erasing information that was
>> > previously encoded in the type system.
>> 
>> Yes, of course.
>> 
>> >
>> >> It is required in order to make an API as generally useful as
>> >> possible.
>> >>
>> >> Typed errors are not viral in this way because no callers are
>> >> prevented from calling an API regardless of whether it declares error
>> >> types or just throws Error like we have today.
>> >
>> > Unless the caller can recover (which is *very* rare) or it catches and
>> > rethrows one of the errors *it* declares, thus erasing information that
>> > was previously encoded in the type system.
>> 
>> I view this as being fundamentally different than casting away const.  
>> Casting away const says “I know better than the types”.
>> 
>> Converting an error to a different type is extremely different.  It much 
>> more similar to any other kind of value wrapper a library might create in 
>> order to shield its users from being coupled to its implementation details / 
>> dependencies.  This is not a way *around* the type system in the sense that 
>> casting away const is.  It is a way of *using* the type system (hopefully) 
>> to your advantage.
>> 
>> 
>> 
>> >
>> >> Pressure to declare error types in your signature in order to make
>> >> your function as generally useful as possible does not exist.  Each
>> >> function is free to declare error types or not according to the
>> >> contract it wishes to expose.
>> >>
>> >> An 

Re: [swift-evolution] A Comprehensive Rethink of Access Levels in Swift

[Jonathan Hull via swift-evolution]

 What I like about ‘hidden’ vs export of nested submodules is that you can 
 freely intermix those declarations in your code (like you can with private 
 now).
>>> 
>>> Yeah, this is an advantage.  It’s not a bad idea, but it’s not a 
>>> replacement for submodules either.  They are complementary.  
>> 
>> Agreed.
>> 
>> What I would really like to see is Nevin’s proposal with a simplified 
>> version of yours providing the submodules, and something like ‘hidden’ 
>> replacing the idea of ‘export’.
> 
> Are you saying you want to see all submodules exposed externally 
> automatically?  Or are you only talking about non-top-level export?

In Nevin’s system (to the best of my understanding), Submodules don’t really 
have much to do with visibility except to define a boundary.  Things marked 
‘private' are visible within a submodule, but not outside of it.  Things marked 
‘internal’ are visible within the entire module, but not outside of it.  Things 
marked ‘public’ are visible everywhere.  

Submodules don’t have visibility of their own in this system (which is part of 
what I like about it). Once you start having to worry about the visibility of 
the submodule itself, it really complicates the model, and you find yourself 
thinking on a much more abstract level instead of writing code. 

>> In more detail, I really like just having ‘private’, ‘internal’, and 
>> ‘public’ where private means private to the submodule.  It is very simple 
>> and understandable.  I think having a single level of submodule using your 
>> ‘submodule’ syntax is the simplest way to provide those.  
> 
> I think there is going to be *a lot* of resistance to the idea of removing 
> file-level private.  Most people want to keep that, but just revert than name 
> to `private` like we had in Swift 2. 

As I said above, Nevin’s system redefines ‘private’ to always mean private to 
the enclosing submodule. If you have not defined an explicit submodule for your 
file, then the file itself is implicitly it’s own submodule (aka. the same 
behavior as fileprivate)


>> I think I would be ok with nested submodules as well, again using your 
>> syntax, as long as we have ‘private’ mean private within the current 
>> submodule (and children).  If we find we really do need parametrized private 
>> (or equivalent) to provide visibility to a specific parent scope, that is 
>> something that can be an additive (non-breaking) change later.  I think we 
>> will be able do pretty much everything we need to without it though.
> 
> I could be wrong, but I’d be willing to bet that in a submodule world you 
> would have a very vocal and large number of people complaining if we suggest 
> not including any of: module-wide visibility, submodule-wide visibility and 
> file-wide visibility.
These are all provided for under the proposal (with file-wide visibility for 
anonymous submodules).

If we wanted to allow nested submodules though, ‘private’ would still mean 
private to your containing submodule.  Other things in the submodule could see 
it, as could any child submodules, but anything outside the submodule could 
not.  What I am saying is that I don’t think we will need 
'private(submoduleName)’, but we can always add it in a non-breaking way if I 
am wrong about that.


>  There are certainly people who think that one or another of these is not 
> worth supporting but I don’t see anything near a consensus around avoiding 
> any one of these.  Each will have a very vocal group of proponents that I 
> believe (again I could be wrong) would be a majority with respect to that 
> particular scope.  
> 
> I can understand why somebody might prefer a style that avoids relying one of 
> these scopes (people have their idiosyncrasies after all).  What I have a 
> hard time understanding is why somebody would propose that *nobody* be able 
> to scope a symbol to one of these very physical and prominent scopes.

The only scope which would be lost is private to the type (what we currently 
call ‘private’ in Swift 3).  Basically it works exactly like Swift 2 did, but 
you have the added ability to extend the domain of private by using submodules…

I like your notation for defining submodules, and would like to see that added, 
as well as my idea of ‘hidden’ to cover the needs I talked about before.

Thanks,
Jon


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

Re: [swift-evolution] [Pitch] Typed throws

[Daniel Leping via swift-evolution]

Well, as Dave pointed, you can very rarely recover from an error, which IMO
is absolutely true.

If your operation fails you don't really care unless you can recover. And
you know your cases, which you can recover from (in reality one usually
does it in optimization phase, though).

What else do you need the type of error for at the very end of your call
stack? In 90% you will tell the user "ah, sorry, something happened. Come
back later" and log the error (if you haven't forgot it).

In most cases the errors are not for recovering. They neither are to be
presented to users. They are for developers to read the log/crash
report/whatever else and analyze it. Most of the errors are for debugging
purposes.

I don't want to deal with cumbersome code the purpose of which is to just
"obey the language rules". Unless I know how to recover I would rethrow it.
Than catch at the top of the stack and log + show the user a nice "sorry"
message without getting techy.

On Tue, 28 Feb 2017 at 1:12 Matthew Johnson via swift-evolution <
swift-evolution@swift.org> wrote:

>
> > On Feb 27, 2017, at 5:01 PM, Dave Abrahams  wrote:
> >
> >
> > on Mon Feb 27 2017, Matthew Johnson  wrote:
> >
> >>> On Feb 27, 2017, at 4:20 PM, Dave Abrahams 
> wrote:
> >>>
> >>>
> >>> I'm sorry, I don't see any substantive difference, based on what you've
> >>> written here, between this feature and const.
> >>
> >> Let me give it one more shot and then I’ll drop it.  :)
> >>
> >> Const is viral because if an API does not declare its arguments const
> >> it cannot be used by a caller who has a const argument.
> >
> > Unless the caller casts away const, thus erasing information that was
> > previously encoded in the type system.
>
> Yes, of course.
>
> >
> >> It is required in order to make an API as generally useful as
> >> possible.
> >>
> >> Typed errors are not viral in this way because no callers are
> >> prevented from calling an API regardless of whether it declares error
> >> types or just throws Error like we have today.
> >
> > Unless the caller can recover (which is *very* rare) or it catches and
> > rethrows one of the errors *it* declares, thus erasing information that
> > was previously encoded in the type system.
>
> I view this as being fundamentally different than casting away const.
> Casting away const says “I know better than the types”.
>
> Converting an error to a different type is extremely different.  It much
> more similar to any other kind of value wrapper a library might create in
> order to shield its users from being coupled to its implementation details
> / dependencies.  This is not a way *around* the type system in the sense
> that casting away const is.  It is a way of *using* the type system
> (hopefully) to your advantage.
>
>
>
> >
> >> Pressure to declare error types in your signature in order to make
> >> your function as generally useful as possible does not exist.  Each
> >> function is free to declare error types or not according to the
> >> contract it wishes to expose.
> >>
> >> An argument can be made that community expectations might develop that
> >> good APIs should declare error types and they could be considered
> >> viral in this sense because any API that is simply declared `throws`
> >> is dropping type information.  But I think this overstates the case.
> >> The community appears to be very sensitive to the problems that can
> >> arise when error types are too concrete, especially across module
> >> boundaries.  I think we can learn to use the tool where it works well
> >> and to avoid it where it causes problems.
> >>
> >>>
> >>> --
> >>> -Dave
> >>
> >
> > --
> > -Dave
>
> ___
> 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] [Draft] Package Manager Manifest API Redesign

[Daniel Dunbar via swift-evolution]

Oh, and to your later email:

The reason why we wanted product type to use subclasses, and not a type field, 
is that we imagine product types growing to encompass other things for which it 
does not make sense to share the fields across all other products. Right now 
the Product type looks very normalized because it only supports things with 
names and modules, but we imagine other types for which that is not true (e.g., 
flat sets of files, archives, frameworks, bundles, etc.).

 - Daniel

> On Feb 27, 2017, at 4:50 PM, Daniel Dunbar  wrote:
> 
> Hi David,
> 
> We discussed the leading-dot & capitalization issue today again... this was 
> already something we weren't really happy about, but had chosen to live with 
> (using the "identity" rule to determine what was a type and what wasn't). 
> However, as we talked it over more we:
> 1. Felt that for the product types, using .library vs .Library would be 
> reasonable and consistent with a user model of thinking of these like enums 
> (even though they won't actually be in practice, we will use factory 
> functions on Product to make the dot work and keep the space extensible).
> 2. Realized that using .target would be a useful change to make now if we 
> ever ended up needing to make the Targets array polymorphic (not something we 
> plan to do now, but it never hurts to have it be extensible).
> so we decided to go ahead and revise to a model where we use leading-dot + 
> lowercase for everything (except Package), including reverting 
> SystemPackageProvider to the `.brew(...)` style syntax.
> 
> Thanks for the feedback!
>  - Daniel
> 
>> On Feb 27, 2017, at 2:21 AM, Ankit Aggarwal via swift-build-dev 
>> > wrote:
>> 
>> Hi David,
>> 
>> Thanks for the feedback! Comments inline:
>> 
>> 
>> On Sun, Feb 26, 2017 at 5:08 AM, David Hart via swift-build-dev 
>> > wrote:
>> Was looking forward to this :) here are my comments:
>> 
>> On 25 Feb 2017, at 01:35, Rick Ballard via swift-evolution 
>> > wrote:
>> 
>>> Hi all,
>>> 
>>> Ankit, Daniel, Anders, Boris and I have a draft proposal in progress for a 
>>> Package.swift manifest API redesign for the Package Manager. We'll welcome 
>>> comments or discussion at this time. My hope is that we can get this 
>>> polished up and ready for evolution within the next week or so, but we'll 
>>> see how the conversation goes!
>>> 
>>> You can see the proposal in progress at 
>>> https://github.com/aciidb0mb3r/swift-evolution/blob/manifest-api-redesign/proposals/-package-manager-manifest-api-redesign.md
>>>  
>>> .
>>>  I'm also including the current version inline in this email.
>>> 
>>> Thanks,
>>> 
>>>- Rick
>>> 
>>> # Package Manager Manifest API Redesign
>>> 
>>> * Proposal: [SE-](-package-manager-manifest-api-redesign.md 
>>> )
>>> * Author: [Ankit Aggarwal](https://github.com/aciidb0mb3r 
>>> )
>>> * Review Manager: TBD
>>> * Status: **Discussion**
>>> 
>>> ## Introduction
>>> 
>>> This is a proposal for redesigning the `Package.swift` manifest APIs 
>>> provided
>>> by Swift Package Manager.  
>>> This proposal only redesigns the existing public APIs and does not add any
>>> new functionality; any API to be added for new functionality will happen in
>>> separate proposals.
>>> 
>>> ## Motivation
>>> 
>>> The `Package.swift` manifest APIs were designed prior to the [API Design
>>> Guidelines] (https://swift.org/documentation/api-design-guidelines/ 
>>> ), and their
>>> design was not reviewed by the evolution process. Additionally, there are
>>> several small areas which can be cleaned up to make the overall API more
>>> "Swifty".
>>> 
>>> We would like to redesign these APIs as necessary to provide clean,
>>> conventions-compliant APIs that we can rely on in the future. Because we
>>> anticipate that the user community for the Swift Package Manager will grow
>>> considerably in Swift 4, we would like to make these changes now, before
>>> more packages are created using the old API.
>>> 
>>> ## Proposed solution
>>> 
>>> Note: Access modifier is omitted from the diffs and examples for brevity. 
>>> The
>>> access modifier is `public` for all APIs unless specified.
>>> 
>>> * Remove `successor()` and `predecessor()` from `Version`.
>>> 
>>>These methods neither have well defined semantics nor are used a lot
>>>(internally or publicly). For e.g., the current implementation of
>>>`successor()` always just increases the patch version.
>>> 
>>> 
>>>
>>>  View diff
>>>  
>>>```diff
>>>struct Version 

Re: [swift-evolution] [swift-build-dev] [Draft] Package Manager Manifest API Redesign

[Daniel Dunbar via swift-evolution]

Hi David,

We discussed the leading-dot & capitalization issue today again... this was 
already something we weren't really happy about, but had chosen to live with 
(using the "identity" rule to determine what was a type and what wasn't). 
However, as we talked it over more we:
1. Felt that for the product types, using .library vs .Library would be 
reasonable and consistent with a user model of thinking of these like enums 
(even though they won't actually be in practice, we will use factory functions 
on Product to make the dot work and keep the space extensible).
2. Realized that using .target would be a useful change to make now if we ever 
ended up needing to make the Targets array polymorphic (not something we plan 
to do now, but it never hurts to have it be extensible).
so we decided to go ahead and revise to a model where we use leading-dot + 
lowercase for everything (except Package), including reverting 
SystemPackageProvider to the `.brew(...)` style syntax.

Thanks for the feedback!
 - Daniel

> On Feb 27, 2017, at 2:21 AM, Ankit Aggarwal via swift-build-dev 
>  wrote:
> 
> Hi David,
> 
> Thanks for the feedback! Comments inline:
> 
> 
> On Sun, Feb 26, 2017 at 5:08 AM, David Hart via swift-build-dev 
> > wrote:
> Was looking forward to this :) here are my comments:
> 
> On 25 Feb 2017, at 01:35, Rick Ballard via swift-evolution 
> > wrote:
> 
>> Hi all,
>> 
>> Ankit, Daniel, Anders, Boris and I have a draft proposal in progress for a 
>> Package.swift manifest API redesign for the Package Manager. We'll welcome 
>> comments or discussion at this time. My hope is that we can get this 
>> polished up and ready for evolution within the next week or so, but we'll 
>> see how the conversation goes!
>> 
>> You can see the proposal in progress at 
>> https://github.com/aciidb0mb3r/swift-evolution/blob/manifest-api-redesign/proposals/-package-manager-manifest-api-redesign.md
>>  
>> .
>>  I'm also including the current version inline in this email.
>> 
>> Thanks,
>> 
>>- Rick
>> 
>> # Package Manager Manifest API Redesign
>> 
>> * Proposal: [SE-](-package-manager-manifest-api-redesign.md 
>> )
>> * Author: [Ankit Aggarwal](https://github.com/aciidb0mb3r 
>> )
>> * Review Manager: TBD
>> * Status: **Discussion**
>> 
>> ## Introduction
>> 
>> This is a proposal for redesigning the `Package.swift` manifest APIs provided
>> by Swift Package Manager.  
>> This proposal only redesigns the existing public APIs and does not add any
>> new functionality; any API to be added for new functionality will happen in
>> separate proposals.
>> 
>> ## Motivation
>> 
>> The `Package.swift` manifest APIs were designed prior to the [API Design
>> Guidelines] (https://swift.org/documentation/api-design-guidelines/ 
>> ), and their
>> design was not reviewed by the evolution process. Additionally, there are
>> several small areas which can be cleaned up to make the overall API more
>> "Swifty".
>> 
>> We would like to redesign these APIs as necessary to provide clean,
>> conventions-compliant APIs that we can rely on in the future. Because we
>> anticipate that the user community for the Swift Package Manager will grow
>> considerably in Swift 4, we would like to make these changes now, before
>> more packages are created using the old API.
>> 
>> ## Proposed solution
>> 
>> Note: Access modifier is omitted from the diffs and examples for brevity. The
>> access modifier is `public` for all APIs unless specified.
>> 
>> * Remove `successor()` and `predecessor()` from `Version`.
>> 
>>These methods neither have well defined semantics nor are used a lot
>>(internally or publicly). For e.g., the current implementation of
>>`successor()` always just increases the patch version.
>> 
>> 
>>
>>  View diff
>>  
>>```diff
>>struct Version {
>>-func successor() -> Version
>> 
>>-func predecessor() -> Version
>>}
>>```
>>
>> 
>> * Make all properties of `Package` and `Target` mutable.
>> 
>>Currently, `Package` has three immutable and four mutable properties, and
>>`Target` has one immutable and one mutable property. We propose to make 
>> all
>>properties mutable to allow complex customization on the package object
>>after initial declaration.
>> 
>>
>>  View diff and example
>>  
>> 
>>  Diff:
>>```diff
>>final class Target {
>>-let name: String
>>+var name: String
>>}
>> 
>>final class Package {
>>-let name: String
>>+var name: String
>> 
>>-let 

[swift-evolution] 'T != Type' in where clause

[Rex Fenley via swift-evolution]

I often find myself running into situations where I'll receive "Ambiguous
use of..." for overloaded functions or operators. In every case these
situations would be easily solved if I could specify "Generic !=
CertainType" in the where clause of one of the overloads so I can
disambiguate the cases. Could this be added to language?

-- 

Rex Fenley  |  IOS DEVELOPER

Remind.com  |  BLOG 
 |  FOLLOW
US   |  LIKE US

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

Re: [swift-evolution] A Comprehensive Rethink of Access Levels in Swift

[Matthew Johnson via swift-evolution]

> On Feb 26, 2017, at 10:47 PM, Jonathan Hull  wrote:
> 
>> 
>> On Feb 25, 2017, at 2:41 PM, Matthew Johnson > > wrote:
>> 
>>> 
>>> On Feb 25, 2017, at 4:01 PM, Jonathan Hull >> > wrote:
>>> 
 
 On Feb 25, 2017, at 1:19 PM, Matthew Johnson > wrote:
> On Feb 25, 2017, at 2:54 PM, Jonathan Hull via swift-evolution 
> > wrote:
> +1000
> 
> This is the best of the proposals I have seen.  I think it works by 
> itself as a complete proposal, but since we are talking "comprehensive 
> rethink", there is one use case which most of the proposals seem to miss. 
>  
> 
> That is, what if I want to make a class which is both Public and 
> Subclassable, but I want to keep some of the implementation details 
> private to the class, while still allowing subclasses and extensions 
> (across the module boundary) to have access to those details.  A concrete 
> example of this is UIGestureRecognizer, which is intended to be 
> subclassed outside of its framework, but hides potentially catastrophic 
> things (like being able to set the state) from callers. This isn’t 
> currently possible in Swift AFAICT without importing from ObjC.
> 
> My solution to this has been to allow something to be marked ‘public 
> hidden’ or ‘hidden', which means that it is public/internal, but has it’s 
> visibility limited only to files which opt-in to seeing it with ‘import 
> hidden filename’ (instead of just ‘import filename’).  I think this is 
> the simplest way to provide this feature, which is sometimes very 
> necessary. It also captures authorial intent very nicely.
 
 My submodule proposal is able to support this use case.  You would just 
 put the symbols intended for subclasses in a separate submodule.  These 
 submodules could be exposed to users with any name you desire, regardless 
 of the internal structure of your module.  You could even arrange for 
 users to get all of the non-subclass-only symbols automatically when they 
 import your module but require explicit import of each individual 
 subclass-only submodule in places where it is needed.
>>> 
>>> I agree that this could also be solved with nested submodules
>> 
>> A minor note, but you would not need to nest them.  You could do it either 
>> way.
> 
> I can’t think of how to do this, but I trust you that it can.
> 
> 
>>> , but the current proposals all seem to add a lot of complexity. This 
>>> complexity does give you much finer grain control over visibility, but what 
>>> I like about Nevin’s proposal is that it is ‘just enough’ control with 
>>> minimal complexity.  
>> 
>> Determining what “just enough” is is obviously a very subjective thing.  :)  
>> Everyone seems to have their own opinion about this (more than usual) which 
>> is going to make it one of the more complicated discussions we’ll have on 
>> the list.
>> 
>> I worked very hard on my proposal to try to design a system that stays out 
>> of your way until you need the tools it offers.  That way nobody is faced 
>> with complexity unless they are deriving direct benefit from it, but when 
>> they need powerful tools those tools are available.  This is the idea of 
>> progressive disclosure (as I understand it).
> 
> True.  I would personally define “just enough” as easy for the 80% and 
> possible for the 98%.
> 
> I don’t think your proposal is bad at all.  I just like the simplicity of 
> Nevin’s a little more (especially with the confusion around ‘open’). In fact, 
> I would like to see you combine them a bit (see below).
> 
> 
>>> What I like about ‘hidden’ vs export of nested submodules is that you can 
>>> freely intermix those declarations in your code (like you can with private 
>>> now).
>> 
>> Yeah, this is an advantage.  It’s not a bad idea, but it’s not a replacement 
>> for submodules either.  They are complementary.  
> 
> Agreed.
> 
> What I would really like to see is Nevin’s proposal with a simplified version 
> of yours providing the submodules, and something like ‘hidden’ replacing the 
> idea of ‘export’.

Are you saying you want to see all submodules exposed externally automatically? 
 Or are you only talking about non-top-level export?

> 
> In more detail, I really like just having ‘private’, ‘internal’, and ‘public’ 
> where private means private to the submodule.  It is very simple and 
> understandable.  I think having a single level of submodule using your 
> ‘submodule’ syntax is the simplest way to provide those.  

I think there is going to be *a lot* of resistance to the idea of removing 
file-level private.  Most people want to keep that, but just revert than name 
to `private` like we had in Swift 2. 

Re: [swift-evolution] [Pitch] Typed throws

[Matthew Johnson via swift-evolution]

> On Feb 27, 2017, at 5:01 PM, Dave Abrahams  wrote:
> 
> 
> on Mon Feb 27 2017, Matthew Johnson  wrote:
> 
>>> On Feb 27, 2017, at 4:20 PM, Dave Abrahams  wrote:
>>> 
>>> 
>>> I'm sorry, I don't see any substantive difference, based on what you've
>>> written here, between this feature and const.
>> 
>> Let me give it one more shot and then I’ll drop it.  :)
>> 
>> Const is viral because if an API does not declare its arguments const
>> it cannot be used by a caller who has a const argument.  
> 
> Unless the caller casts away const, thus erasing information that was
> previously encoded in the type system.

Yes, of course.

> 
>> It is required in order to make an API as generally useful as
>> possible.
>> 
>> Typed errors are not viral in this way because no callers are
>> prevented from calling an API regardless of whether it declares error
>> types or just throws Error like we have today.  
> 
> Unless the caller can recover (which is *very* rare) or it catches and
> rethrows one of the errors *it* declares, thus erasing information that
> was previously encoded in the type system.

I view this as being fundamentally different than casting away const.  Casting 
away const says “I know better than the types”.

Converting an error to a different type is extremely different.  It much more 
similar to any other kind of value wrapper a library might create in order to 
shield its users from being coupled to its implementation details / 
dependencies.  This is not a way *around* the type system in the sense that 
casting away const is.  It is a way of *using* the type system (hopefully) to 
your advantage.



> 
>> Pressure to declare error types in your signature in order to make
>> your function as generally useful as possible does not exist.  Each
>> function is free to declare error types or not according to the
>> contract it wishes to expose.
>> 
>> An argument can be made that community expectations might develop that
>> good APIs should declare error types and they could be considered
>> viral in this sense because any API that is simply declared `throws`
>> is dropping type information.  But I think this overstates the case.
>> The community appears to be very sensitive to the problems that can
>> arise when error types are too concrete, especially across module
>> boundaries.  I think we can learn to use the tool where it works well
>> and to avoid it where it causes problems.
>> 
>>> 
>>> -- 
>>> -Dave
>> 
> 
> -- 
> -Dave

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

Re: [swift-evolution] [Pitch] Typed throws

[Dave Abrahams via swift-evolution]

on Mon Feb 27 2017, Matthew Johnson  wrote:

>> On Feb 27, 2017, at 4:20 PM, Dave Abrahams  wrote:
>> 
>> 
>> I'm sorry, I don't see any substantive difference, based on what you've
>> written here, between this feature and const.
>
> Let me give it one more shot and then I’ll drop it.  :)
>
> Const is viral because if an API does not declare its arguments const
> it cannot be used by a caller who has a const argument.  

Unless the caller casts away const, thus erasing information that was
previously encoded in the type system.

> It is required in order to make an API as generally useful as
> possible.
>
> Typed errors are not viral in this way because no callers are
> prevented from calling an API regardless of whether it declares error
> types or just throws Error like we have today.  

Unless the caller can recover (which is *very* rare) or it catches and
rethrows one of the errors *it* declares, thus erasing information that
was previously encoded in the type system.

> Pressure to declare error types in your signature in order to make
> your function as generally useful as possible does not exist.  Each
> function is free to declare error types or not according to the
> contract it wishes to expose.
>
> An argument can be made that community expectations might develop that
> good APIs should declare error types and they could be considered
> viral in this sense because any API that is simply declared `throws`
> is dropping type information.  But I think this overstates the case.
> The community appears to be very sensitive to the problems that can
> arise when error types are too concrete, especially across module
> boundaries.  I think we can learn to use the tool where it works well
> and to avoid it where it causes problems.
>
>> 
>> -- 
>> -Dave
>

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

Re: [swift-evolution] [Pitch] Typed throws

[Matthew Johnson via swift-evolution]

> On Feb 27, 2017, at 4:44 PM, Zach Waldowski via swift-evolution 
>  wrote:
> 
> On Mon, Feb 27, 2017, at 04:05 PM, Daniel Leping via swift-evolution wrote:
>> David, IMHO, all you say is absolutely true and typed throws might work 
>> well, but in theoretic idealistic world. In reality though, you end having 
>> more exception types than data types, feature cost rises exponentially and 
>> the code becomes cluttered with all the wrapping.
>> 
>> I seriously don't understand why would one even think of this feature after 
>> it's proven a bad practice by Java community. Even Java based languages 
>> (i.e. Scala) have dropped this "feature".
> 
> I share Daniel's concerns 100%. The Swift community is so (rightfully) 
> concerned about stability right now, and all I can see is how this could tie 
> the hands of a future API author.
> 
> I'd love to have those fears mollified. If Swift can noticeably improve on 
> the typed throws model (through type checking, conversion, some ABI 
> guarantees for changing errors, etc.), like Swift has for a lot of features 
> other languages have tried and had trouble with, we should definitely move 
> forward with typed throws. If we can't, it does a lot to hurt what I think is 
> the great success of Swift's error-handling model.

Do you have a sense of the criteria you would use to determine whether the 
improvements are satisfactory to you or not?

> 
> Zach
> z...@waldowski.me 
> 
> 
> ___
> 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] Typed throws

[Matthew Johnson via swift-evolution]

> On Feb 27, 2017, at 4:20 PM, Dave Abrahams  wrote:
> 
> 
> on Mon Feb 27 2017, Matthew Johnson  > wrote:
> 
>>> On Feb 27, 2017, at 10:48 AM, Dave Abrahams  wrote:
>>> 
>>> 
>>> on Mon Feb 27 2017, Matthew Johnson  wrote:
>>> 
>> 
> On Feb 27, 2017, at 12:32 AM, Dave Abrahams via swift-evolution 
>  wrote:
> 
> 
>> on Fri Feb 17 2017, Joe Groff  wrote:
>> 
>> Experience in other languages like Rust and Haskell that use
>> Result-based error propagation suggests that a single error type is
>> adequate, and beneficial in many ways. 
> 
> And experience in still others, like C++ and Java, suggests that
> using static types to restrict the kind of information a function can
> give you when an error occurs may actually be harmful.
 
 It seems to me that both can be true.  It is up to the author to
 determine which applies in a given use case.  I really don't think
 Swift should require those who understand where it is beneficial to
 use non-throwing functions that return a Result type if they wish to
 realize the benefits when they are relevant.
 
 My understanding of Chris's meaning of progressive disclosure is that
 the language should have powerful and general tools at its foundation
 that can be ignored until they are necessary for a particular problem.
>>> 
>>> For what problem is this feature necessary?
>> 
>> I was speaking about progressive disclosure generally.  You are right
>> that typed errors are not *necessary* for any problems.  Of course
>> that can be said about many language features.  Perhaps I should have
>> said "until they add value or clarity”.
>> 
>>> 
 In this case the powerful and general tool is typed errors.  The
 syntactic sugar allowing you to omit a type and therefore throw any
 error (typed as Error) allows users to ignore the more general tool
 when it isn't providing value.
 
 We should focus on educating users who wish to use this tool about the
 tradeoffs involved and how to think about what error type might be
 appropriate in different use cases rather than introduce an arbitrary
 (i.e. not technical) limitation prohibiting typed errors just because
 they can be badly used.  Understanding the tradeoffs is certainly not
 a beginner topic, but there are plenty of things in Swift that are not
 beginner topics.
>>> 
>>> In my experience, given an opportunity to encode something in the type
>>> system or categorize and annotate things using language constructs, most
>>> users will.  That's usually a great instinct, but not in this case, IMO.
>>> The hard problems of error recovery involve maintaining your program
>>> invariants, but this feature contributes nothing toward that end.  The
>>> one thing it *could* improve is the quality of error reporting to end
>>> users, but in practice that ends up devolving to dynamic lookups due to
>>> the need for localization.  So we truly gain very little from encoding
>>> this feature in the type system.
>> 
>> Error reporting and recovery are precisely where type errors can help.
>> I’ll give an example below.
>> 
>>> 
>>> This particular feature is viral in the same sense as C++ const, so I
>>> predict it will either see widespread use, which IMO would be harmful,
>>> or everyone will learn to avoid it.  Either way, it seems like a bad
>>> investment for the language.
>> 
>> I understand why you might make this comparison but I think there is
>> an important difference.
>> 
>> If I receive a const input I can only give that input to other things
>> that take a const.  It restricts my dependencies (what I can do with
>> the input), or conversely I have to abandon const or cast it away (!)
>> because my dependency isn’t declared as taking const.
>> 
>> With typed errors the situation is a little bit different.  My
>> signature is much more independent from that of my dependencies.
>> 
>> For example, I might have some dependencies which my users would
>> prefer to not be tightly coupled with that happen to throw errors.
>> For example, maybe I depend on an IO library and a parsing library.
>> These dependencies are subject to change in the future.  Rather than
>> let the errors propagate directly I wrap them in `enum MyLIbraryError
>> { case IOError(Error); case ParsingError(Error) }`.
>> 
>> This could provide a meaningful abstraction / grouping that helps the
>> client know what might or might not solve the problem.  
> 
> And it might not.  It might turn out that something you have to call
> throws an error that doesn't fit into either case.  Remember, the things
> you call may be closures or methods supplied to you by your clients.
> Then you have to resort to the equivalent of casting away const.
> 
>> It might be worth exposing the error type to callers giving them 

Re: [swift-evolution] [Pitch] Typed throws

[Zach Waldowski via swift-evolution]

On Mon, Feb 27, 2017, at 04:05 PM, Daniel Leping via swift-evolution wrote:
> David, IMHO, all you say is absolutely true and typed throws might
> work well, but in theoretic idealistic world. In reality though, you
> end having more exception types than data types, feature cost rises
> exponentially and the code becomes cluttered with all the wrapping.
> 

> I seriously don't understand why would one even think of this feature
> after it's proven a bad practice by Java community. Even Java based
> languages (i.e. Scala) have dropped this "feature".


I share Daniel's concerns 100%. The Swift community is so (rightfully)
concerned about stability right now, and all I can see is how this could
tie the hands of a future API author.


I'd love to have those fears mollified. If Swift can noticeably improve
on the typed throws model (through type checking, conversion, some ABI
guarantees for changing errors, etc.), like Swift has for a lot of
features other languages have tried and had trouble with, we should
definitely move forward with typed throws. If we can't, it does a lot to
hurt what I think is the great success of Swift's error-handling model.


Zach

z...@waldowski.me




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

Re: [swift-evolution] [Re-Review] SE-0104: Protocol-oriented integers

[Joe Groff via swift-evolution]

> On Feb 27, 2017, at 11:05 AM, Jordan Rose via swift-evolution 
>  wrote:
> 
> 
>> On Feb 25, 2017, at 07:06, Ben Rimmington via swift-evolution 
>>  wrote:
>> 
>> 
>> 
>>> On 24 Feb 2017, at 02:05, Ben Cohen wrote:
>>> 
>>> Regarding the “Number” protocol: it was felt this is likely to cause 
>>> confusion with NSNumber, given the NS-prefix-dropping versions of other 
>>> Foundation types indicate a value-typed concrete type equivalent, which 
>>> this won’t be. The recommendation is to use “Numeric" instead.
>> 
>> Does the `Error` protocol cause confusion with the `NSError` class?
>> 
>> I think `Number` is better than `Numeric`, because it is consistent with 
>> `SignedNumber`.
> 
> Error and NSError are actually related types, like String and NSString, and 
> are used in roughly the same way. Numeric and NSNumber serve very different 
> purposes: the former is a protocol for various operations, and the latter is 
> a semi-type-erased class box around a *cough* numeric value that 
> (deliberately) doesn't implement most of the operations in the protocol.

However, without doing anything, Numeric itself could serve the same 
type-erased box purpose. Since most arithmetic operations require `Self` 
arguments, they naturally wouldn't be available on the Numeric existential 
(unless someone designed and implemented an extension that handled 
up-conversion among arbitrary numeric types in the vein of Scheme's number 
tower or something like that). This seems like one place where that behavior 
would be desirable.

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

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0155: Normalize Enum Case Representation

[Matthew Johnson via swift-evolution]

> On Feb 27, 2017, at 4:07 PM, Dave Abrahams via swift-evolution 
>  wrote:
> 
> 
> on Mon Feb 27 2017, Joe Groff  wrote:
> 
>>> On Feb 24, 2017, at 9:26 PM, Daniel Duan  wrote:
>>> 
>>> Before I start revising this proposal, there are a couple of open questions 
>>> I’d like to discuss
>> with the community and the core team.
>>> 
>>> The first question relates to the purpose of having a “internal”
>>> argument name. There are applications of such names in GADT (if we
>>> ever get there) and perhaps the case-as-subtype-of-the-enum stories
>>> on the list right now. Out side of these scenarios, however, such
>>> names has few chances to be used. The one I can come up with, which
>>> is also the “open” part of the question, is this: we can use the
>>> internal names in pattern matching, as opposed to using the
>>> labels. This seems to align with the subtyping/GADT use cases. Is
>>> this a desirable outcome?
>> 
>> Why would GADTs make internal argument names useful? 
> 
> I'll probably never win this fight, but I'm trying to get people to use
> “parameter name” and “argument label” as the preferred terms.

I like this terminology.  I’ll start using it.  Thanks for making an attempt to 
get everyone on the same page!  :)

> 
>> They seem completely useless to me. Their "internal"-ness is
>> compromised if you try to hang semantics off of them—they shouldn't
>> have any impact on use sites.
>> 
>>> The second open question is the syntax for “overloaded” cases. If we
>>> decide to allow them, what should the patterns matching them look
>>> like? I can think of one obvious-ish design where we make the
>>> pattern look like the declaration and require types for
>>> disambiguation. So the most verbose form of pattern would look
>>> something like
>>> 
>>> ```
>>> case let .baseName(label0 name0: Type0, label1 name1: Type1)
>>> ```
>> 
>> By "overloaded", do you mean "same name different types", or "same
>> base name, different argument names"? 
> 
> When you write "argument name," do you mean parameter name or argument
> label?  This is an example of why I'd like us to settle on the other
> terminology.
> 
>> I think we should have a consistent naming model where the latter is
>> never considered overloading. As an affordance to make pattern
>> matching more concise, it seems reasonable to me to maybe say that a
>> binding pattern matches a label with the same name, so that `case
>> .foo(let bar, let bas)` can match `.foo(bar:bas:)`.
> 
> SGTM
> 
> -- 
> -Dave
> ___
> 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-evolution-announce] [Review] SE-0155: Normalize Enum Case Representation

[Dave Abrahams via swift-evolution]

on Mon Feb 27 2017, Matthew Johnson  wrote:

>> On Feb 27, 2017, at 12:46 PM, Joe Groff  wrote:
>> 
>> That still feels like it's going against the behavior of the binding
>> name in other declarations. Personally, `case .playing(with: let x)`
>> doesn't bother me that much, especially since the IDE ought to be
>> able to splat that out for you.
>
> It depends on how verbose the label is.  :)  

Yeah, how hard something is to type is very rarely more important than
how hard it is to read.

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

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0155: Normalize Enum Case Representation

[Dave Abrahams via swift-evolution]

on Mon Feb 27 2017, Joe Groff  wrote:

>> On Feb 24, 2017, at 9:26 PM, Daniel Duan  wrote:
>> 
>> Before I start revising this proposal, there are a couple of open questions 
>> I’d like to discuss
> with the community and the core team.
>> 
>> The first question relates to the purpose of having a “internal”
>> argument name. There are applications of such names in GADT (if we
>> ever get there) and perhaps the case-as-subtype-of-the-enum stories
>> on the list right now. Out side of these scenarios, however, such
>> names has few chances to be used. The one I can come up with, which
>> is also the “open” part of the question, is this: we can use the
>> internal names in pattern matching, as opposed to using the
>> labels. This seems to align with the subtyping/GADT use cases. Is
>> this a desirable outcome?
>
> Why would GADTs make internal argument names useful? 

I'll probably never win this fight, but I'm trying to get people to use
“parameter name” and “argument label” as the preferred terms.

> They seem completely useless to me. Their "internal"-ness is
> compromised if you try to hang semantics off of them—they shouldn't
> have any impact on use sites.
>
>> The second open question is the syntax for “overloaded” cases. If we
>> decide to allow them, what should the patterns matching them look
>> like? I can think of one obvious-ish design where we make the
>> pattern look like the declaration and require types for
>> disambiguation. So the most verbose form of pattern would look
>> something like
>> 
>> ```
>> case let .baseName(label0 name0: Type0, label1 name1: Type1)
>> ```
>
> By "overloaded", do you mean "same name different types", or "same
> base name, different argument names"? 

When you write "argument name," do you mean parameter name or argument
label?  This is an example of why I'd like us to settle on the other
terminology.

> I think we should have a consistent naming model where the latter is
> never considered overloading. As an affordance to make pattern
> matching more concise, it seems reasonable to me to maybe say that a
> binding pattern matches a label with the same name, so that `case
> .foo(let bar, let bas)` can match `.foo(bar:bas:)`.

SGTM

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

Re: [swift-evolution] [Re-Review] SE-0104: Protocol-oriented integers

[Jonathan Hull via swift-evolution]

+1 to all of this.  I completely support the proposal now.

Thanks,
Jon

> On Feb 23, 2017, at 6:05 PM, Ben Cohen via swift-evolution 
>  wrote:
> 
> Hi everyone,
> 
> The core team met and reviewed the discussion of this proposal so far, and 
> had the following mid-review feedback to relay back to the list:
> 
> Regarding the “Number” protocol: it was felt this is likely to cause 
> confusion with NSNumber, given the NS-prefix-dropping versions of other 
> Foundation types indicate a value-typed concrete type equivalent, which this 
> won’t be. The recommendation is to use “Numeric" instead.
> Regarding the question of the trailing argument to distinguish 
> overflow-checking vs expanding versions of multiplied: rather than add an 
> enum or use the void trick in order to do this via arguments, it is better to 
> just distinguish the two functions via different base names.
> Regarding restoring the BitwiseOperations protocol – the team feels that the 
> bitset use case can be modeled with SetAlgebra rather than retaining a 
> protocol with only bitwise operators.
> popcount – although this is a term of art, in general it’s best to avoid 
> abbreviations, so the suggestion is to rename it populationCount, which also 
> helps settle whether the “c” should be capitalized and confusion over the 
> other meaning of “pop".
> 
> - Ben
> 
> 
>> On Feb 17, 2017, at 5:45 PM, Joe Groff via swift-evolution 
>> > wrote:
>> 
>> Hello Swift community,
>> 
>> The re-review of SE-0104 "Protocol-oriented integers" begins now and runs 
>> through February 25, 2017. This proposal was accepted for Swift 3, but was 
>> not implemented in time for the release. The revised proposal is available 
>> here:
>> 
>>  
>> https://github.com/apple/swift-evolution/blob/master/proposals/0104-improved-integers.md
>>  
>> 
>> 
>> Reviews are an important part of the Swift evolution process. All reviews 
>> should be sent to the swift-evolution mailing list at
>> 
>>  https://lists.swift.org/mailman/listinfo/swift-evolution 
>> 
>> 
>> or, if you would like to keep your feedback private, directly to the review 
>> manager. When replying, please try to keep the proposal link at the top of 
>> the message:
>> 
>>  Proposal link:
>>  
>> https://github.com/apple/swift-evolution/blob/master/proposals/0104-improved-integers.md
>>  
>> 
>>  
>>  Reply text
>> 
>>  Other replies
>> 
>> What goes into a review?
>> 
>> The goal of the review process is to improve the proposal under review 
>> through constructive criticism and, eventually, determine the direction of 
>> Swift. When writing your review, here are some questions you might want to 
>> answer in your review:
>> 
>>  • What is your evaluation of the proposal?
>>  • Is the problem being addressed significant enough to warrant a change 
>> to Swift?
>>  • Does this proposal fit well with the feel and direction of Swift?
>>  • If you have used other languages or libraries with a similar feature, 
>> how do you feel that this proposal compares to those?
>>  • How much effort did you put into your review? A glance, a quick 
>> reading, or an in-depth study?
>> 
>> More information about the Swift evolution process is available at
>> 
>> https://github.com/apple/swift-evolution/blob/master/process.md 
>> 
>> 
>> Thank you,
>> 
>> -Joe Groff
>> Review Manager
>> ___
>> 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] Make swift enum string available to Objc

[Derrick Ho via swift-evolution]

NS_EXTENSIBLE_STRING_ENUM
Turns a groups of NSStrings into a struct.

What do you suggest for the reverse?
On Mon, Feb 27, 2017 at 4:39 PM Zach Waldowski via swift-evolution <
swift-evolution@swift.org> wrote:

> -1 as written due to the impedance mismatch with importing NS_STRING_ENUM
> and NS_EXTENSIBLE_STRING_ENUM. Exporting to Objective-C should export a
> typedef and several constants, not a class. Exporting generated accessors
> to Objective-C is unnecessary as you have -isEqual: and -hashValue on
> NSString over there.
>
> I'm not sure how technically feasible it is to identify "a struct with a
> single field conforming to RawRepresentable" to make it compatible with
> @objc, though I'm not really a compiler person.
>
> Other than that, I like the idea. I don't believe any of the annotations
> to make Objective-C code better in Swift should be one-way.
>
> Sincerely,
>   Zachary Waldowski
>   z...@waldowski.me
>
>
> On Sun, Feb 26, 2017, at 01:21 PM, Derrick Ho via swift-evolution wrote:
>
> I updated my proposal
> 
> to reflect the community's desire to build on @objc instead of adding a new
> attribute @objcstring.
>
> I've included it below for convenience:
>
> Swift Enum strings ported to Objective-c
>
>- Proposal: SE-
>
> 
>- Authors: Derrick Ho 
>- Review Manager: TBD
>- Status: Awaiting review
>
> *During the review process, add the following fields as needed:*
>
>- Decision Notes: Rationale
>
> 
>- Previous Proposal: SE-0033
>
> 
>
>
> 
> Introduction
>
> We should allow swift-enum-strings and swift-struct-strings to be bridged
> to objective-c. We can use the following notation:
>
> @objc enum Planets: String { case Mercury }
>
> @objc struct Food: String { public static let hamburger = Food(rawValue:
> "hamburger") }
>
> Creating a bridgable version will allow objective-c to enjoy some of the
> benefits that swift enjoys.
>
> Swift-evolution thread: Discussion
> 
>  Discussion
> 
>
> 
> Motivation
>
> NS_STRING_ENUM and NS_EXSTENSIBLE_STRING_ENUM are annotations that you can
> add to an objective-c global string. The annotations will make swift
> interpret the objective-c global strings as enum and structs respectively
> in theory. But it actually doesn't ever create enums
> .
>
> The problem seems to stem from the conversion from objc to swift. It might
> be more fruitful to make a conversion from swift to objc.
>
> However, what if we take it a step further? Turning a swift-string-enum
> into a bunch of global NSStrings really limits its power. There are many
> classes written by apple that are structs in swift but become classes in
> objective-c (i.e. String becomes NSString, Date becomes NSDate, Array
> becomes NSArray, etc). There is a special bridging mechanism that allows
> this to be possible. I think we should expand on that.
>
> Proposed
> solution
>
> // `@objc` and `String` can be applied to an enum to make it available to 
> objective-c:
> //
> @objc
> public enum Food: String {
>case Calamari
>case Fish
> }
>
> // This can be ported over to Objective-c as an objective-c class
>
> @interface Food: NSObject
>
> @property (readonly) NSString *_Nonnull rawValue;
>
> - (instancetype _Nullable)initWithRawValue:(NSString *_Nonnull)rawValue;
>
> + (instanceType _Nonnull)Calamari;
> + (instanceType _Nonnull)Fish;
>
> @end
>
>
> // `@objc` and `String` can be applied to a struct to make it available to 
> objective-c:
> //
>
> @objc
> public struct Planets: String {
>   public let rawValue: String //<- This should be implicit and the user 
> should not need to add it
>   init(rawValue: String) { self.rawValue = rawValue } //<- This should be 
> implicit and the user should not need to add it
>
>   public static let Earth = Planets(rawValue: "Earth") //<- user defines these
>   public static let Venus = Planets(rawValue: "Venus") //<- user defines these
> }
>
> // This can be ported over to 

Re: [swift-evolution] [pitch] Variadic Arguments should accept Arrays

[Jose Cheyo Jimenez via swift-evolution]

> On Feb 27, 2017, at 1:20 PM, Tino Heth <2...@gmx.de> wrote:
> 
>> These is very unfortunate as a solution for “spreading” a collection or 
>> tuple so that It can be applied to function taking a variadic.
>> It makes sense on the declaration site but not on the call site. 
>> 
>> someFunc(@nonVariadic [1])  
>> someFunc(@variadic [1]) 
>> 
>> There is nothing special about variadic/ spreading that would warrant an 
>> attribute. 
>> 
>> I think using attributes is not different than using a keyword like c# uses. 
>> http://stackoverflow.com/questions/7580277/why-use-the-params-keyword 
>> 
>> 
>> Do we really want to tag every array/tuple with a @variadic or @nonVariadic 
>> tag when packing and unpacking parameters?
>> 
>> variadic/ spreading (AKA packing / unpacking ) is a well known concept to 
>> most languages. 
> 
> I have the impression there is a misunderstanding about the proposal:
> It would not only make the variadics-syntax superflous, but also the whole 
> splatting-magic.
> There would only be functions that accept arrays, and you could freely choose 
> to feed them a comma-seperated list instead.
> The attribute would be written in the function declaration only — and we 
> could even decide that it isn't needed at all, and simply accept lists 
> wherever an array is expected.

Perhaps. Implicit splat behavior was removed for Tuples; I don’t see why we 
would reintroduce it for Array like constructs. 
https://github.com/apple/swift-evolution/blob/master/proposals/0029-remove-implicit-tuple-splat.md#alternatives-considered
 


I am in favor in explicit splat behavior but I don’t see it happening anytime 
soon. Its tagged as low priority.  

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

Re: [swift-evolution] [Pitch] Typed throws

[Matthew Johnson via swift-evolution]

> On Feb 27, 2017, at 3:34 PM, Joe Groff via swift-evolution 
>  wrote:
> 
> 
>> On Feb 27, 2017, at 4:19 AM, Daniel Leping via swift-evolution 
>> > wrote:
>> 
>> 
>> On Mon, 27 Feb 2017 at 8:44 Dave Abrahams via swift-evolution 
>> > wrote:
>> 
>> on Fri Feb 17 2017, Joe Groff > > wrote:
>> 
>> > Experience in other languages like Rust and Haskell that use
>> > Result-based error propagation suggests that a single error type is
>> > adequate, and beneficial in many ways.
>> 
>> 
>> And experience in still others, like C++ and Java, suggests that
>> using static types to restrict the kind of information a function can
>> give you when an error occurs may actually be harmful.
>> +1 here. It becomes wrapping over wrapping over wrapping. Try doing a big 
>> app in Java (i.e. some kind of layered server) and you'll understand 
>> everything. Ones who tried and still want it - well, there are different 
>> tastes out there.
> 
> OTOH, people *don't* seem to have these problems with Rust and functional 
> languages with value-oriented error handling. This could be partly because 
> there's a greater focus on fully-closed systems in those communities where 
> resilience isn't a concern, and you can usually evolve all your use sites if 
> you need to break an API, whereas C++ and Java projects are more likely to 
> incorporate black-box components from multiple sources. Having affordances 
> for unwinding with a well-typed error *within* a component seems like a 
> generally useful thing; Haskell has do notation and Rust tosses macros at the 
> problem to hide the propagation boilerplate, after all.

+1.  There are places where typed errors are very useful and places where they 
can cause problems (as with many features a programming language can have).

> 
> -Joe
> ___
> 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] Typed throws

[Matthew Johnson via swift-evolution]

> On Feb 27, 2017, at 1:46 PM, David Waite via swift-evolution 
>  wrote:
> 
> IMHO, there are two kinds of responses to errors - a specific response, and a 
> general one. Only the calling code knows how it will deal with errors, so a 
> “typed throws” is the function guessing possible calling code behavior.
> 
> The problem is, that gives four possible combinations - two where the 
> function guesses correctly, and two where it doesn’t. The most damaging is 
> when it suspects a caller doesn’t care about the error, when the caller 
> actually does. This is unwanted wrapping.
> 
> To provide an example, imagine a library that parses JSON. It has several 
> errors indicating JSON syntactic errors, and an “other” for representing 
> errors on the input stream. It wraps the input stream errors so that it can 
> provide a closed set of errors to the caller.
> 
> The caller is responsible for returning a data set. It doesn’t think that 
> code calling ‘it” cares about JSON syntactic errors, merely that the object 
> was not able to be restored. It returns its own wrapped error.
> 
> However, the original caller knows it is loading from disk. If the problem is 
> due to an issue such as access permissions, It has to know implementation 
> details of the API it called if it wishes to dive through the wrapped errors 
> to find out if the problem was filesystem related.
> 
> Add more layers, and it can be very mysterious why a call failed. Java at 
> least captures stack traces in this case to aid in technical support in 
> diagnosing the error.
> 
> Wrapping exceptions also prevents an aggregate of errors from different 
> subsystems being handled as a category, such as having a catch block handle 
> RecoverableError generically

Fwiw, I think wrapping errors is something that people are sometimes going to 
want to do regardless of whether they are typed or not.  Maybe the solution is 
to better support wrapping errors by focusing on the problems that wrapping 
causes.  For example, we could do something like this to make it easier to get 
at the original error:

protocol Error {
  // The error directly underlying this error.
  // Ideally the compiler would synthesize an implementation for enums 
conforming to `Error`
  // If `self` is a case that has an associate value which is or conforms to 
`Error` that error would be returned, otherwise `nil` would be returned.
  var underlyingError: Error? { get }

  // The original error underlying *all* layers of wrapping.
  // If underlyingError is non-nil this is also non-nil.
  var originalError: Error { get }
}
extension Error {
var underlyingError: Error? { 
  return nil
}
var originalError: Error {
  return underlyingError?.originalError ?? underlyingError ?? self
}
}

We could even provide syntactic sugar for catch sites that want to deal with 
the original error rather than the wrapped error if that is an important use 
case.

> 
> An interesting solution that has emerged in Ruby to keep library authors from 
> wrapping exceptions is by decorating the existing exception. Exceptions are 
> caught via pattern matching (same as in Swift), so rather than wrap an 
> extension, they extend the error instance with a library-specific module 
> (e.g. swift protocol). So while the error may be a IOError in ruby, you can 
> still catch it via ‘rescue JSONError’
> 
> Trying to specify the exact errors becomes even more destructive with 
> protocols and closures, where the person defining the interface knows neither 
> which errors the implementor of the call will throw, nor necessarily if the 
> caller will want to implement specific behavior on those errors. This in my 
> personal Java coding experience almost always leads to wrapping in some 
> protocol-specific Exception type which exposes minimal information to the 
> caller, or exposing your errors in some unrelated type like IOException which 
> was declared based on the author’s experience of possible exceptions.
> 
> -DW
>  
>> On Feb 27, 2017, at 5:19 AM, Daniel Leping via swift-evolution 
>> > wrote:
>> 
>> 
>> On Mon, 27 Feb 2017 at 8:44 Dave Abrahams via swift-evolution 
>> > wrote:
>> 
>> on Fri Feb 17 2017, Joe Groff > > wrote:
>> 
>> > Experience in other languages like Rust and Haskell that use
>> > Result-based error propagation suggests that a single error type is
>> > adequate, and beneficial in many ways.
>> 
>> 
>> And experience in still others, like C++ and Java, suggests that
>> using static types to restrict the kind of information a function can
>> give you when an error occurs may actually be harmful.
>> +1 here. It becomes wrapping over wrapping over wrapping. Try doing a big 
>> app in Java (i.e. some kind of layered server) and you'll understand 
>> everything. 

Re: [swift-evolution] [pitch] Make swift enum string available to Objc

[Zach Waldowski via swift-evolution]

-1 as written due to the impedance mismatch with importing
NS_STRING_ENUM and NS_EXTENSIBLE_STRING_ENUM. Exporting to Objective-C
should export a typedef and several constants, not a class. Exporting
generated accessors to Objective-C is unnecessary as you have -isEqual:
and -hashValue on NSString over there.


I'm not sure how technically feasible it is to identify "a struct with a
single field conforming to RawRepresentable" to make it compatible with
@objc, though I'm not really a compiler person.


Other than that, I like the idea. I don't believe any of the annotations
to make Objective-C code better in Swift should be one-way.


Sincerely,

  Zachary Waldowski

  z...@waldowski.me





On Sun, Feb 26, 2017, at 01:21 PM, Derrick Ho via swift-evolution wrote:
> I updated my proposal[1] to reflect the community's desire to build on
> @objc instead of adding a new attribute @objcstring.
> 

> I've included it below for convenience:

> 

> Swift Enum strings ported to Objective-c


>  * Proposal: SE-[2]
>  * Authors: Derrick Ho[3]
>  * Review Manager: TBD
>  * Status: Awaiting review
> *During the review process, add the following fields as needed:*


>  * Decision Notes: Rationale[4]
>  * Previous Proposal: SE-0033[5]
> Introduction



> We should allow swift-enum-strings and swift-struct-strings to be
> bridged to objective-c. We can use the following notation:
> @objc enum Planets: String { case Mercury }



> @objc struct Food: String { public static let hamburger =
> Food(rawValue: "hamburger") }
> Creating a bridgable version will allow objective-c to enjoy some of
> the benefits that swift enjoys.
> Swift-evolution thread: Discussion[6] Discussion[7]



> Motivation



> NS_STRING_ENUM and NS_EXSTENSIBLE_STRING_ENUM are annotations that you
> can add to an objective-c global string. The annotations will make
> swift interpret the objective-c global strings as enum and structs
> respectively in theory. But it actually doesn't ever create enums[8].
> The problem seems to stem from the conversion from objc to swift. It
> might be more fruitful to make a conversion from swift to objc.
> However, what if we take it a step further? Turning a swift-string-
> enum into a bunch of global NSStrings really limits its power. There
> are many classes written by apple that are structs in swift but
> become classes in objective-c (i.e. String becomes NSString, Date
> becomes NSDate, Array becomes NSArray, etc). There is a special
> bridging mechanism that allows this to be possible. I think we should
> expand on that.
> Proposed solution


> // `@objc` and `String` can be applied to an enum to make it available
> to objective-c: // @objc public enum Food: String { case Calamari case
> Fish }  // This can be ported over to Objective-c as an objective-c
> class  @interface Food: NSObject  @property (readonly) NSString
> *_Nonnull rawValue;  - (instancetype
> _Nullable)initWithRawValue:(NSString *_Nonnull)rawValue;  +
> (instanceType _Nonnull)Calamari; + (instanceType _Nonnull)Fish;  @end

>
> // `@objc` and `String` can be applied to a struct to make it
> available to objective-c: //  @objc public struct Planets: String {
> public let rawValue: String //<- This should be implicit and the user
> should not need to add it init(rawValue: String) { self.rawValue =
> rawValue } //<- This should be implicit and the user should not need
> to add it  public static let Earth = Planets(rawValue: "Earth") //<-
> user defines these public static let Venus = Planets(rawValue:
> "Venus") //<- user defines these }  // This can be ported over to objective-
> c as a class  @interface Planets: NSObject - (instancetype
> _Nonnull)initWithRawValue:(NSString *_Nonnull)rawValue;  +
> (instancetype)Earth; + (instancetype)Venus; @end
>
> The difference between a swift-enum-string and a swift-struct-string
> is that swift-enum-string provides a failable initializer while swift-struct-
> string provides a non-failable initializer.
> Detailed design



> swift-string-enum - case/string translations



> A swift-enum-string, is created with cases and it has an implicit
> string value based on the name of the case. The user may also add a
> name that does not equal the name of the case.


> // Swift @objc public enum Food: String { case Calamari case Fish =
> "Flounder" //<-- User wants Fish to be Flounder }  // Objective-c
> @interface Food: NSObject  @property (readonly) NSString *_Nonnull
> rawValue;  + (instanceType _Nonnull)Calamari; + (instanceType
> _Nonnull)Fish;  @end  @implementation Food + (instanceType
> _Nonnull)Calamari { return [[Food alloc]
> initWithRawValue:@"Calimari"]; } + (instanceType _Nonnull)Fish {
> return [[Food alloc] initWithRawValue:@"Flounder"]; } //<-- Fisher
> contains Flounder @end
>
> swift-string-enum - failable initializer



> A swift-enum-string has the ability to be initialized with a string.
> If the string matches one of the possible cases, then it returns it,
> otherwise it will return nil. This 

Re: [swift-evolution] [Pitch] Typed throws

[Joe Groff via swift-evolution]

> On Feb 27, 2017, at 4:19 AM, Daniel Leping via swift-evolution 
>  wrote:
> 
> 
> On Mon, 27 Feb 2017 at 8:44 Dave Abrahams via swift-evolution 
> > wrote:
> 
> on Fri Feb 17 2017, Joe Groff  > wrote:
> 
> > Experience in other languages like Rust and Haskell that use
> > Result-based error propagation suggests that a single error type is
> > adequate, and beneficial in many ways.
> 
> 
> And experience in still others, like C++ and Java, suggests that
> using static types to restrict the kind of information a function can
> give you when an error occurs may actually be harmful.
> +1 here. It becomes wrapping over wrapping over wrapping. Try doing a big app 
> in Java (i.e. some kind of layered server) and you'll understand everything. 
> Ones who tried and still want it - well, there are different tastes out there.

OTOH, people *don't* seem to have these problems with Rust and functional 
languages with value-oriented error handling. This could be partly because 
there's a greater focus on fully-closed systems in those communities where 
resilience isn't a concern, and you can usually evolve all your use sites if 
you need to break an API, whereas C++ and Java projects are more likely to 
incorporate black-box components from multiple sources. Having affordances for 
unwinding with a well-typed error *within* a component seems like a generally 
useful thing; Haskell has do notation and Rust tosses macros at the problem to 
hide the propagation boilerplate, after all.

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

Re: [swift-evolution] [swift-build-dev] [Draft] Package Manager Manifest API Redesign

[David Hart via swift-evolution]

> On 27 Feb 2017, at 11:21, Ankit Aggarwal  wrote:
> 
> Hi David,
> 
> Thanks for the feedback! Comments inline:
> 
> 
> On Sun, Feb 26, 2017 at 5:08 AM, David Hart via swift-build-dev 
> > wrote:
> Was looking forward to this :) here are my comments:
> 
> On 25 Feb 2017, at 01:35, Rick Ballard via swift-evolution 
> > wrote:
> 
>> Hi all,
>> 
>> Ankit, Daniel, Anders, Boris and I have a draft proposal in progress for a 
>> Package.swift manifest API redesign for the Package Manager. We'll welcome 
>> comments or discussion at this time. My hope is that we can get this 
>> polished up and ready for evolution within the next week or so, but we'll 
>> see how the conversation goes!
>> 
>> You can see the proposal in progress at 
>> https://github.com/aciidb0mb3r/swift-evolution/blob/manifest-api-redesign/proposals/-package-manager-manifest-api-redesign.md
>>  
>> .
>>  I'm also including the current version inline in this email.
>> 
>> Thanks,
>> 
>>- Rick
>> 
>> # Package Manager Manifest API Redesign
>> 
>> * Proposal: [SE-](-package-manager-manifest-api-redesign.md 
>> )
>> * Author: [Ankit Aggarwal](https://github.com/aciidb0mb3r 
>> )
>> * Review Manager: TBD
>> * Status: **Discussion**
>> 
>> ## Introduction
>> 
>> This is a proposal for redesigning the `Package.swift` manifest APIs provided
>> by Swift Package Manager.  
>> This proposal only redesigns the existing public APIs and does not add any
>> new functionality; any API to be added for new functionality will happen in
>> separate proposals.
>> 
>> ## Motivation
>> 
>> The `Package.swift` manifest APIs were designed prior to the [API Design
>> Guidelines] (https://swift.org/documentation/api-design-guidelines/ 
>> ), and their
>> design was not reviewed by the evolution process. Additionally, there are
>> several small areas which can be cleaned up to make the overall API more
>> "Swifty".
>> 
>> We would like to redesign these APIs as necessary to provide clean,
>> conventions-compliant APIs that we can rely on in the future. Because we
>> anticipate that the user community for the Swift Package Manager will grow
>> considerably in Swift 4, we would like to make these changes now, before
>> more packages are created using the old API.
>> 
>> ## Proposed solution
>> 
>> Note: Access modifier is omitted from the diffs and examples for brevity. The
>> access modifier is `public` for all APIs unless specified.
>> 
>> * Remove `successor()` and `predecessor()` from `Version`.
>> 
>>These methods neither have well defined semantics nor are used a lot
>>(internally or publicly). For e.g., the current implementation of
>>`successor()` always just increases the patch version.
>> 
>> 
>>
>>  View diff
>>  
>>```diff
>>struct Version {
>>-func successor() -> Version
>> 
>>-func predecessor() -> Version
>>}
>>```
>>
>> 
>> * Make all properties of `Package` and `Target` mutable.
>> 
>>Currently, `Package` has three immutable and four mutable properties, and
>>`Target` has one immutable and one mutable property. We propose to make 
>> all
>>properties mutable to allow complex customization on the package object
>>after initial declaration.
>> 
>>
>>  View diff and example
>>  
>> 
>>  Diff:
>>```diff
>>final class Target {
>>-let name: String
>>+var name: String
>>}
>> 
>>final class Package {
>>-let name: String
>>+var name: String
>> 
>>-let pkgConfig: String?
>>+var pkgConfig: String?
>> 
>>-let providers: [SystemPackageProvider]?
>>+var providers: [SystemPackageProvider]?
>>}
>>```
>> 
>>Example:
>>```swift
>>let package = Package(
>>name: "FooPackage",
>>targets: [
>>Target(name: "Foo", dependencies: ["Bar"]),
>>]
>>)
>> 
>>#if os(Linux)
>>package.targets[0].dependencies = ["BarLinux"]
>>#endif
>>```
>>
>> 
>> * Change `Target.Dependency` enum cases to lowerCamelCase.
>> 
>>According to API design guidelines, everything other than types should be 
>> in lowerCamelCase.
>> 
>>
>>  View diff and example
>>  
>> 
>> Diff:
>>```diff
>>enum Dependency {
>>-case Target(name: String)
>>+case target(name: String)
>> 
>>-case Product(name: String, package: String?)
>>+case product(name: String, package: String?)
>> 
>>-case ByName(name: String)
>>+case byName(name: String)
>>}
>>```
>> 
>>

Re: [swift-evolution] [pitch] Variadic Arguments should accept Arrays

[Tino Heth via swift-evolution]

> These is very unfortunate as a solution for “spreading” a collection or tuple 
> so that It can be applied to function taking a variadic.
> It makes sense on the declaration site but not on the call site. 
> 
> someFunc(@nonVariadic [1])  
> someFunc(@variadic [1]) 
> 
> There is nothing special about variadic/ spreading that would warrant an 
> attribute. 
> 
> I think using attributes is not different than using a keyword like c# uses. 
> http://stackoverflow.com/questions/7580277/why-use-the-params-keyword 
> 
> 
> Do we really want to tag every array/tuple with a @variadic or @nonVariadic 
> tag when packing and unpacking parameters?
> 
> variadic/ spreading (AKA packing / unpacking ) is a well known concept to 
> most languages. 

I have the impression there is a misunderstanding about the proposal:
It would not only make the variadics-syntax superflous, but also the whole 
splatting-magic.
There would only be functions that accept arrays, and you could freely choose 
to feed them a comma-seperated list instead.
The attribute would be written in the function declaration only — and we could 
even decide that it isn't needed at all, and simply accept lists wherever an 
array is expected.___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Pitch] Typed throws

[Daniel Leping via swift-evolution]

David, IMHO, all you say is absolutely true and typed throws might work
well, but in theoretic idealistic world. In reality though, you end having
more exception types than data types, feature cost rises exponentially and
the code becomes cluttered with all the wrapping.

I seriously don't understand why would one even think of this feature after
it's proven a bad practice by Java community. Even Java based languages
(i.e. Scala) have dropped this "feature".

On Mon, 27 Feb 2017 at 21:46 David Waite 
wrote:

> IMHO, there are two kinds of responses to errors - a specific response,
> and a general one. Only the calling code knows how it will deal with
> errors, so a “typed throws” is the function guessing possible calling code
> behavior.
>
> The problem is, that gives four possible combinations - two where the
> function guesses correctly, and two where it doesn’t. The most damaging is
> when it suspects a caller doesn’t care about the error, when the caller
> actually does. This is unwanted wrapping.
>
> To provide an example, imagine a library that parses JSON. It has several
> errors indicating JSON syntactic errors, and an “other” for representing
> errors on the input stream. It wraps the input stream errors so that it can
> provide a closed set of errors to the caller.
>
> The caller is responsible for returning a data set. It doesn’t think that
> code calling ‘it” cares about JSON syntactic errors, merely that the object
> was not able to be restored. It returns its own wrapped error.
>
> However, the original caller knows it is loading from disk. If the problem
> is due to an issue such as access permissions, It has to know
> implementation details of the API it called if it wishes to dive through
> the wrapped errors to find out if the problem was filesystem related.
>
> Add more layers, and it can be very mysterious why a call failed. Java at
> least captures stack traces in this case to aid in technical support in
> diagnosing the error.
>
> Wrapping exceptions also prevents an aggregate of errors from different
> subsystems being handled as a category, such as having a catch block handle
> RecoverableError generically
>
> An interesting solution that has emerged in Ruby to keep library authors
> from wrapping exceptions is by decorating the existing exception.
> Exceptions are caught via pattern matching (same as in Swift), so rather
> than wrap an extension, they extend the error instance with a
> library-specific module (e.g. swift protocol). So while the error may be a
> IOError in ruby, you can still catch it via ‘rescue JSONError’
>
> Trying to specify the exact errors becomes even more destructive with
> protocols and closures, where the person defining the interface knows
> neither which errors the implementor of the call will throw, nor
> necessarily if the caller will want to implement specific behavior on those
> errors. This in my personal Java coding experience almost always leads to
> wrapping in some protocol-specific Exception type which exposes minimal
> information to the caller, or exposing your errors in some unrelated type
> like IOException which was declared based on the author’s experience of
> possible exceptions.
>
> -DW
>
>
> On Feb 27, 2017, at 5:19 AM, Daniel Leping via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>
> On Mon, 27 Feb 2017 at 8:44 Dave Abrahams via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>
> on Fri Feb 17 2017, Joe Groff  wrote:
>
> > Experience in other languages like Rust and Haskell that use
> > Result-based error propagation suggests that a single error type is
> > adequate, and beneficial in many ways.
>
>
>
> And experience in still others, like C++ and Java, suggests that
> using static types to restrict the kind of information a function can
> give you when an error occurs may actually be harmful.
>
> +1 here. It becomes wrapping over wrapping over wrapping. Try doing a big
> app in Java (i.e. some kind of layered server) and you'll understand
> everything. Ones who tried and still want it - well, there are different
> tastes out there.
>
>
>
> --
> -Dave
>
> ___
> 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] Typed throws

[Matthew Johnson via swift-evolution]

> On Feb 27, 2017, at 1:46 PM, David Waite via swift-evolution 
>  wrote:
> 
> IMHO, there are two kinds of responses to errors - a specific response, and a 
> general one. Only the calling code knows how it will deal with errors, so a 
> “typed throws” is the function guessing possible calling code behavior.
> 
> The problem is, that gives four possible combinations - two where the 
> function guesses correctly, and two where it doesn’t. The most damaging is 
> when it suspects a caller doesn’t care about the error, when the caller 
> actually does. This is unwanted wrapping.
> 
> To provide an example, imagine a library that parses JSON. It has several 
> errors indicating JSON syntactic errors, and an “other” for representing 
> errors on the input stream. It wraps the input stream errors so that it can 
> provide a closed set of errors to the caller.
> 
> The caller is responsible for returning a data set. It doesn’t think that 
> code calling ‘it” cares about JSON syntactic errors, merely that the object 
> was not able to be restored. It returns its own wrapped error.
> 
> However, the original caller knows it is loading from disk. If the problem is 
> due to an issue such as access permissions, It has to know implementation 
> details of the API it called if it wishes to dive through the wrapped errors 
> to find out if the problem was filesystem related.

On the other hand, without wrapping the caller still needs to know the 
implementation details of the API in order to know what errors its dependencies 
might throw and the burden of grouping errors into higher-level categories is 
punted to the caller.  Some callers might appreciate the directness and 
specificity of the original error but many others might appreciate the higher 
level grouping.

This is ultimately a question of API design where there is no one right answer.

> 
> Add more layers, and it can be very mysterious why a call failed. Java at 
> least captures stack traces in this case to aid in technical support in 
> diagnosing the error.
> 
> Wrapping exceptions also prevents an aggregate of errors from different 
> subsystems being handled as a category, such as having a catch block handle 
> RecoverableError generically
> 
> An interesting solution that has emerged in Ruby to keep library authors from 
> wrapping exceptions is by decorating the existing exception. Exceptions are 
> caught via pattern matching (same as in Swift), so rather than wrap an 
> extension, they extend the error instance with a library-specific module 
> (e.g. swift protocol). So while the error may be a IOError in ruby, you can 
> still catch it via ‘rescue JSONError’

If I understand this correctly it sounds like introducing a library would 
create protocols to categorize errors and add retroactive conformances to these 
protocols for errors thrown by its dependencies?  That is an interesting 
approach.  But it requires knowing the concrete types of the possible errors 
all the way down the stack (you can’t add a conformance to an existential).  
This seems very problematic to me, especially in a language where creating new 
error types is as easy as it is in Swift.

Error handling is messy, there’s no doubt about that.  I would like to have as 
many tools at my disposal as possible.  Error types is one of those tools.

> 
> Trying to specify the exact errors becomes even more destructive with 
> protocols and closures, where the person defining the interface knows neither 
> which errors the implementor of the call will throw, nor necessarily if the 
> caller will want to implement specific behavior on those errors. This in my 
> personal Java coding experience almost always leads to wrapping in some 
> protocol-specific Exception type which exposes minimal information to the 
> caller, or exposing your errors in some unrelated type like IOException which 
> was declared based on the author’s experience of possible exceptions.
> 
> -DW
>  
>> On Feb 27, 2017, at 5:19 AM, Daniel Leping via swift-evolution 
>> > wrote:
>> 
>> 
>> On Mon, 27 Feb 2017 at 8:44 Dave Abrahams via swift-evolution 
>> > wrote:
>> 
>> on Fri Feb 17 2017, Joe Groff > > wrote:
>> 
>> > Experience in other languages like Rust and Haskell that use
>> > Result-based error propagation suggests that a single error type is
>> > adequate, and beneficial in many ways.
>> 
>> 
>> And experience in still others, like C++ and Java, suggests that
>> using static types to restrict the kind of information a function can
>> give you when an error occurs may actually be harmful.
>> +1 here. It becomes wrapping over wrapping over wrapping. Try doing a big 
>> app in Java (i.e. some kind of layered server) and you'll understand 
>> everything. Ones who tried and still want it - well, there 

Re: [swift-evolution] [pitch] Variadic Arguments should accept Arrays

[Haravikk via swift-evolution]

> On 27 Feb 2017, at 19:09, Jose Cheyo Jimenez  wrote:
> 
>> 
>> On Feb 27, 2017, at 9:59 AM, Haravikk > > wrote:
>> 
>> 
>>> On 27 Feb 2017, at 17:10, Jose Cheyo Jimenez via swift-evolution 
>>> > wrote:
>>> On Feb 26, 2017, at 9:25 AM, Tino Heth via swift-evolution 
>>> > wrote:
>>> 
 I suggest to take a look at the topics "Variadics as an Attribute" and 
 "array splatting for variadic parameters" and 
 https://github.com/Haravikk/swift-evolution/blob/a13dc03d6a8c76b25a30710d70cbadc1eb31b3cd/proposals/-variadics-as-attribute.md
  
 .
 
 This is basically the other way round (arrays would accept variadic 
 arguments), but it has the same effect — and more:
 You get rid of the odd "…" type, and it's also possible to use this with 
 types besides array (set, iterator….)
>>> I agree with getting rid of the Type... because we could use ... in slicing 
>>> (see String manifesto). Why must it be an attribute and not just "*" ? The 
>>> advantage I see is that this will play great in also deconstructing 
>>> collection like things like Array, Slice and Tuple. This is already 
>>> familiar to python and ruby users. 
>> 
>> Part of the aim is to avoid less easily discovered custom syntax; the point 
>> of the proposal is that there's no need for a special syntax just to support 
>> variadics as attributes already exist, plus they're more descriptive about 
>> what they do and easy to look-up.
> 
> 
> These is very unfortunate as a solution for “spreading” a collection or tuple 
> so that It can be applied to function taking a variadic.
> It makes sense on the declaration site but not on the call site. 
> 
> someFunc(@nonVariadic [1])  
> someFunc(@variadic [1]) 

These are only required in the case that a function accepts arguments of type 
Any; since both the array itself, and its contents are valid example of Any. 
This isn't the case if the variadic is on any other type.___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Pitch] Typed throws

[David Waite via swift-evolution]

IMHO, there are two kinds of responses to errors - a specific response, and a 
general one. Only the calling code knows how it will deal with errors, so a 
“typed throws” is the function guessing possible calling code behavior.

The problem is, that gives four possible combinations - two where the function 
guesses correctly, and two where it doesn’t. The most damaging is when it 
suspects a caller doesn’t care about the error, when the caller actually does. 
This is unwanted wrapping.

To provide an example, imagine a library that parses JSON. It has several 
errors indicating JSON syntactic errors, and an “other” for representing errors 
on the input stream. It wraps the input stream errors so that it can provide a 
closed set of errors to the caller.

The caller is responsible for returning a data set. It doesn’t think that code 
calling ‘it” cares about JSON syntactic errors, merely that the object was not 
able to be restored. It returns its own wrapped error.

However, the original caller knows it is loading from disk. If the problem is 
due to an issue such as access permissions, It has to know implementation 
details of the API it called if it wishes to dive through the wrapped errors to 
find out if the problem was filesystem related.

Add more layers, and it can be very mysterious why a call failed. Java at least 
captures stack traces in this case to aid in technical support in diagnosing 
the error.

Wrapping exceptions also prevents an aggregate of errors from different 
subsystems being handled as a category, such as having a catch block handle 
RecoverableError generically

An interesting solution that has emerged in Ruby to keep library authors from 
wrapping exceptions is by decorating the existing exception. Exceptions are 
caught via pattern matching (same as in Swift), so rather than wrap an 
extension, they extend the error instance with a library-specific module (e.g. 
swift protocol). So while the error may be a IOError in ruby, you can still 
catch it via ‘rescue JSONError’

Trying to specify the exact errors becomes even more destructive with protocols 
and closures, where the person defining the interface knows neither which 
errors the implementor of the call will throw, nor necessarily if the caller 
will want to implement specific behavior on those errors. This in my personal 
Java coding experience almost always leads to wrapping in some 
protocol-specific Exception type which exposes minimal information to the 
caller, or exposing your errors in some unrelated type like IOException which 
was declared based on the author’s experience of possible exceptions.

-DW
 
> On Feb 27, 2017, at 5:19 AM, Daniel Leping via swift-evolution 
>  wrote:
> 
> 
> On Mon, 27 Feb 2017 at 8:44 Dave Abrahams via swift-evolution 
> > wrote:
> 
> on Fri Feb 17 2017, Joe Groff  > wrote:
> 
> > Experience in other languages like Rust and Haskell that use
> > Result-based error propagation suggests that a single error type is
> > adequate, and beneficial in many ways.
> 
> 
> And experience in still others, like C++ and Java, suggests that
> using static types to restrict the kind of information a function can
> give you when an error occurs may actually be harmful.
> +1 here. It becomes wrapping over wrapping over wrapping. Try doing a big app 
> in Java (i.e. some kind of layered server) and you'll understand everything. 
> Ones who tried and still want it - well, there are different tastes out there.
> 
> 
> --
> -Dave
> 
> ___
> 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] [Re-Review] SE-0104: Protocol-oriented integers

[Max Moiseev via swift-evolution]

> On Feb 25, 2017, at 8:28 AM, Xiaodi Wu via swift-evolution 
>  wrote:
> 
> I assume that Number being renamed Numeric implies SignedNumber being renamed 
> SignedNumeric?
That is correct.

> On Sat, Feb 25, 2017 at 09:06 Ben Rimmington via swift-evolution 
> > wrote:
>   
> >
> 
> > On 24 Feb 2017, at 02:05, Ben Cohen wrote:
> >
> > Regarding the “Number” protocol: it was felt this is likely to cause 
> > confusion with NSNumber, given the NS-prefix-dropping versions of other 
> > Foundation types indicate a value-typed concrete type equivalent, which 
> > this won’t be. The recommendation is to use “Numeric" instead.
> 
> Does the `Error` protocol cause confusion with the `NSError` class?
> 
> I think `Number` is better than `Numeric`, because it is consistent with 
> `SignedNumber`.
> ___
> 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] [Re-Review] SE-0104: Protocol-oriented integers

[Jordan Rose via swift-evolution]

> On Feb 25, 2017, at 07:06, Ben Rimmington via swift-evolution 
>  wrote:
> 
> 
> 
>> On 24 Feb 2017, at 02:05, Ben Cohen wrote:
>> 
>> Regarding the “Number” protocol: it was felt this is likely to cause 
>> confusion with NSNumber, given the NS-prefix-dropping versions of other 
>> Foundation types indicate a value-typed concrete type equivalent, which this 
>> won’t be. The recommendation is to use “Numeric" instead.
> 
> Does the `Error` protocol cause confusion with the `NSError` class?
> 
> I think `Number` is better than `Numeric`, because it is consistent with 
> `SignedNumber`.

Error and NSError are actually related types, like String and NSString, and are 
used in roughly the same way. Numeric and NSNumber serve very different 
purposes: the former is a protocol for various operations, and the latter is a 
semi-type-erased class box around a *cough* numeric value that (deliberately) 
doesn't implement most of the operations in the protocol.

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

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0155: Normalize Enum Case Representation

[Matthew Johnson via swift-evolution]

> On Feb 27, 2017, at 12:46 PM, Joe Groff  wrote:
> 
> 
>> On Feb 27, 2017, at 10:39 AM, Matthew Johnson  wrote:
>> 
>> 
>> 
>> Sent from my iPad
>> 
>>> On Feb 27, 2017, at 12:00 PM, Joe Groff via swift-evolution 
>>>  wrote:
>>> 
>>> 
 On Feb 24, 2017, at 9:26 PM, Daniel Duan  wrote:
 
 Before I start revising this proposal, there are a couple of open 
 questions I’d like to discuss with the community and the core team.
 
 The first question relates to the purpose of having a “internal” argument 
 name. There are applications of such names in GADT (if we ever get there) 
 and perhaps the case-as-subtype-of-the-enum stories on the list right now. 
 Out side of these scenarios, however, such names has few chances to be 
 used. The one I can come up with, which is also the “open” part of the 
 question, is this: we can use the internal names in pattern matching, as 
 opposed to using the labels. This seems to align with the subtyping/GADT 
 use cases. Is this a desirable outcome?
>>> 
>>> Why would GADTs make internal argument names useful? They seem completely 
>>> useless to me. Their "internal"-ness is compromised if you try to hang 
>>> semantics off of them—they shouldn't have any impact on use sites.
>> 
>> Internal is probably a bad name.  Imagine if the case is a subtype of the 
>> enum and thus a struct or struct-like type.  We would usually want the 
>> property to be named similarly to the name we would use for an argument in a 
>> function implementation, not the label used when calling the function.
>> 
>> Here is an example of the kind of thing I have in mind:
>> 
>> enum PlayerState {
>>  case stopped
>>  sub case playing(with track: Track)
>> 
>>   // type of the playing case looks something like this:
>>   struct Playing { let track: Track }
>> 
>>   // the case value constructor looks something like this
>>   static func playing(with track: Track) -> Playing {
>>   return Playing(track: track)
>>   }
>> }
>> 
>> let foo = Foo.playing(with: makeTrack())
>> let track = foo.track
>> 
>> switch foo {
>>   case .stopped: break
>>   // we get to match with the name that is argument / property-like
>>   // `with` would be a terrible variable name 
>>   case .playing(let track): // do something with the track
>> 
>>// this label would be used when the user wants to use a *different* name
>>   // case .playing(with: let someOtherName)
>> }
> 
> That still feels like it's going against the behavior of the binding name in 
> other declarations. Personally, `case .playing(with: let x)` doesn't bother 
> me that much, especially since the IDE ought to be able to splat that out for 
> you.

It depends on how verbose the label is.  :)  

What did you think of the subtype example using the “internal” name as the 
property name?  Does that make sense?

I definitely don’t think we would want to allow eliding the *external* label by 
binding a name: `case .playing(let with)` is a bit absurd! :)

Personally, I think eliding would be a useful shorthand and if we allow it 
along with internal names (which I also think is a good idea) then we would 
want eliding to use the internal / property name.  

The primary goal should be clarity at the site of the pattern.  Sometimes a 
label adds clarity, but other times it will just add clutter.  Allowing label 
elision ensures a reader sees a name that lines up with the meaning of the 
associated value with less clutter.  I think this would often increase clarity. 
 That said, it is a rather minor piece of syntactic sugar.


> 
> -Joe

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

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0155: Normalize Enum Case Representation

[John McCall via swift-evolution]

> On Feb 27, 2017, at 1:39 PM, Daniel Duan  wrote:
>> On Feb 27, 2017, at 10:00 AM, Joe Groff  wrote:
>> 
>> 
>>> On Feb 24, 2017, at 9:26 PM, Daniel Duan  wrote:
>>> 
>>> Before I start revising this proposal, there are a couple of open questions 
>>> I’d like to discuss with the community and the core team.
>>> 
>>> The first question relates to the purpose of having a “internal” argument 
>>> name. There are applications of such names in GADT (if we ever get there) 
>>> and perhaps the case-as-subtype-of-the-enum stories on the list right now. 
>>> Out side of these scenarios, however, such names has few chances to be 
>>> used. The one I can come up with, which is also the “open” part of the 
>>> question, is this: we can use the internal names in pattern matching, as 
>>> opposed to using the labels. This seems to align with the subtyping/GADT 
>>> use cases. Is this a desirable outcome?
>> 
>> Why would GADTs make internal argument names useful? They seem completely 
>> useless to me. Their "internal"-ness is compromised if you try to hang 
>> semantics off of them—they shouldn't have any impact on use sites.
> 
> Interesting. 
> 
> I was reaching for any possible use cases there. The theory is these names 
> would be how one refers to a "property" of the case in, say, extension 
> methods for the case.
> 
> But yeah, I considered this internal name thing during first draft and 
> decided that they weren't necessary 路‍♀️

I think the strongest argument here is that internal names already have an 
accepted meaning, which is just that they name the argument variables in the 
following code.  Today, cases don't have any following code, but if/when we add 
that in SE-, people will obviously expect internal names to name those 
argument variables.  Even if the SE- proposers decide that, actually, using 
internal names for case arguments isn't a good idea, they will still need to do 
something about that natural user expectation, and they shouldn't be limited by 
us having carelessly given internal names some random other meaning way back in 
SE-0155.

John.

>> 
>>> The second open question is the syntax for “overloaded” cases. If we decide 
>>> to allow them, what should the patterns matching them look like? I can 
>>> think of one obvious-ish design where we make the pattern look like the 
>>> declaration and require types for disambiguation. So the most verbose form 
>>> of pattern would look something like
>>> 
>>> ```
>>> case let .baseName(label0 name0: Type0, label1 name1: Type1)
>>> ```
>> 
>> By "overloaded", do you mean "same name different types", or "same base 
>> name, different argument names"? I think we should have a consistent naming 
>> model where the latter is never considered overloading.
> 
> Same name different type is what "overloading" was meant here. "Same base 
> name" is already in the first revision and wouldn't fit in this "open 
> question" discussion.
> 
>> As an affordance to make pattern matching more concise, it seems reasonable 
>> to me to maybe say that a binding pattern matches a label with the same 
>> name, so that `case .foo(let bar, let bas)` can match `.foo(bar:bas:)`.
> 
> Good idea.
> 
>> -Joe
> 

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

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0155: Normalize Enum Case Representation

[Joe Groff via swift-evolution]

> On Feb 27, 2017, at 10:39 AM, Matthew Johnson  wrote:
> 
> 
> 
> Sent from my iPad
> 
>> On Feb 27, 2017, at 12:00 PM, Joe Groff via swift-evolution 
>>  wrote:
>> 
>> 
>>> On Feb 24, 2017, at 9:26 PM, Daniel Duan  wrote:
>>> 
>>> Before I start revising this proposal, there are a couple of open questions 
>>> I’d like to discuss with the community and the core team.
>>> 
>>> The first question relates to the purpose of having a “internal” argument 
>>> name. There are applications of such names in GADT (if we ever get there) 
>>> and perhaps the case-as-subtype-of-the-enum stories on the list right now. 
>>> Out side of these scenarios, however, such names has few chances to be 
>>> used. The one I can come up with, which is also the “open” part of the 
>>> question, is this: we can use the internal names in pattern matching, as 
>>> opposed to using the labels. This seems to align with the subtyping/GADT 
>>> use cases. Is this a desirable outcome?
>> 
>> Why would GADTs make internal argument names useful? They seem completely 
>> useless to me. Their "internal"-ness is compromised if you try to hang 
>> semantics off of them—they shouldn't have any impact on use sites.
> 
> Internal is probably a bad name.  Imagine if the case is a subtype of the 
> enum and thus a struct or struct-like type.  We would usually want the 
> property to be named similarly to the name we would use for an argument in a 
> function implementation, not the label used when calling the function.
> 
> Here is an example of the kind of thing I have in mind:
> 
> enum PlayerState {
>   case stopped
>   sub case playing(with track: Track)
> 
>// type of the playing case looks something like this:
>struct Playing { let track: Track }
> 
>// the case value constructor looks something like this
>static func playing(with track: Track) -> Playing {
>return Playing(track: track)
>}
> }
> 
> let foo = Foo.playing(with: makeTrack())
> let track = foo.track
> 
> switch foo {
>case .stopped: break
>// we get to match with the name that is argument / property-like
>// `with` would be a terrible variable name 
>case .playing(let track): // do something with the track
> 
> // this label would be used when the user wants to use a *different* name
>// case .playing(with: let someOtherName)
> }

That still feels like it's going against the behavior of the binding name in 
other declarations. Personally, `case .playing(with: let x)` doesn't bother me 
that much, especially since the IDE ought to be able to splat that out for you.

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

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0155: Normalize Enum Case Representation

[Daniel Duan via swift-evolution]

Daniel Duan
Sent from my iPhone
> On Feb 27, 2017, at 10:00 AM, Joe Groff  wrote:
> 
> 
>> On Feb 24, 2017, at 9:26 PM, Daniel Duan  wrote:
>> 
>> Before I start revising this proposal, there are a couple of open questions 
>> I’d like to discuss with the community and the core team.
>> 
>> The first question relates to the purpose of having a “internal” argument 
>> name. There are applications of such names in GADT (if we ever get there) 
>> and perhaps the case-as-subtype-of-the-enum stories on the list right now. 
>> Out side of these scenarios, however, such names has few chances to be used. 
>> The one I can come up with, which is also the “open” part of the question, 
>> is this: we can use the internal names in pattern matching, as opposed to 
>> using the labels. This seems to align with the subtyping/GADT use cases. Is 
>> this a desirable outcome?
> 
> Why would GADTs make internal argument names useful? They seem completely 
> useless to me. Their "internal"-ness is compromised if you try to hang 
> semantics off of them—they shouldn't have any impact on use sites.

Interesting. 

I was reaching for any possible use cases there. The theory is these names 
would be how one refers to a "property" of the case in, say, extension methods 
for the case.

But yeah, I considered this internal name thing during first draft and decided 
that they weren't necessary 路‍♀️
> 
>> The second open question is the syntax for “overloaded” cases. If we decide 
>> to allow them, what should the patterns matching them look like? I can think 
>> of one obvious-ish design where we make the pattern look like the 
>> declaration and require types for disambiguation. So the most verbose form 
>> of pattern would look something like
>> 
>> ```
>> case let .baseName(label0 name0: Type0, label1 name1: Type1)
>> ```
> 
> By "overloaded", do you mean "same name different types", or "same base name, 
> different argument names"? I think we should have a consistent naming model 
> where the latter is never considered overloading.

Same name different type is what "overloading" was meant here. "Same base name" 
is already in the first revision and wouldn't fit in this "open question" 
discussion.

> As an affordance to make pattern matching more concise, it seems reasonable 
> to me to maybe say that a binding pattern matches a label with the same name, 
> so that `case .foo(let bar, let bas)` can match `.foo(bar:bas:)`.

Good idea.

> -Joe

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

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0155: Normalize Enum Case Representation

[Matthew Johnson via swift-evolution]

Sent from my iPad

> On Feb 27, 2017, at 12:00 PM, Joe Groff via swift-evolution 
>  wrote:
> 
> 
>> On Feb 24, 2017, at 9:26 PM, Daniel Duan  wrote:
>> 
>> Before I start revising this proposal, there are a couple of open questions 
>> I’d like to discuss with the community and the core team.
>> 
>> The first question relates to the purpose of having a “internal” argument 
>> name. There are applications of such names in GADT (if we ever get there) 
>> and perhaps the case-as-subtype-of-the-enum stories on the list right now. 
>> Out side of these scenarios, however, such names has few chances to be used. 
>> The one I can come up with, which is also the “open” part of the question, 
>> is this: we can use the internal names in pattern matching, as opposed to 
>> using the labels. This seems to align with the subtyping/GADT use cases. Is 
>> this a desirable outcome?
> 
> Why would GADTs make internal argument names useful? They seem completely 
> useless to me. Their "internal"-ness is compromised if you try to hang 
> semantics off of them—they shouldn't have any impact on use sites.

Internal is probably a bad name.  Imagine if the case is a subtype of the enum 
and thus a struct or struct-like type.  We would usually want the property to 
be named similarly to the name we would use for an argument in a function 
implementation, not the label used when calling the function.

Here is an example of the kind of thing I have in mind:

enum PlayerState {
   case stopped
   sub case playing(with track: Track)

// type of the playing case looks something like this:
struct Playing { let track: Track }

// the case value constructor looks something like this
static func playing(with track: Track) -> Playing {
return Playing(track: track)
}
}

let foo = Foo.playing(with: makeTrack())
let track = foo.track

switch foo {
case .stopped: break
// we get to match with the name that is argument / property-like
// `with` would be a terrible variable name 
case .playing(let track): // do something with the track

 // this label would be used when the user wants to use a *different* name
// case .playing(with: let someOtherName)
}


> 
>> The second open question is the syntax for “overloaded” cases. If we decide 
>> to allow them, what should the patterns matching them look like? I can think 
>> of one obvious-ish design where we make the pattern look like the 
>> declaration and require types for disambiguation. So the most verbose form 
>> of pattern would look something like
>> 
>> ```
>> case let .baseName(label0 name0: Type0, label1 name1: Type1)
>> ```
> 
> By "overloaded", do you mean "same name different types", or "same base name, 
> different argument names"? I think we should have a consistent naming model 
> where the latter is never considered overloading. As an affordance to make 
> pattern matching more concise, it seems reasonable to me to maybe say that a 
> binding pattern matches a label with the same name, so that `case .foo(let 
> bar, let bas)` can match `.foo(bar:bas:)`.

I agree as far as names go, but I think this was talking about same name 
different types. I believe the overloading sub-topic began with Dave A's 
comments about anonymous cases for enums where the associated value is all that 
matters. 

My suggestion was to allow overloading on types and use cast patterns to 
disambiguate when matching.  This increases consistency with functions and 
enables that important use case.


> 
> -Joe
> ___
> 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-evolution-announce] [Review] SE-0155: Normalize Enum Case Representation

[Joe Groff via swift-evolution]

> On Feb 24, 2017, at 9:26 PM, Daniel Duan  wrote:
> 
> Before I start revising this proposal, there are a couple of open questions 
> I’d like to discuss with the community and the core team.
> 
> The first question relates to the purpose of having a “internal” argument 
> name. There are applications of such names in GADT (if we ever get there) and 
> perhaps the case-as-subtype-of-the-enum stories on the list right now. Out 
> side of these scenarios, however, such names has few chances to be used. The 
> one I can come up with, which is also the “open” part of the question, is 
> this: we can use the internal names in pattern matching, as opposed to using 
> the labels. This seems to align with the subtyping/GADT use cases. Is this a 
> desirable outcome?

Why would GADTs make internal argument names useful? They seem completely 
useless to me. Their "internal"-ness is compromised if you try to hang 
semantics off of them—they shouldn't have any impact on use sites.

> The second open question is the syntax for “overloaded” cases. If we decide 
> to allow them, what should the patterns matching them look like? I can think 
> of one obvious-ish design where we make the pattern look like the declaration 
> and require types for disambiguation. So the most verbose form of pattern 
> would look something like
> 
> ```
> case let .baseName(label0 name0: Type0, label1 name1: Type1)
> ```

By "overloaded", do you mean "same name different types", or "same base name, 
different argument names"? I think we should have a consistent naming model 
where the latter is never considered overloading. As an affordance to make 
pattern matching more concise, it seems reasonable to me to maybe say that a 
binding pattern matches a label with the same name, so that `case .foo(let bar, 
let bas)` can match `.foo(bar:bas:)`.

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

Re: [swift-evolution] [pitch] Variadic Arguments should accept Arrays

[Haravikk via swift-evolution]

> On 27 Feb 2017, at 17:10, Jose Cheyo Jimenez via swift-evolution 
>  wrote:
> On Feb 26, 2017, at 9:25 AM, Tino Heth via swift-evolution 
> > wrote:
> 
>> I suggest to take a look at the topics "Variadics as an Attribute" and 
>> "array splatting for variadic parameters" and 
>> https://github.com/Haravikk/swift-evolution/blob/a13dc03d6a8c76b25a30710d70cbadc1eb31b3cd/proposals/-variadics-as-attribute.md
>>  
>> .
>> 
>> This is basically the other way round (arrays would accept variadic 
>> arguments), but it has the same effect — and more:
>> You get rid of the odd "…" type, and it's also possible to use this with 
>> types besides array (set, iterator….)
> I agree with getting rid of the Type... because we could use ... in slicing 
> (see String manifesto). Why must it be an attribute and not just "*" ? The 
> advantage I see is that this will play great in also deconstructing 
> collection like things like Array, Slice and Tuple. This is already familiar 
> to python and ruby users. 

Part of the aim is to avoid less easily discovered custom syntax; the point of 
the proposal is that there's no need for a special syntax just to support 
variadics as attributes already exist, plus they're more descriptive about what 
they do and easy to look-up.___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [pitch] Variadic Arguments should accept Arrays

[Jose Cheyo Jimenez via swift-evolution]

> On Feb 26, 2017, at 9:25 AM, Tino Heth via swift-evolution 
>  wrote:
> 
> I suggest to take a look at the topics "Variadics as an Attribute" and "array 
> splatting for variadic parameters" and 
> https://github.com/Haravikk/swift-evolution/blob/a13dc03d6a8c76b25a30710d70cbadc1eb31b3cd/proposals/-variadics-as-attribute.md.
> 
> This is basically the other way round (arrays would accept variadic 
> arguments), but it has the same effect — and more:
> You get rid of the odd "…" type, and it's also possible to use this with 
> types besides array (set, iterator….)
I agree with getting rid of the Type... because we could use ... in slicing 
(see String manifesto). Why must it be an attribute and not just "*" ? The 
advantage I see is that this will play great in also deconstructing collection 
like things like Array, Slice and Tuple. This is already familiar to python and 
ruby users. 

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

Re: [swift-evolution] [Manifesto] Ownership

[John McCall via swift-evolution]

> On Feb 25, 2017, at 11:41 AM, plx via swift-evolution 
>  wrote:
> 1: Collection Composition
> 
> As much as the high-level picture is focused on safety, I’d just like to 
> request a strong focus on making sure the eventual ownership system addresses 
> the common issues like avoiding copies when mutating through optionals, or 
> when nesting collections, and so on.

Avoiding copies is basically the entire core of the proposal.  The interaction 
with safety is that sometimes copies are necessary to avoid memory unsafety, 
and this proposal recommends an approach that minimizes that.

> Point fixes like the custom `.values` collection on `Dictionary` that just 
> got approved are useful, but hopefully ownership can provide a general 
> solution.
> 
> 2: Mutating Iteration & Granularity
> 
> If I understood the mutating-iteration section right it reads as if `for 
> inout` would only be available on `MutableCollection`. Is that correct?
> 
> If so that does seem limiting, as e.g. for a `Dictionary` it’d be nice if 
> something like this were expressible:
> 
>   for (key, inout value) in someDictionary {
>   }
> 
> …assuming there’s not some insurmountable technical obstacle.

The technical obstacle to this is just that, so far, we've tried to make 
language features like for-loops use formal protocols.

An iteration protocol is going to have requirements like this:
  generator iterate() -> Element
  mutating generator iterateMutable() -> inout Element
But there's no valid substitution that makes '(Key, inout Value)' equal either 
'Element' or 'inout Element'.  So we'd have to do some special to make this 
work.

That said, no, there's no intrinsic technical reason this can't be made to work.

> 3: Mutable Views
> 
> Currently a major pain point of Swift has been exposing “mutable views” into 
> a type in a reasonable way. Apologies for length, but here’s an extended 
> example:
> 
>   /// Implements a 2D grid (of size fixed upon initialization).
>   /// **Not** a `Collection` itself but has many *views* into it that *are* 
> `Collection`s.
>   ///
>   struct Grid2D {
> // typical CoW backing storage
> fileprivate var storage: Grid2DStorage
> 
> /// Obtain a linear traversal of our grid:
> /// - parameter corner: The corner at which we start (e.g. `northWest`)
> /// - parameter motion: The order in which we travel 
> (`latitudeThenLongitude` or `longitudeThanLatitude`)
> ///
> /// - returns: A read-only `Collection` that visits each grid location in 
> `self`, following the requested traversal
> func traversal(from corner: Grid2DCorner, following motion: Grid2DMotion) 
> -> Grid2DTraversal
>   }
> 
> …wherein `Grid2DTraversal` is, as noted, a "read-only view” into its 
> parent that also adopts `Collection`.
> 
> What would be nice is to be able to make that `Grid2DTraversal` into a 
> mutable view in a way that’s also *safe*; what I mean is something like:
> 
>   extension Grid2D {
>   
> mutating func mutatingTraversal(from corner: Grid2DCorner, following 
> motion: Grid2DMotion, _ mutator: (inout Grid2DTraversal) -> R) -> R {
>   var t = self.traversal(from: corner, following: motion)
>   return mutator()
> }
> 
>   }
> 
> …with the specific goals of (a) having mutations applied via 
> `Grid2DTraversal` get directly written-through to the underlying storage 
> (w/out pointless copying) but also (b) making `Grid2DTraversal` generally act 
> safely in all other contexts.
> 
> As it is the “best” way to squeeze this into the type system at this time is 
> arguably:
> 
> - define Grid2DTraversal:
>   - to have as a strong reference to the backing storage
>   - as only having the read-only methods
> - *also* define MutableGrid2DTraversal:
>   - to have an unowned reference to the backing storage
>   - also include the mutating methods
> 
> …and then just be careful with API design and patterns of use; in particular 
> only provide access to `MutableGrid2DTraversal` values in the context of 
> closures passed into dedicated functions like `mutatingTraversal`, above…and 
> then just be disciplined never to extract those passed-in values.
> 
> Needless to say this isn’t a very satisfactory state of affairs—it is well 
> into “why am I bothering with all this?” territory—and it’d be *far* nicer if 
> the ownership system would allow for `Grid2DTraversal`:
> 
> - to adopt `Collection` without restriction
> - to adopt `MutableCollection` only in certain ownership contexts
> - to have reasonable control over where those contexts apply 

It's not sensible to have a type that conditionally conforms to a protocol 
based on context.  However, the requirements of MutableCollection are all 
'mutating', so you can't actually use them unless you have a mutable value.  So 
the way to fit what you're asking for into the ownership proposal is to make 
sure that clients of your view type only have a mutable value when the base was 
mutable, and the 

Re: [swift-evolution] Strings in Swift 4

[Ted F.A. van Gaalen via swift-evolution]

Hi David W. 
please read inline responses
> On 25 Feb 2017, at 07:26, David Waite  wrote:
> 
> Ted, 
> 
> It might have helped if instead of being called String and Character, they 
> were named Text and ExtendedGraphemeCluster. 
Imho,l “text” maybe, but in computer programming “String” is more appropriate, 
I think. see:
https://en.wikipedia.org/wiki/String_(computer_science) 
 

Also imho, “Character” is OK (but maybe “Symbol” would be better)  because 
mostly, when working
with text/strings in an application it is not important to know how the 
Character is encoded, 
e.g. Unicode, ASCII, whatever.(OOP , please hide the details, thank you)  

However, If I needed to work  with the character’s components directly, e.g. 
when I 
might want to influence the display of
the underlying graphical aspects, I always have access to the Characters’ 
properties 
and methods. Unicode codepoints, ASCII bytes.. whatever it contains... 
   
> 
> They don’t really have the same behavior or functionality as 
> string/characters in many other languages, especially older languages. This 
> is because in many languages, strings are not just text but also 
> random-accesss (possibly binary) data.
could be but that’s not my perception of a string. 
> 
> Thats not to say that there aren’t a ton of algorithms where you can use Text 
> like a String, treat ExtendedGraphemeCluster like a character, and get 
> unicode behavior without thinking about it.
> 
> But when it comes to random access and/or byte modification, you are better 
> off working with something closer to a traditional (byte) string interface.
> 
> Trying to wedge random access and byte modification into the Swift String 
> will simply complicate everything, slow down the algorithms which don’t need 
> it, eat up more memory, as well as slow down bridging between Swift and 
> Objective C code.
Yes, this has been extensively discussed in this thread...
> 
> Hence me suggesting earlier working with Data, [UInt8], or [Character] within 
> the context of your manipulation code, then converting to a Swift String at 
> the end. Convert to the data format you need, then convert back.
That’s exactly what I did, saved that I have the desire to work exclusively 
with discrete
 (in the model of humanly visible discrete elements on a graphical medium) ... 

For the sake of completeness ,here is my complete Swift 3.x playground example, 
may useful for others too:
//: Playground - noun: a place with Character!

import UIKit
import Foundation

struct TGString: CustomStringConvertible
{
var ar = [Character]()

var description: String // used by "print" and "\(...)"
{
return String(ar)
}

// Construct from a String
init(_ str : String)
{
ar = Array(str.characters)
}
// Construct from a Character array
init(_ tgs : [Character])
{
ar = tgs
}
// Construct from anything. well sort of..
init(_ whatever : Any)
{
ar = Array("\(whatever)".characters)
}

var $: String
{
get   // return as a normal Swift String
{
return String(ar)
}
set (str) //Mutable: set from a Swift String
{
ar = Array(str.characters)
}
}

var asString: String
{
get   // return as a normal Swift String
{
return String(ar)
}
set (str) //Mutable: set from a Swift String
{
ar = Array(str.characters)
}
}

// Return the count of total number of characters:
var count: Int
{
get
{
return ar.count
}
}

// Return empty status:

var isEmpty: Bool
{
get
{
return ar.isEmpty
}
}

// s[n1.. TGString
{
get
{
return TGString( [ar[n]] )
}
set(newValue)
{
if newValue.isEmpty
{
ar.remove(at: n) // remove element when empty
}
else
{
ar[n] =  newValue.ar[0]
if newValue.count > 1
{
insert(at: n, string: newValue[1.. TGString
{
get
{
return TGString( Array(ar[r]) )
}
set(newValue)
{
ar[r] = ArraySlice(newValue.ar)
}
}

subscript (r: ClosedRange) -> TGString
{
get
{
return TGString( Array(ar[r]) )
}
set(newValue)
{
ar[r] = ArraySlice(newValue.ar)
}
}

Re: [swift-evolution] [Pitch] Typed throws

[Daniel Leping via swift-evolution]

On Mon, 27 Feb 2017 at 8:44 Dave Abrahams via swift-evolution <
swift-evolution@swift.org> wrote:

>
> on Fri Feb 17 2017, Joe Groff  wrote:
>
> > Experience in other languages like Rust and Haskell that use
> > Result-based error propagation suggests that a single error type is
> > adequate, and beneficial in many ways.


>
> And experience in still others, like C++ and Java, suggests that
> using static types to restrict the kind of information a function can
> give you when an error occurs may actually be harmful.

+1 here. It becomes wrapping over wrapping over wrapping. Try doing a big
app in Java (i.e. some kind of layered server) and you'll understand
everything. Ones who tried and still want it - well, there are different
tastes out there.

>
>
> --
> -Dave
>
> ___
> 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] [Draft] Package Manager Manifest API Redesign

[Ankit Aggarwal via swift-evolution]

Hi David,

Thanks for the feedback! Comments inline:


On Sun, Feb 26, 2017 at 5:08 AM, David Hart via swift-build-dev <
swift-build-...@swift.org> wrote:

> Was looking forward to this :) here are my comments:
>
> On 25 Feb 2017, at 01:35, Rick Ballard via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> Hi all,
>
> Ankit, Daniel, Anders, Boris and I have a draft proposal in progress for a
> Package.swift manifest API redesign for the Package Manager. We'll welcome
> comments or discussion at this time. My hope is that we can get this
> polished up and ready for evolution within the next week or so, but we'll
> see how the conversation goes!
>
> You can see the proposal in progress at https://github.com/
> aciidb0mb3r/swift-evolution/blob/manifest-api-redesign/
> proposals/-package-manager-manifest-api-redesign.md. I'm also
> including the current version inline in this email.
>
> Thanks,
>
>- Rick
>
> # Package Manager Manifest API Redesign
>
> * Proposal: [SE-](-package-manager-manifest-api-redesign.md)
> * Author: [Ankit Aggarwal](https://github.com/aciidb0mb3r)
> * Review Manager: TBD
> * Status: **Discussion**
>
> ## Introduction
>
> This is a proposal for redesigning the `Package.swift` manifest APIs
> provided
> by Swift Package Manager.
> This proposal only redesigns the existing public APIs and does not add any
> new functionality; any API to be added for new functionality will happen in
> separate proposals.
>
> ## Motivation
>
> The `Package.swift` manifest APIs were designed prior to the [API Design
> Guidelines] (https://swift.org/documentation/api-design-guidelines/), and
> their
> design was not reviewed by the evolution process. Additionally, there are
> several small areas which can be cleaned up to make the overall API more
> "Swifty".
>
> We would like to redesign these APIs as necessary to provide clean,
> conventions-compliant APIs that we can rely on in the future. Because we
> anticipate that the user community for the Swift Package Manager will grow
> considerably in Swift 4, we would like to make these changes now, before
> more packages are created using the old API.
>
> ## Proposed solution
>
> Note: Access modifier is omitted from the diffs and examples for brevity.
> The
> access modifier is `public` for all APIs unless specified.
>
> * Remove `successor()` and `predecessor()` from `Version`.
>
>These methods neither have well defined semantics nor are used a lot
>(internally or publicly). For e.g., the current implementation of
>`successor()` always just increases the patch version.
>
>
>
>  View diff
>  
>```diff
>struct Version {
>-func successor() -> Version
>
>-func predecessor() -> Version
>}
>```
>
>
> * Make all properties of `Package` and `Target` mutable.
>
>Currently, `Package` has three immutable and four mutable properties,
> and
>`Target` has one immutable and one mutable property. We propose to make
> all
>properties mutable to allow complex customization on the package object
>after initial declaration.
>
>
>  View diff and example
>  
>
>  Diff:
>```diff
>final class Target {
>-let name: String
>+var name: String
>}
>
>final class Package {
>-let name: String
>+var name: String
>
>-let pkgConfig: String?
>+var pkgConfig: String?
>
>-let providers: [SystemPackageProvider]?
>+var providers: [SystemPackageProvider]?
>}
>```
>
>Example:
>```swift
>let package = Package(
>name: "FooPackage",
>targets: [
>Target(name: "Foo", dependencies: ["Bar"]),
>]
>)
>
>#if os(Linux)
>package.targets[0].dependencies = ["BarLinux"]
>#endif
>```
>
>
> * Change `Target.Dependency` enum cases to lowerCamelCase.
>
>According to API design guidelines, everything other than types should
> be in lowerCamelCase.
>
>
>  View diff and example
>  
>
> Diff:
>```diff
>enum Dependency {
>-case Target(name: String)
>+case target(name: String)
>
>-case Product(name: String, package: String?)
>+case product(name: String, package: String?)
>
>-case ByName(name: String)
>+case byName(name: String)
>}
>```
>
>Example:
>```diff
>let package = Package(
>name: "FooPackage",
>targets: [
>Target(
>name: "Foo",
>dependencies: [
>-.Target(name: "Bar"),
>+.target(name: "Bar"),
>
>-.Product(name: "SwiftyJSON", package: "SwiftyJSON"),
>+.product(name: "SwiftyJSON", package: "SwiftyJSON"),
>]
>),
>]
>)
>```
>
>
> * Add default parameter to the enum case `Target.Dependency.product`.
>
>The associated value `package` in the (enum) case `product`, is an
>