Re: [swift-evolution] [Review] SE 0192 - Non-Exhaustive Enums

[Zach Waldowski via swift-evolution]

Sorry to glomm on to my own comments:

I think there’s a lot of reasonable push-back to requiring a default
case on non-exhaustive enums. I personally don’t want to see a “future
case” because I think it’s mystery-meat. However, in the happy path, as
a developer I do want *some* notification by the compiler that I may
need to handle a new case, even if my code is already in the wild
handling the case through a default. To fulfill Swift’s safety and
stability goals, it  needs to both avoid creating suddenly invalid code
at compile time and  avoid UB at runtime. The community should take note
that this all a bit of cutting  a Gordian knot on the part of the
language, but it's worthwhile to avoid adding cruft and bugs.
Sincerely,
  Zachary Waldowski
  z...@waldowski.me

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

Re: [swift-evolution] [swift-evolution-announce] [REVIEW] SE-0193 - Cross-module inlining and specialization

[Zach Waldowski via swift-evolution]

I’m hugely in favor of a path forward that involves extending existing
language constructs instead of introducing new ones or throwing around a
bunchannotations. I want to say that I like extending `@available`
(because I do), but it kind of breaks my mental model of the flags to
`@available` establishing a sort of “lifecycle” for an entity
(born/introduced foo, deprecated bar, died/removed baz). I know that’s
not official reasoning, but it's helped me explain it to others. (As a
side concern, ABI flags feel too easily forgotten  in the expanded form
of `@available` where you are specifying multiple combos for multiple
platforms.)
Maybe there’s opportunity here for clustering together the purpose of
these ABI features more generally? Others have mentioned parameterizing
the access control keywords, which I personally think aligns well and
will also align well if/when versioning is added to those.
Alternatively, bucketing them together under something like
`@stability(inlinable: foo)` and making sure SourceKit gets autocomplete
for the parameters could be neat. I mention this kind of thing over in
the closed enums thread as deserving a more holistic look as we add a
new axis of syntax features to the language.
Sincerely,
  Zachary Waldowski
  z...@waldowski.me

On Thu, Dec 21, 2017, at 2:14 AM, Chris Lattner via swift-evolution wrote:>> On 
Dec 20, 2017, at 4:19 PM, Ted Kremenek  wrote:>> 
>> The review of "SE-0193 - Cross-module inlining and specialization"
>> begins now and runs through *January 5, 2018*.>> The proposal is available 
>> here:


>>> https://github.com/apple/swift-evolution/blob/master/proposals/0193-cross-module-inlining-and-specialization.md>>
>>>  When reviewing a proposal, here are some questions to consider:


>>  * What is your evaluation of the proposal?> I am hugely supportive of the 
>> features that these attributes enable,
> but I think that the spelling of this is absolutely wrong, and I’m
> disappointed that the extensive discussion we’ve had for months about
> this didn’t make it into (at least) the alternatives considered
> section.  Here are my concerns:> 
> *Availability Ranges*
> 
> Both of these attributes will (perhaps not for Swift 5 given the fact
> that these will be new then, but certainly in 5.1 or 6) need to be
> qualified by deployment modifiers.  We’ll need the ability to specify
> not just that a declaration is inlinable or abipublic, but in *which
> versions* of the binary package (that they are defined in) have this
> property.> 
> For example, while perhaps it will be common for a decl to be “born
> inlinable” and just need the form of attribute as specified here, it
> is just as clear that this is not the *only* model we need.  It is
> entirely reasonable (and will be important in the future) to say that
> something “became ABI public in iOS14, became abiPublic in iOS 15, and
> became inlinable in iOS16”.  The use of this will be relatively rare,
> but it is important for the model to support this in time.> 
> Because of this, if we accept the spelling as proposed in this
> proposal, these attributes will need to be generalized to have an
> availability range, e.g.:> 
> @abipublic(iOS 15, *)
> 
> The concern is that this proposal opens the door to have a family of
> attributes each of which have availability information on them, and
> this “family” of attributes will have nothing tying them together into
> a unified framework.> **
> **
> *Pollution of the Attribute Namespace*
> 
> Furthermore, these two attributes are the tip of the iceberg, and the
> core team has spent a lot of time recently discussing the fact there
> are potentially going to be about a dozen attributes similar to these
> (fixed_contents,  global_var_is_directly_addressible, …)  that will
> only be required for binary frameworks.  It is possible that
> @inlinable will be prominent enough to be a global attribute (I
> personally am not sure if it will be commonly used or not, it depends
> a lot on how widely used binary frameworks are).  That said, it is
> clear @abiPublic will not be commonly used, and many attributes that
> follow these will be even more obscure.> 
> This is bad for three reasons: 
> 
> 1) we’re polluting the general attribute namespace with obscure
>things.  Pollution of the attribute namespace may have a marginal
>impact today, but will start to matter if/when we ever get user
>defined attributes.> 
> 2) The other reason is that this provides no general framework to tie
>together these things that affect binary frameworks into a unified
>framework.> 
> 3) Furthermore, I don’t like attributes being a dumping ground for
>weird performance hacks required by binary frameworks.  It is a
>practical necessity that we support these because they are
>extremely important for narrow cases, but we don’t need to put them
>into a syntactically prominent spot in the grammar.> 
> *The name “ABI”*
> 
> A minor point, but the 

Re: [swift-evolution] [Review] SE 0192 - Non-Exhaustive Enums

[Zach Waldowski via swift-evolution]

On Tue, Dec 19, 2017, at 5:58 PM, Ted Kremenek wrote:
>  * What is your evaluation of the proposal?
+1.

I strongly prefer all additions to service ABI follow progressive
disclosure, but it’s not reason alone to make the annotation be mystery
meat. Like the inlining proposal, the spelling needs some consideration
by the core team to provide an ergonomic through-line through the
language. I liked reusing `final` way back when the proposal first came
up, but that ship appears to have sailed. If an annotation is our
preference, I do like `@frozen` if we see it come up in interesting ways
elsewhere.
>  * Is the problem being addressed significant enough to warrant a
>change to Swift?
I see this proposal and its discussion mostly as prevarication on the
spelling and the default behavior. Those aside, it solves a bug, so bar-
none something must be done. In a perfect world, no annotation or
closed/open would be needed, but this is unrealistic, and a solution
that involves compile-time diagnostics over runtime failures is
preferable.
>  * Does this proposal fit well with the feel and direction of Swift?
ABI stability is a high-level goal, and this fits within it.

The Core Team and Apple could do a better job with messaging its
compatibility impact. Though I understand it now, changing a feature’s
behavior is indeed surprising at this point. My understanding is that
nothing will change for creating enums in the single target happy path,
with a stretch goal being to extend that to all  source targets that
produce a single (in Apple terminology) bundle. I know y’all can’t
discuss future dev tools directions, but it may have helped us to know
the plan for what constitutes the compiler “seeing” an enum’s source to
make a resilience decision.
>  * If you have used other languages or libraries with a similar
>feature, how do you feel that this proposal compares to those?
I’m most familiar if the impact of this problem on ObjC, where it was
only really solved for Apple. We’re forging new territory for solving
this at the ABI level for any binary module, so some uncertainty is to
be expected.
>  * How much effort did you put into your review? A glance, a quick
>reading, or an in-depth study?
I’ve followed the proposal in depth since its early stages.

Sincerely,
  Zachary Waldowski
  z...@waldowski.me
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Concurrency] async/await + actors

[Zach Waldowski via swift-evolution]

On Thu, Aug 17, 2017, at 10:04 PM, Chris Lattner via swift-evolution wrote:> 
That said, I don’t feel like I have enough data to have a strong
> opinion on it.  The missing link for me is exactly how pervasive the
> non-throwing cocoa completion handlers are.  If it turns out that
> people would have to confront "async(nonthrowing)” in practice (as
> opposed to being an obscure corner that the compiler implementers have
> to care about) then it is probably the wrong design.
It may be helpful to look at data points outside of Cocoa. We use a
Future framework that distinguishes between plain old `Future` and
`Future`. In a back-of-the-hand calculation, about 10% of our
futures don’t use  Result. It’s rarer, but it is useful; it aligns well
with the Error manifesto’s notion of a domain failures.
I think I’m overall in favor of an implicitly throwing model, though.
Not only is it cleaner, but it’ll simplify all sorts of abstractions.
f.ex: In our use of this framework, collecting up errors or
cancellations for an array of tasks is a perennial problem. `Future`
(and similarly `async -> T?`) can be plenty useful, but I’m not sure
they pull their weight enough to deserve occupying the best syntax.
(Huge, huge +1 to the whole shebang, though. Let’s just do this!!!)

Sincerely,
  Zachary Waldowski
  z...@waldowski.me


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

Re: [swift-evolution] Enums and Source Compatibility - defaults

[Zach Waldowski via swift-evolution]

On Wed, Aug 9, 2017, at 08:49 PM, Jordan Rose via swift-evolution wrote:> Ah, I 
forgot to mention: per my response to Charlie, the vast majority
> of enums in ObjC Foundation (80-90%) seem to be "open". I should have
> put that in the "open" side of the list. I'm not convinced that "APIs
> are designed differently in Swift" to the extent where you'd actually
> expect most enums to be closed; rather, I suspect most Swift API
> designers haven't been thinking too hard about exhaustive switches,
> and certainly not about binary compatibility, which becomes relevant
> at least for Apple once Swift libraries become part of the SDK.
Let me expound a bit. I was erroneously including string enums in my
supposition that APIs are designed differently, but overall I still
stand behind it.
Foundation is designed for paper over lots of different computing
concepts  and underlying libraries with similar-ish APIs — in a good
way! From the eyes of an API consumer, configuring something like a
formatter to behave how they want is basically a write-only proposition.
This makes simple enum cases a great design choice for hiding  swaths of
different underlying implementations  (ex: NSDateFormatterShortStyle
having a different meaning per-locale.)
Say we split up Foundation's enums  roughly into categories. You have
your policies (NSURLCacheStoragePolicy, NSDateFormatterStyle),
states/answers (NSURLSessionTaskState, NSQualityOfService), and, well,
lists (NSSearchPathDirectory, NSStringEncoding). Given those, I’d say
protocols, generics, and zero-cost abstractions are frequently a better
choice (but not always). For  instance, IMHO a closed protocol better
models commonly-used styles.
I know you ask  to only consider open/closed enums in isolation to make
it most likely to succeed, but there’s the frequent complaint that Swift
has many ways to accomplish the same thing; I think resilience will land
best with the community if it has a few really solid throughlines with
the rest of the language, open/closed I hope being among them.
Sincerely,
  Zachary Waldowski
  z...@waldowski.me


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

Re: [swift-evolution] Enums and Source Compatibility - defaults

[Zach Waldowski via swift-evolution]

On Wed, Aug 9, 2017, at 08:42 PM, Jordan Rose via swift-evolution wrote:> - 
Consistency: switches on an enum in the same module can always be
>   exhaustive, so having it be different across modules is a bit
>   annoying. (But 'public' already acts like this.)
>From someone frequently working on teams or unfamiliar codebases, it’s
really heard to know whether “default: fatalError()” is a smell or not
without memorizing the  surface area of every API your app works with.
> … That brings us to one more concern: how different should binary
> frameworks be from source frameworks?
As few as possible. Realistically, I understand there must be  some, but
I feel like they need to be there for awfully good reasons. The
differences between app targets, framework/library targets, and
playgrounds feel arbitrary unless you understand parts of the language
very fully.
Some debugging techniques (or even just saving-time-rebuilding
techniques) involve using a binary framework and swapping it for another
binary with extra instrumentation or a source version for full
instrumentation, or vice-versa as you ossify a PoC feature into being
production-ready. It would be awful to break source compatibility as
this happens because an API you’re consuming changes behavior according
to the compiler. (I can hear my graybeard coworkers already - “It’s the
same code!”)
Sincerely,
  Zachary Waldowski
  z...@waldowski.me


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

Re: [swift-evolution] ExpressibleByStringInterpolation

[Zach Waldowski via swift-evolution]

I like the proposal so far and would be happy seeing this in 4.1, even.
;) I don’t know/remember the conditions under which the previous
implementation was deemed unsuitable, but this addresses most of my
personal qualms with it.

My primary interests in an interpolation align with yours: in addition
to things like SQL statements, I want string literals to improve aspects
of Apple’s frameworks like localization and (especially of interest to
me) logging. The `StringInterpolationSegment` design allows those
interests to be satisfied by limiting the acceptable interpolation
types, which is pretty nice. At the compiler QoL level, the error
handling for this will have to be pretty spiffy though.

My only suggestion for proposed given design would be to consider making
`case interpolation(Interpolation)` take a `() throws -> Interpolation`
instead to allow for lazy evaluation, basically acting like an
autoclosure. In your SQLStatement 

I actually don’t mind the buffer approach; it aligns reasonably with
Codable’s semantics. I understand the cons there are significant. It
comes down to extensibility; the proposed design is reasonable if we
can’t think of any potential ways to extend interpolation, since the
segment enum will have to be closed.

Sincerely,
  Zachary Waldowski
  z...@waldowski.me

On Wed, Aug 9, 2017, at 12:08 AM, Brent Royal-Gordon via swift-evolution
wrote:
> I had a proposal for replacing/reintroducing
> `ExpressibleByStringInterpolation` (which is currently deprecated pending
> a redesign), but it landed too late in the Swift 4 cycle to be
> considered. The PR is here:
> https://github.com/apple/swift-evolution/pull/659
> 
> I think it squares up relatively well against the Swift 5 standards:
> 
> * It addresses ABI stability and strings, which are both Swift 5 themes.
> 
> * It includes an implementation, but it definitely needs a rebase,
> probably needs someone more experienced than me to examine it with a
> fine-toothed comb, and might need a significant redesign.
> 
> * I believe it includes tests.
> 
> * I don't think it's been run against the source compatibility suite. (Is
> there a way for random outside developers to do that?)
> 
> So what's the next step at this point?
> 
> -- 
> Brent Royal-Gordon
> Architechies
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Enums and Source Compatibility

[Zach Waldowski via swift-evolution]

I disagree. Closed is indeed the stronger guarantee, but APIs are
designed differently in Swift; closed is a sensible default. We
shouldn’t need to define new keywords and increase the surface area of
the language for something that has verisimilitude with the existing
open syntax.
Sincerely,
  Zachary Waldowski
  z...@waldowski.me


On Wed, Aug 9, 2017, at 06:23 AM, David Hart via swift-evolution wrote:> 
> 
> On 9 Aug 2017, at 09:21, Adrian Zubarev via swift-evolution  evolut...@swift.org> wrote:>> Hi Jordan, is that only me or haven't you 
> metioned the default should
>> be applied to all new enums? Personally I'd say that 'closed' should
>> be the default and the 'open' enum would require an extra keyword.> 
> I think it should definitely be the other way round for public enums
> because closed is the stronger guarantee. Final is the default for
> classes because open is the stronger guarantee. That’s probably why we
> should not use the same keywords.> 
>> Now about the keyword itself. Here are two keywords that IMHO nail
>> their behavior down to the point:>> 
>> finite enum A {} - so to say a closed enum (default)
>> infinite enum B {} - so to say an open enum (requires default case in
>> a switch statement)>> 
>> If you think the default should be the other way around, than feel
>> free to switch that. 'finite' also implies that the enum connot ever
>> be extended with more cases (to become infinite), which was also
>> mentioned in your email.>> 
>> -- 
>> Adrian Zubarev
>> Sent with Airmail
>> Am 9. August 2017 um 00:27:53, Jordan Rose via swift-evolution (swift-
>> evolut...@swift.org) schrieb:>>> 
>>> 
>>> 
>>> Hi, everyone. Now that Swift 5 is starting up, I'd like to circle
>>> back to an issue that's been around for a while: the source
>>> compatibility of enums. Today, it's an error to switch over an
>>> enum without handling all the cases, but this breaks down in a
>>> number of ways:>>> 
>>> - A C enum may have "private cases" that aren't defined inside the
>>>   original enum declaration, and there's no way to detect these in a
>>>   switch without dropping down to the rawValue.>>> - For the same reason, 
>>> the compiler-synthesized 'init(rawValue:)' on
>>>   an imported enum never produces 'nil', because who knows how
>>>   anyone's using C enums anyway?>>> - Adding a new case to a *Swift* enum 
>>> in a library breaks any client
>>>   code that was trying to switch over it.>>> 
>>> (This list might sound familiar, and that's because it's from a
>>> message of mine on a thread started by Matthew Johnson back in
>>> February called "[Pitch] consistent public access modifiers". Most
>>> of the rest of this email is going to go the same way, because we
>>> still need to make progress here.)>>> 
>>> At the same time, we really like our exhaustive switches, especially
>>> over enums we define ourselves. And there's a performance side to
>>> this whole thing too; if all cases of an enum are known, it can be
>>> passed around much more efficiently than if it might suddenly grow a
>>> new case containing a struct with 5000 Strings in it.>>> 
>>> 
>>> *Behavior*
>>>
>>>  I think there's certain behavior that is probably not *terribly*
>>>  controversial:
>>>
>>>  - When enums are imported from Apple frameworks, they should always
>>>require a default case, except for a few exceptions like
>>>NSRectEdge. (It's Apple's job to handle this and get it right,
>>>but if we get it wrong with an imported enum there's still the
>>>workaround of dropping down to the raw value.)
>>>  - When I define Swift enums in the current framework, there's
>>>obviously no compatibility issues; we should allow exhaustive
>>>switches.
>>>
>>>  Everything else falls somewhere in the middle, both for enums
>>>  defined in Objective-C:
>>>
>>>  - If I define an Objective-C enum in the current framework, should
>>>it allow exhaustive switching, because there are no compatibility
>>>issues, or not, because there could still be private cases
>>>defined in a .m file?
>>>  - If there's an Objective-C enum in *another* framework (that I
>>>built locally with Xcode, Carthage, CocoaPods, SwiftPM, etc.),
>>>should it allow exhaustive switching, because there are no
>>>*binary* compatibility issues, or not, because there may be
>>>*source* compatibility issues? We'd really like adding a new enum
>>>case to *not* be a breaking change even at the source level.
>>>  - If there's an Objective-C enum coming in through a bridging
>>>header, should it allow exhaustive switching, because I might
>>>have defined it myself, or not, because it might be non-modular
>>>content I've used the bridging header to import?
>>>
>>>  And in Swift:
>>>
>>>  - If there's a Swift enum in another framework I built locally,
>>>should it allow exhaustive switching, because there are no binary
>>>compatibility issues, or not, because there may be source
>>>compatibility issues? 

Re: [swift-evolution] [Pitch] Guard/Catch

[Zach Waldowski via swift-evolution]

I second Xiaodi on this. The syntax feels like a slam-dunk. The only
concerns I have are indentation, and ultimately that's not my problem to
decide about. ;)
Sincerely,
  Zachary Waldowski
  z...@waldowski.me

On Wed, Jul 5, 2017, at 07:15 PM, Xiaodi Wu via swift-evolution wrote:
> Initially, this proposal felt a little off, but on re-reading, I think
> I like it very much. It shows that guard/catch is meant to solve a
> nesting problem (just like guard/else was meant to solve one), and it
> preserves the idea that the else/catch clause must exit the outer
> scope, which is very important to the meaning of `guard`.> 
> I agree with the proposal authors that mix-and-match guard/catch/else
> feels unwise. I see no reason why rewriting to repeat only the word
> `guard` (as in, `guard A catch { }; guard B else { }` instead of
> `guard A, B catch { } else { }`) is onerous enough to justify a syntax
> that is clearly harder to reason about.> 
> On Wed, Jul 5, 2017 at 2:25 PM, Soroush Khanlou via swift-evolution
>  wrote:>> Jon — we explored allowing users to mix 
> and match optional unwrapping
>> and error catching in the same guard, but found that it was
>> ultimately pretty confusing. We think that guard/else and guard/catch
>> should be two totally different components. Dave’s email lays out the
>> two best approaches, and the “Alternatives Considered” section of the
>> proposal goes into why those alternatives were ultimately rejected.>> 
>>> On Jul 5, 2017, at 2:09 PM, Dave DeLong via swift-evolution >> evolut...@swift.org> wrote:>>> 
>>> Soroush’s proposal has the idea that maybe we could do multiple
>>> blocks for this scenario, like so:>>> 
>>> guard try something(), let thing = optionalThing catch {
>>> // try something() failed
>>> } else {
>>> // the let-binding failed
>>> }
>>> 
>>> 樂 Alternatively, what if the “error” captured was optional in this
>>> scenario?>>> 
>>> guard try something(), let thing = optionalThing catch {
>>> if let error = error {
>>> // the try call failed
>>> } else {
>>> // the optional binding failed
>>> }
>>> }
>>> 
>>> Dave
>>> 
 On Jul 5, 2017, at 12:00 PM, Jon Shier via swift-evolution >>> evolut...@swift.org> wrote: 
 I didn’t think I was going to like it but I really do. My only
 concern, which isn’t really a deal breaker, is what it would look
 like to chain multiple try and let statement in the same guard.
 Unless that scenario works well I don’t think you could convince
 others. i.e. In the case where I have: 
 guard try something(), let thing = optionalThing catch { }
 
 What happens when the let fails? No implicit error?
 
 
 
 Jon
 
 
> On Jul 5, 2017, at 1:30 PM, Soroush Khanlou via swift-evolution
>  wrote:> 
> I’d like to propose a guard/catch construct to the language. It
> would allow code to use throwing functions and handle errors
> fully, without straying from a happy path. do/catch can be a bit
> heavy-handed sometimes, and it would be nice to be able to handle
> throwing functions without committing to all the nesting and
> ceremony of do/catch.> 
> Full proposal, which discusses all the corner cases and
> alternatives:> 
> https://gist.github.com/khanlou/8bd9c6f46e2b3d94f0e9f037c775f5b9
> 
> Looking forward to feedback!
> 
> Soroush
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
 
 ___
 swift-evolution mailing list
 swift-evolution@swift.org
 https://lists.swift.org/mailman/listinfo/swift-evolution
>>> 
>>> ___
>>> swift-evolution mailing list
>>> swift-evolution@swift.org
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>> 
>> 
>> ___
>>  swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>> 
> _
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

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

Re: [swift-evolution] [Pitch] Introducing the "Unwrap or Die" operator to the standard library

[Zach Waldowski via swift-evolution]

Big +1.

Using `!` is widely seen as a smell. However, the need for it still
arises; they are preconditions, of a sort. It has become prevalent in my
teams’ codebases to do “guard else preconditionFailure”.
I like `!!` over something like `?!`; it follows the pattern that almost
every `?` in the language has an equivalent `!`.
The implementation details are ultimately not relevant to me. I’m a fan
of `Never` being a bottom type for more reasons than just this. I also
see no reason why operator funcs couldn’t accept file and line as extra
arguments on the rhs.
Best,
  Zachary Waldowski
  z...@waldowski.me

On Tue, Jun 27, 2017, at 01:16 PM, Erica Sadun via swift-evolution wrote:> 
Using an operator to provide feedback on the context of a failed
> unwrap has become a commonly implemented approach in the Swift
> developer Community. What are your thoughts about adopting this widely-
> used operator into the standard library?> 
> guard !lastItem.isEmpty else { return }
> let lastItem = array.last !! "Array must be non-empty"
> 
> Details here:
> https://gist.github.com/erica/423e4b1c63b95c4c90338cdff4939a9b> 
> Thank you for your thoughtful feedback, -- E
> 
> _
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

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

Re: [swift-evolution] Pitch: Omit deprecation warnings for same-file references

[Zach Waldowski via swift-evolution]

I understand the reasoning and am in favor of it for those reasons, but
I will note that I use deprecations extremely frequently while
refactoring, and this would defeat that use case. As I have a few larger
projects with long compile times, losing that functionality would be
disappointing.
Sincerely,
  Zachary Waldowski
  z...@waldowski.me


On Fri, May 5, 2017, at 02:12 PM, Tony Allevato via swift-evolution wrote:> Hey 
Swift Evolvers,
> 
> I'd like to propose a change that would suppress deprecation warnings
> when the reference to the deprecated declaration is in the same file
> as that declaration.> 
> This personally affects one of my projects (Swift protocol buffers)
> because .proto files allow declarations to be declared as deprecated,
> and we'd like to surface that by deprecating the equivalent
> declaration in the Swift code that we generate. We can't do this
> without generating noisy build logs, because we still need to
> reference the deprecated declarations to encode/decode the messages
> correctly; and the workarounds have significant performance penalties
> as described in the draft.> 
> I'd love some feedback from folks to know whether this—or something
> like it—is something that seems desirable/undesirable for the
> language. I've tinkered with an implementation in a branch[1] and it's
> fairly straightforward.> 
> Gist link:
> https://gist.github.com/allevato/76f098a761147f3be5017d10a6f4ecbb> 
> 
> Omit deprecation warnings for same-file references


>  * Proposal: SE-[2]
>  * Author(s): Tony Allevato[3]
>  * Status: Awaiting review[4]
>  * Review manager: TBD> Introduction


> Public API developers can use the @available attribute in Swift to
> mark APIs as deprecated, which will emit warnings when a user
> references that API to notify them that that particular API is no
> longer preferred or may disappear in the future.> These warnings are emitted 
> for *any* reference to a deprecated
> entity, including those in the same file. In some cases, however, it
> may be necessary and correct to continue referring to the deprecated
> entity privately while discouraging its external use. In these
> scenarios, the warnings are superfluous and generate noise in the
> build logs. We propose eliminating these warnings for references made
> in the same file.> Swift-evolution thread: TBD[5]


> Motivation


> As APIs evolve, declarations may become deprecated but still need to
> be referenced privately in order to function correctly. For example,
> consider an object that is serialized/parsed between a client and
> server. The first iteration of such a type might look like this (the
> examples use a strawman API to avoid tying the discussion too closely
> with the new coding APIs, which is not the focus):> public class Person {  
> public var name: String  public var
> phoneNumber: String?   public init(name: String, phoneNumber: String?
> = nil) {  self.name = name  self.phoneNumber = phoneNumber }   public
> convenience init?(from reader: Reader) {  guard let name =
> reader.readString(withKey: "name") else {  return nil }  let
> phoneNumber = reader.readString(withKey: "phoneNumber")
> self.init(name: name, phoneNumber: phoneNumber) }   public func
> write(to writer: Writer) { writer.write(name, key: "name")  if let
> phoneNumber = phoneNumber { writer.write(phoneNumber, key:
> "phoneNumber") } } }> Later, we decide that we need to support storing 
> multiple phone
> numbers for a Person. To avoid breaking source compatibility, we
> deprecate the old property and add a new one. We still wish the
> encoding/decoding process to preserve the integrity of the old data,
> however—for example, a middleman process used for logging should not
> modify the data stream, so the encoding/decoding process should not be
> also migrating the data. Thus, we update the class to the following:> public 
> class Person {  public var name: String  @available(*,
> deprecated, message: "use 'phoneNumbers' instead")  public var
> phoneNumber: String?  public var phoneNumbers: [String]
> @available(*, deprecated, message: "use 'init(name:phoneNumbers:)'
> instead")  public convenience init(name: String, phoneNumber: String?)
> {  self.phoneNumber = phoneNumber  self.init(name: name, phoneNumbers:
> []) }   public init(name: String, phoneNumbers: [String] = []) {
> self.name = name  self.phoneNumber = nil  self.phoneNumbers =
> phoneNumbers }   public convenience init?(from reader: Reader) {
> guard let name = reader.readString(withKey: "name") else {  return nil
> }  let phoneNumbers = reader.readStringArray(withKey: "phoneNumbers")
> ?? []  self.phoneNumber = reader.readString(withKey: "phoneNumber")
> self.init(name: name, phoneNumbers: phoneNumbers) }   public func
> write(to writer: Writer) { writer.write(name, key: "name")  if let
> phoneNumber = phoneNumber { writer.write(phoneNumber, key:
> "phoneNumber") }  if !phoneNumbers.isEmpty {
> writer.write(phoneNumbers, key: "phoneNumbers") } } }> This type is 

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0166: Swift Archival & Serialization

[Zach Waldowski via swift-evolution]

On Fri, Apr 21, 2017, at 11:26 AM, Tony Parker via swift-evolution wrote:> One 
more thing, which we realized after I sent my original email: the
> default implementation of many of the protocols needs to throw errors.
> Therefore we will add enum EncodingError and enum DecodingError to the
> list of new types. Those enums will have various associated values
> according to what is useful debug information. To preserve the ability
> for developers to present these errors to users with localized and user-
> presentable messages, when these enums are cast to NSError (e as?
> NSError), they will have the Cocoa error domain and a Foundation-
> provided code. (This is done via an extension to the enum in
> Foundation).
This is the best possible outcome for layering. Thanks to everyone
involved for reconsidering that.
Sincerely,
  Zachary Waldowski
  z...@waldowski.me


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

Re: [swift-evolution] [Review] SE-0166: Swift Archival & Serialization

[Zach Waldowski via swift-evolution]

I want to disagree with this is strongly as possible lest it influence
the proposal in any way whatsoever. Just because you can solve something
through reflection doesn't mean you should.

  Zachary Waldowski
  z...@waldowski.me

On Wed, Apr 12, 2017, at 03:22 PM, Brad Hilton via swift-evolution
wrote:
> -1. I support the motivation, but I think this proposal and SE-0167 are
> too premature.
> 
> Don’t get me wrong, I think that Swift leaves much to be desired as far
> as serialization/deserialization goes. However I think that these
> proposals are putting the cart before the horse. I think we first need to
> add genuine reflection APIs before adding encoding/decoding capabilities
> to the stdlib. Reflection will substantially simply most
> serialization/deserialization task. These APIs borrow too much Cocoa’s
> native archiving capabilities for my taste and I’d rather not introduce
> something that may be considered legacy in the future.
> 
> 
> > Hello Swift community,
> > 
> > 
> > The review of SE-0166 "Swift Archival" begins now and runs 
> > through April 12, 2017. The proposal is available here:
> > 
> > > https://github.com/apple/swift-evolution/blob/master/proposals/0166-swift-archival-serialization.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/0166-swift-archival-serialization.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,
> > 
> > 
> > -Doug
> > 
> > 
> > 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

Re: [swift-evolution] SE-165: Dictionary & Set Enhancements

[Zach Waldowski via swift-evolution]

Responses inline.



Best,

  Zachary Waldowski

  z...@waldowski.me





On Wed, Apr 5, 2017, at 08:45 PM, Ben Cohen via swift-evolution wrote:

> • What is your evaluation of the proposal?



Overall, +1. Dictionary and in Set are in need of interaction
improvements. However, given the increased need for considering source
stability, I'm of the opinion adding new stuff to the stdlib should face
an appropriately high bar; so specific and nit-picky notes follow.


- The `init(_ keysAndValues: Sequence)` should be `init?(_:)`.

- The merging family does not feel completely in line with Swift
  naming. Considering other closure-taking methods in the stdlib, I
  feel like "by mergingValues" is a better fit, since "merg[ing]"
  already comes up in the signature, netting you `Dictionary(merging:
  listOfPairs, by: max)`.
- I'm not sure subscripts allow all this right now, but `default
  defaultValue` seems like an appropriate candidate for being
  `@autoclosure` and `throws`, and the subscript itself `rethrows`.
- I retract my concerns over the merging methods, but I still don't see
  the API benefit of `mapValues`. This doesn't seem like it pulls its
  weight besides an optimization. With SE-0154 and conditional
  conformances, I feel like the same optimization could be possible with
  `init(_ keysAndValues: Sequence)` and `lazy`. So -1 there.
- Source-breaking changes from `filter(_:)` overloads feel more
  problematic than described in the proposal. Both behaviors (returning
  Self and returning Array) are useful, and I don't want to lose easy
  calling of one. The desired behavior can also be accomplished using
  one of the initializers and `filter` or `lazy.filter`. -0.5 on that.
- As much as I want it personally, `grouped(by:)` feels like a weak
  specialization of `init(merging:mergingValues:)`. Now, of course, that
  would be better (for performance, readability, etc.) if `combine` were
  `inout`. This parallels nicely with the subscript-with-default being a
  mutating l-value. I don't remember how `reduce`-with-`inout` fell out
  back in January, but this feels like it's in similar territory. I just
  don't want to lock us into a collection of methods that are only
  slightly only different enough to be frustrating when using them.


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


For sure. Arrays and generalized collections are best-in-class; the
hashed collections are only slightly less so.


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



With some nits as noted above, yes.



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


I, for one, don't feel like Dictionary needs to shoot much past the
capabilities of NSMutableDictionary, but should definitely at least
match it; this proposal gets us pretty close.


> • How much effort did you put into your review? A glance, a quick
> reading, or an in-depth study?


Followed the proposal since inception. Uh, big user of dictionaries,
I suppose.


> 

> More information about the Swift evolution process is available at
> https://github.com/apple/swift-evolution/blob/master/process.md
> 

> Thank you,

> 

> Ben Cohen

> 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

Re: [swift-evolution] [Proposal] Foundation Swift Archival & Serialization

[Zach Waldowski via swift-evolution]

OK, understood. Thanks!



Zach



On Tue, Apr 4, 2017, at 05:53 PM, Itai Ferber wrote:

> Hi Zach,



> Thanks for your comments!

>  The type is called "unkeyed", but I assume "nonkeyed" was a typo and
>  that's what you meant. As far as the phrasing of "ordered" and
>  "sequential", both sound good, but:


>  1. The symmetry between "keyed" and "unkeyed" is helpful in creating
> opposition between types of encoding (and especially so in
> comparison to "single value", which is the odd man out — and you'd
> extremely rarely need to interact with it)
>  2. Given something that's "x" or "not x", you'd generally gravitate
> toward the thing with the more positive phrasing. As you mention,
> we really want to encourage keyed containers and diminish the use
> of unkeyed containers unless truly necessary, because they're
> fragile. The problem is, it's much easier to use the unkeyed
> containers — especially accidentally as a novice, since they're
> much simpler API — and I think "ordered" and "sequential" don't go
> far enough to detract from their usage.
> They sound good, and in fact, too good, and we find that more negative
> phrasing is helpful.
> — Itai



> On 3 Apr 2017, at 16:01, Zach Waldowski via swift-evolution wrote:



> 



> 

>> Itai and co:

>> 

>> This is a solid improvement.

>> 

>> I think it's appropriate to diminish the importance of non-keyed
>> containers. "Nonkeyed" as the name is pretty iffy to me, though, even
>> though I admit it makes the use case pretty clear. "Ordered" or
>> "Sequential" both sound fine, even for an encoder that's slot-based
>> instead of  NSArchiver-like model. An array is ordered but you don't
>> have to traverse it in order.
>> 

>> Best,

>>   Zachary Waldowski

>>   z...@waldowski.me

>> 

>> 

>> On Mon, Apr 3, 2017, at 04:31 PM, Itai Ferber via swift-
>> evolution wrote:
>>> Hi everyone,



>>> With feedback from swift-evolution and additional internal review,
>>> we've pushed updates to this proposal, and to the Swift Encoders[1]
>>> proposal. In the interest of not blowing up mail clients with the
>>> full HTML again, I'll simply be linking to the swift-evolution PR
>>> here[2], as well as the specific diff[3] of what's changed.
>>> At a high level:


>>>  * The Codable protocol has been split up into Encodable and
>>>Decodable
>>>  * String keys on CodingKey are no longer optional
>>>  * KeyedEncodingContainer has become
>>>KeyedEncodingContainerProtocol, with a concrete type-erased
>>>KeyedEncodingContainer struct to hold it
>>>  * Array responsibilities have been removed from
>>>KeyedEncodingContainer, and have been added to a new
>>>UnkeyedEncodingContainer type
>>>  * codingKeyContext has been renamed codingPath
>>> There are some specific changes inline — I know it might be a bit of
>>> a pain, but let's keep discussion here on the mailing list instead
>>> of on GitHub. We'll be looking to start the official review process
>>> very soon, so we're interested in any additional feedback.
>>> Thanks!



>>> — Itai



>>> _

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



> 




Links:

  1. https://github.com/apple/swift-evolution/pull/640
  2. https://github.com/apple/swift-evolution/pull/639
  3. 
https://github.com/apple/swift-evolution/pull/639/commits/d619eef9166f8b45ffac152d06376cbdab536241
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Type-based ‘private’ access within a file

[Zach Waldowski via swift-evolution]

On Mon, Apr 3, 2017, at 07:55 PM, Brent Royal-Gordon via swift-evolution wrote:
> Honestly, I think it's becoming increasingly clear that no access
> control design will ever satisfy everybody. So let's lock down the
> unsatisfactory design we know, rather than the unsatisfactory design
> we don't.


I agree with every point up to, but excluding, this conclusion. A broken
language will remain broken forever.


Zachary Waldowski

z...@waldowski.me




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

Re: [swift-evolution] [Proposal] Foundation Swift Archival & Serialization

[Zach Waldowski via swift-evolution]

Itai and co:



This is a solid improvement.



I think it's appropriate to diminish the importance of non-keyed
containers. "Nonkeyed" as the name is pretty iffy to me, though, even
though I admit it makes the use case pretty clear. "Ordered" or
"Sequential" both sound fine, even for an encoder that's slot-based
instead of  NSArchiver-like model. An array is ordered but you don't
have to traverse it in order.


Best,

  Zachary Waldowski

  z...@waldowski.me





On Mon, Apr 3, 2017, at 04:31 PM, Itai Ferber via swift-evolution wrote:
> Hi everyone,



> With feedback from swift-evolution and additional internal review,
> we've pushed updates to this proposal, and to the Swift Encoders[1]
> proposal. In the interest of not blowing up mail clients with the full
> HTML again, I'll simply be linking to the swift-evolution PR here[2],
> as well as the specific diff[3] of what's changed.
> At a high level:


>  * The Codable protocol has been split up into Encodable and Decodable
>  * String keys on CodingKey are no longer optional
>  * KeyedEncodingContainer has become
>KeyedEncodingContainerProtocol, with a concrete type-erased
>KeyedEncodingContainer struct to hold it
>  * Array responsibilities have been removed from
>KeyedEncodingContainer, and have been added to a new
>UnkeyedEncodingContainer type
>  * codingKeyContext has been renamed codingPath
> There are some specific changes inline — I know it might be a bit of a
> pain, but let's keep discussion here on the mailing list instead of on
> GitHub. We'll be looking to start the official review process very
> soon, so we're interested in any additional feedback.
> Thanks!



> — Itai



> _

> swift-evolution mailing list

> swift-evolution@swift.org

> https://lists.swift.org/mailman/listinfo/swift-evolution




Links:

  1. https://github.com/apple/swift-evolution/pull/640
  2. https://github.com/apple/swift-evolution/pull/639
  3. 
https://github.com/apple/swift-evolution/pull/639/commits/d619eef9166f8b45ffac152d06376cbdab536241
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Type-based ‘private’ access within a file

[Zach Waldowski via swift-evolution]

Depending on the actual implications of the loosening of `private`, I'd
then advocate for deprecating `fileprivate` in the Swift 4 timeframe and
removing when it makes sense. Is that an option?


I am personally against muddying the implementation of access control
further (in addition to its existing muddying in the syntactical sense,
but let's avoid rehashing that now), and would like it if someone from
the Core Team could speak to the complexities involved there. I wouldn't
want access control changes to, for instance, hurt compile times or
stymie ABI efforts.


Sincerely,

  Zachary Waldowski

  z...@waldowski.me





On Mon, Apr 3, 2017, at 02:34 PM, Douglas Gregor via swift-evolution wrote:
> Hello Swift Community,

> 

> In rejecting SE-0159[1], the core team described a potential direction
> we would like to investigate for “private” access control that admits
> a limited form of type-based access control within files. The core
> team is seeking some discussion here and a motivated volunteer to put
> together a proposal along these lines for review in the Swift 4 time-
> frame (i.e., very soon). To be clear, the core team it’s sure this is
> the right direction to go… but it appears promising and we would
> *love* to be able to settle the access-control issue.
> 

> The design, specifically, is that a “private” member declared within a
> type “X” or an extension thereof would be accessible from:
> 

> * An extension of “X” in the same file

> * The definition of “X”, if it occurs in the same file

> * A nested type (or extension thereof) of one of the above that occurs
>   in the same file
> 

> This design has a number of apparent benefits:

> + “private” becomes the right default for “less than whole module”
>   visibility, and aligns well with Swift coding style that divides a
>   type’s definition into a number of extensions.
> + “fileprivate” remains for existing use cases, but now it’s use it
>   more rare, which has several advantages:
> + It fits well with the "progressive disclosure” philosophy behind
>   Swift: you can use public/internal/private for a while before
>   encountering and having to learn about “fileprivate”   (note: we
>   thought this was going to be true of SE-0025[2], but we were clearly
>   wrong)
> + When “fileprivate” occurs, it means there’s some interesting
>   coupling between different types in the same file. That makes
>   fileprivate a useful alert to the reader rather than, potentially,
>   something that we routinely use and overlook so that we can separate
>   implementations into extensions.
> + “private” is more closely aligned with other programming languages
>   that use type-based access control, which can help programmers just
>   coming to Swift. When they reach for “private”, they’re likely to
>   get something similar to what they expect—with a little Swift twist
>   due to Swift’s heavy use of extensions.
> + Loosening the access restrictions on “private” is unlikely to break
>   existing code.
> 

> There are likely some drawbacks:

> - Developers using patterns that depend on the existing lexically-
>   scoped access control of “private” may find this new interpretation
>   of “private” to be insufficiently strict
> - Swift’s access control would go from “entirely lexical” to “partly
>   lexical and partly type-based”, which can be viewed as being more
>   complicated
> 

> Thoughts? Volunteer?

> 

> - Doug

> _

> swift-evolution mailing list

> swift-evolution@swift.org

> https://lists.swift.org/mailman/listinfo/swift-evolution




Links:

  1. 
https://github.com/apple/swift-evolution/blob/master/proposals/0159-fix-private-access-levels.md
  2. 
https://github.com/apple/swift-evolution/blob/master/proposals/0025-scoped-access-level.md
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Review] SE-0161: Smart KeyPaths: Better Key-Value Coding for Swift

[Zach Waldowski via swift-evolution]

On Thu, Mar 30, 2017, at 12:25 PM, Douglas Gregor wrote:
>  * What is your evaluation of the proposal?


Weak +0.5. This is absolutely needed, and I don't want to see the
feature broken down any further through interminable bikeshedding,
so I'd be more willing to let it ride as-is than miss out on having
this feature.


I was personally quite happy with the original proposal text. Worrying
about interaction with type properties reminds me of the pearl-clutching
when lightweight generics were added to ObjC over ambiguity with
protocol conformance statements, to which, IIRC, the involved people
stated, "Don't worry. The compiler's got this. It's its job."


I can't really get behind a syntax with this amount of clunkiness. The
second example — `foo[keyPath: #keyPath(.bar.baz)]` — is egregious.
Perhaps the proposal is right that you'd rarely see it, but I take
umbrage with "never". Teaching smart key paths will require building up
from base principles just like the proposal, and from that perspective
it looks like a syntax designed out of compatibility concerns in a much
older language, not the best it could be on its own.


The leading dot inference is extremely desirable to limit repetition,
but the difference in behavior with lookup for #selector and ObjC-style
#keyPath will be confusing for many. "Why was it not compiling?" "You
have a leading dot when you shouldn't." That doesn't sound like a
satisfying experience unless the diagnostic is truly superlative.


Ultimately, the Core Team and the community have to make an opinionated
decision about this feature's impact on the language. Though I
understand (and believe in) progressive disclosure, I don't think it
behooves us to "hide" "advanced" syntax. `#foo` sigils feel like compatibility-
driven hacks. If, like me, you think unbounded methods and unbounded
properties form the lowercase-f foundation for Swift's answer to Cocoa-
quality dynamism, then the feature should have that policy reflected
appropriately in its syntax.

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


Absolutely. See what I say above — the time is right for well-
considered, powerful, but low-impact language additions. Key-paths would
be a sea-change for data-flow (reactive, etc.) frameworks and for DSLs.

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


The feature — yes. The syntax — not quite.


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


I've extensively used Cocoa's similar features. I can see, perhaps
just barely, where AnyKeyPath would be NSKeyPath in another universe,
and in that sense it's a great accomplishment building out these
features for Swift.

>  * How much effort did you put into your review? A glance, a quick
>reading, or an in-depth study?


In-depth study of the original proposal; followed the mailing list
threads; quick re-review of the modified proposal.


Sincerely,

  Zachary Waldowski

  z...@waldowski.me




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

Re: [swift-evolution] [Draft] Dictionary & Set Enhancements

[Zach Waldowski via swift-evolution]

Right-favoring:



for (key, value) in rhs {

lhs[key] = value

}



Left-favoring:



for (key, value) in rhs where lhs[key] == nil {

lhs[key] = value

}



Throws an error:



for (key, value) in rhs {

guard lhs[key] == nil else { throw Foo() }

lhs[key] = value

}



The barrier to inclusion in the stdlib should not merely be if someone's
had to write it before, otherwise there's no reason not to include your
Instagram-but-for-cats client full-on in the OS.


Doing these as needed yourself are not  unreasonably complex or error-
prone — unlike, say, Unicode — but they _are_ pretty domain specific.


I'm personally not in favor of  additions to the standard library that
have an associated Options or Strategy type. "Well," you may respond,
"we don't want to add a bunch of overloads, either! That'd be
confusing!" And that's exactly what I'm getting at - either way you
slice it, every addition to the stdlib has a concrete impact on the
mental model of  the language.


Moreover, I am wary of language additions that can't (or we don't want
to) be modeled in terms of Collection, because we risk limiting the
growth of the latter as we get better generics features.


Best,

  Zachary Waldowski

  z...@waldowski.me





On Sat, Apr 1, 2017, at 12:01 PM, Jason Gregori via swift-evolution wrote:
> I really like the merging methods and have already needed to write my
> own. Zach, do you mind showing a comparison of what you're thinking?
> 

> Nate, do you mind throwing this up in a gist or something? My email
> client isn't letting me see the whole thing.
> 

> Thanks, 

> Jason

> 

> 

> On Fri, Mar 31, 2017 at 11:52 AM Zach Waldowski via swift-evolution
> <swift-evolution@swift.org> wrote:
>> __

>> Snipped quoted proposal so as to not break the mailing list… By and
>> large, I'm in favor. I like the potential for bringing up Dictionary
>> and Set up to the implementation quality of Array and String.
>> 

>> I don't think `init(merging:resolvingCollisionsWith:)` et al hold
>> their weight for inclusion in the language, unless some notable
>> optimization opportunity can be surfaced out of it. Users frustrated
>> at the lack of a `merge` in Swift want it to be opinionated and "just
>> do the right thing," i.e., the same way as whatever other language
>> they most recently used. A properly annotated and indented-to-be-
>> beautiful use of the closure-based version will take up the same
>> amount of code as doing the merge by hand with your custom condition.
>> 

>> Sincerely,

>>   Zachary Waldowski

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


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

Re: [swift-evolution] [Draft] Dictionary & Set Enhancements

[Zach Waldowski via swift-evolution]

Snipped quoted proposal so as to not break the mailing list… By and
large, I'm in favor. I like the potential for bringing up Dictionary and
Set up to the implementation quality of Array and String.


I don't think `init(merging:resolvingCollisionsWith:)` et al hold their
weight for inclusion in the language, unless some notable optimization
opportunity can be surfaced out of it. Users frustrated at the lack of a
`merge` in Swift want it to be opinionated and "just do the right
thing," i.e., the same way as whatever other language they most recently
used. A properly annotated and indented-to-be-beautiful use of the closure-
based version will take up the same amount of code as doing the merge by
hand with your custom condition.


Sincerely,

  Zachary Waldowski

  z...@waldowski.me


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

Re: [swift-evolution] [Pitch] String revision proposal #1

[Zach Waldowski via swift-evolution]

On Thu, Mar 30, 2017, at 12:35 PM, Félix Cloutier via swift-evolution wrote:
> I don't have much non-nitpick issues that I greatly care about; I'm in
> favor of this.
> 

> My only request: it's currently painful to create a String from a fixed-
> size C array. For instance, if I have a pointer to a `struct foo {
> char name[16]; }` in Swift where the last character doesn't have to be
> a NUL, it's hard to create a String from it. Real-world examples of
> this are Mach-O LC_SEGMENT and LC_SEGMENT_64 commands.
> 

> 

> The generally-accepted wisdom[1] is that you take a pointer to the
> CChar tuple that represents the fixed-size array, but this still
> requires the string to be NUL-terminated. What do we think of an
> additional init(cString:) overload that takes an UnsafeBufferPointer
> and reads up to the first NUL or the end of the buffer, whichever
> comes first?


Today's String already supports this through
`String.decodeCString(_:as:repairingInvalidCodeUnits:)`, passing a
buffer pointer.


Best,

  Zachary Waldowski

  z...@waldowski.me








Links:

  1. http://stackoverflow.com/a/27456220/251153
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Pitch] String revision proposal #1

[Zach Waldowski via swift-evolution]

Loving it so far.



`encode` and `parseScalar[Forward|Backward]` feel asymmetric. What's
wrong with `decode[Forward|Backward]`?


`UnicodeParseResult` really feels like it could/should be
defined as `UnicodeEncoding.ParseResult` (or `DecodeResult`,
given the above). I can't remember if that generics limitation was
being lifted?


Best,

  Zachary Waldowski

  z...@waldowski.me





On Wed, Mar 29, 2017, at 08:32 PM, Ben Cohen via swift-evolution wrote:
> Hi Swift Evolution,

> 

> Below is a pitch for the first part of the String revision. This
> covers a number of changes that would allow the basic internals to be
> overhauled.
> 

> Online version here:
> https://github.com/airspeedswift/swift-evolution/blob/3a822c799011ace682712532cfabfe32e9203fbb/proposals/0161-StringRevision1.md
> 

> 

> String Revision: Collection Conformance, C Interop, Transcoding


>  * Proposal: SE-0161
>  * Authors: Ben Cohen[1], Dave Abrahams[2]
>  * Review Manager: TBD
>  * Status: *Awaiting review*
> Introduction



> This proposal is to implement a subset of the changes from the Swift 4
> String Manifesto[3].
> Specifically:


>  * Make String conform to BidirectionalCollection
>  * Make String conform to RangeReplaceableCollection
>  * Create a Substring type for String.SubSequence
>  * Create a Unicode protocol to allow for generic operations over both
>types.
>  * Consolidate on a concise set of C interop methods.
>  * __Revise the transcoding infrastructure.
> Other existing aspects of String remain unchanged for the purposes of
> this proposal.
> Motivation



> This proposal follows up on a number of recommendations found in the
> manifesto:
> Collection conformance was dropped from String in Swift 2. After
> reevaluation, the feeling is that the minor semantic discrepancies
> (mainly with RangeReplaceableCollection) are outweighed by the
> significant benefits of restoring these conformances. For more detail
> on the reasoning, see here[4]
> While it is not a collection, the Swift 3 string does have slicing
> operations. String is currently serving as its own subsequence,
> allowing substrings to share storage with their “owner”. This can lead
> to memory leaks when small substrings of larger strings are stored long-
> term (see here[5] for more detail on this problem). Introducing a
> separate type of Substring to serve as String.Subsequence is
> recommended to resolve this issue, in a similar fashion to ArraySlice.
> As noted in the manifesto, support for interoperation with nul-
> terminated C strings in Swift 3 is scattered and incoherent, with 6
> ways to transform a C string into a String and four ways to do the
> inverse. These APIs should be replaced with a simpler set of methods
> on String.
> Proposed solution



> A new type, Substring, will be introduced. Similar to ArraySlice it
> will be documented as only for short- to medium-term storage:
>> *Important*



>> Long-term storage of Substring instances is discouraged. A substring
>> holds a reference to the entire storage of a larger string, not just
>> to the portion it presents, even after the original string’s lifetime
>> ends. Long-term storage of a substring may therefore prolong the
>> lifetime of elements that are no longer otherwise accessible, which
>> can appear to be memory leakage.
> Aside from minor differences, such as having a SubSequence of Self and
> a larger size to describe the range of the subsequence, Substring will
> be near-identical from a user perspective.
> In order to be able to write extensions accross both String and
> Substring, a new Unicode protocol to which the two types will conform
> will be introduced. For the purposes of this proposal, Unicode will be
> defined as a protocol to be used whenver you would previously extend
> String. It should be possible to substitute extension Unicode { ... }
> in Swift 4 wherever extension String { ... } was written in Swift 3,
> with one exception: any passing of self into an API that takes a
> concrete String will need to be rewritten as String(self). If Self is
> a String then this should effectively optimize to a no-op, whereas if
> Self is a Substring then this will force a copy, helping to avoid the
> “memory leak” problems described above.
> The exact nature of the protocol – such as which methods should be
> protocol requirements vs which can be implemented as protocol
> extensions, are considered implementation details and so not covered
> in this proposal.
> Unicode will conform to BidirectionalCollection.
> RangeReplaceableCollection conformance will be added directly onto the
> String and Substring types, as it is possible future Unicode-
> conforming types might not be range-replaceable (e.g. an immutable
> type that wraps a const char *).
> The C string interop methods will be updated to those described
> here[6]: a single withCString operation and two init(cString:)
> constructors, one for UTF8 and one for arbitrary encodings. The
> primary change is to 

Re: [swift-evolution] [Review] SE-0159: Fix Private Access Levels

[Zach Waldowski via swift-evolution]

I admit feeling great dismay at finally posting "MY REVIEW", given the
generally sour nature of the discourse of the thread. However, I feel
like it was a mistake to not have voiced my concern in the SE-0025
fight, so here we are.


On Mon, Mar 20, 2017, at 07:54 PM, Douglas Gregor via swift-evolution wrote:
>  * What is your evaluation of the proposal?


Overwhelmingly vehement +1 for any implementation this idea can take. I
personally prefer reverting to Swift 2 behavior, full-stop.


As others have noted, the text of the proposal leaves a little to be
desired on some of the context. However, I do not believe this prevents
making a decision on the matter. ("To post a proposal to Swift
Evolution, one must first invent the universe…)

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


The lack of proper consideration, caution, or even solid
implementation of the scoped access modifier is the biggest mistake
the Evolution community has made yet. It is a non-trivially broken
feature with no plans to fix it. If I had to choose between the 15-ish
implemented proposals created wholly by the community and not having
ever had SE-0025 be a twinkle in anyone's eye, I'm honestly not sure
which I'd choose.

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


In the most literal sense, it does not, but that's the point: Swift's
thought on access control is in need of a course correction, for reasons
I lay out in the next question.

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


I've had plenty of experience in other languages both with and without
access control.


This specific smell in Swift's access control is a sign of a simply
untenable direction. I find C++ access control similarly untenable due
to its confusing variations and edge cases. Swift is heading down a
similar path.


Swift has the laudable goal of being a multi-modal and multi-paradigm
language. That does not mean it cannot be opinionated. Inspecting access
control in a single file is trivial, and if it's not, that's your
problem. I don't care at this point to hear the gospel of all the magic
I can accomplish in unmaintainable large files.


I keep thinking of SE-0009, which was rejected quite plainly for
"introduc[ing] a significant amount of verbosity that does not justify
itself with added clarity". After being immersed in this topic for what
feels like eons, and having my own opinions explained to me several
times, I truly cannot see how scope-private/the fileprivate change was
any different.


Nowadays, my codebases are littered with chains of attributes like
`@IBOutlet fileprivate private(set) weak var`. It look less like working
in a language of sane defaults and look more like I had a stroke while
typing it out. This change has been the antithesis of clarity, and the
inability of +1-ers to see it any other way than theirs is an upsetting
application of, "F*** you, got mine." I'm glad you all understand the
change and have incorporated it into your work, I really am. I haven't;
I still don't.

>  * How much effort did you put into your review? A glance, a quick
>reading, or an in-depth study?


I have followed the thread(s) closely, and done much follow-up and
discussion about this issue off the mailing lists.


I beseech the Core Team to act decisively to restore sanity to this part
of the language. I don't care if that means being for or against this
particular proposal. I don't care if it's a spelling change, hinting at
a future plan for submodules, or explaining what the happy path will be
for creating modules  in Xcode 9. I just ask that they think of the
developers who are being underrepresented in this discussion out of
inexperience, lack of understanding, or, worse, having stopped using
Swift in frustration.


I am now absolutely thrilled to create a filter to Mark As Read anything
else arising from this thread. Good luck.


Sincerely,

  Zachary Waldowski

  z...@waldowski.me




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

Re: [swift-evolution] [Review] SE-0159: Fix Private Access Levels

[Zach Waldowski via swift-evolution]

On Fri, Mar 24, 2017, at 05:59 AM, Jonathan Hull via swift-evolution wrote:
> **This is not something that will go away simply by learning the
> behavior.  It will continue to be a rough spot in the language that
> causes discomfort until the underlying design issue is fixed.**


I want to keep repeating this statement from Jonathan until someone
actually pays attention to it. The impedance mismatch between the access
levels is not simply programmer flavor. It  taints the basic nature of
learning Swift, and learning those different styles.


I want to be open to other programming styles, and would be interested
in using the one that so desperately "needs" scope private as people on
this thread claim. Except I'm turned off it immediately by having to
accommodate this jagged, ugly, bleeding edge of the language.


Best,

  Zachary Waldowski

  z...@waldowski.me




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

Re: [swift-evolution] [Review] SE-0159: Fix Private Access Levels

[Zach Waldowski via swift-evolution]

> On Mar 23, 2017, at 2:22 AM, Matt Gallagher via swift-evolution 
>  wrote:
> I can't help but feel that this proposal is really misdirected frustration. 
> Programmers who don't use clusters of tiny types in a single file shouldn't 
> care about the existence of a scoped access modifier because it shouldn't 
> affect them – they should use file access modifiers and be done. Yet 
> apparently, it is file access modifier advocates pushing this proposal.

It is equally frustrating that those on the opposite side of this proposal keep 
indicating “just don’t pay attention to it” is an acceptable answer to the 
language growing an entire axis of confusion to its access control (i.e., a 
wart) so early in its life.

Sincerely,
Zachary Waldowski
Sent from my Mac

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

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0159: Fix Private Access Levels

[Zach Waldowski via swift-evolution]

On Tue, Mar 21, 2017, at 07:44 PM, Drew Crawford via swift-evolution wrote:
>> When new `private` and `fileprivate` were shipped, there were
>> numerous questions asked by users on forums such as Stack Overflow
> 

> And before they were shipped, there were people asking for a scoped
> modifier.  And when we change them again, what questions will that
> generate?  So I don’t see what we are accomplishing with this line of
> inquiry.
> 

>> You see the new access modifiers described, for example, as something
>> that "take[s] some getting used to." Rather damning as a euphemism,
>> don't you think?
> Not at all.  We could describe strong typing, or optionals, enums,
> pattern matching, etc., in this way.  ARC in particular is “difficult
> to teach” but we should not get rid of it, it solves a safety problem.
> A scoped access modifier is similar.


These two points are where I have to jump in. As someone who actually
teaches Swift, and not just lectures others about it on the mailing
lists, both of these arguments are terribly fallacious. Core Swift
features like optionals are fundamental to the idea of the language,
that have semantic meaning and impact on  compiled code.


People are thrilled to learn how to use enums because they make for a
better time writing code. These access modifier are can only charitably
be called code flavor. I have spent entire weeks of class trying to
extoll the benefits, so breathlessly shared on these mailing lists, of
how beautiful it is to have a scoped access level. I have yet to
succeed. They frustrate readers and they are a constant source of
roadblocks for the inexperienced.


Segregating private and fileprivate are, at best, a distraction, and at
worst are actively imposing on all of us the personal code style
preferences of those that were most active on the mailing lists while
Swift 2 was open.


It doesn't matter if desire for using extensions is the root of the
problem. Swift should only impose a preference when it's important to
the speed, functionality, and safety of the language. I have yet to be
convinced that there's a benefit to a scoped access level that fits
anywhere in there.


Best,

  Zach Waldowski

  z...@waldowski.me




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

Re: [swift-evolution] Smart KeyPaths

[Zach Waldowski via swift-evolution]

I might point out that this form of bikeshedding was already explicitly
called out in the text of the proposal. ("Alternatives Considered")
Your personal preferences as to what sigils are "lightweight" or "easy"
are not absolute ones without some form of evidence or objective
rationale provided.


Until that can be done, it would be more productive to discuss what we
can do to avoid ambiguity without magic sigils; or, in the face of Joe
Groff's post, why that ambiguity is a problem at all.


Best,

  Zachary Waldowski

  z...@waldowski.me





On Sun, Mar 19, 2017, at 01:00 AM, Muse M via swift-evolution wrote:

> I would suggest a keypath using ~ which is concise and clearer to
> identify.
> 

> let myPath = Person~friends[0].name

> 

> 

> 

> 

> 

> On Sunday, March 19, 2017, Jonathan Hull via swift-evolution  evolut...@swift.org> wrote:
>> This looks fantastic!

>> 

>> The one worry I would have, as others have brought up, is confusion
>> when there are static properties with the same name.  Maybe we could
>> have a special static property called ‘keyPath’ or ‘path’ that would
>> be reserved, and anything that followed would be a key path.
>> 

>> So instead of:

>> 

>> let myPath = Person.friends[0].name

>> 

>> you would have:

>> 

>> let myPath = Person.keyPath.friends[0].name

>> 

>> 

>> Or if we want to choose a sentinel, I would nominate ‘$’:

>> 

>> let myPath = $Person.friends[0].name

>> 

>> Thanks,

>> Jon

>> 

>> 

>>> On Mar 17, 2017, at 10:04 AM, Michael LeHew via swift-evolution >> evolut...@swift.org> wrote:
>>> 

>>> Hi friendly swift-evolution folks,

>>> 

>>> The Foundation and Swift team  would like for you to consider the
>>> following proposal:
>>> 

>>> Many thanks,

>>> -Michael

>>> 

>>> Smart KeyPaths: Better Key-Value Coding for Swift


>>>  * Proposal: SE-
>>>  * Authors: David Smith[1], Michael LeHew[2], Joe Groff[3]
>>>  * Review Manager: TBD
>>>  * Status: *Awaiting Review*
>>>  * Associated PRs:
>>>* #644[4]
>>> Introduction



>>> We propose a family of concrete *Key Path* types that represent
>>> uninvoked references to properties that can be composed to form
>>> paths through many values and directly get/set their underlying
>>> values.
>>> Motivation



>>> We Can Do Better than String



>>> On Darwin platforms Swift's existing #keyPath() syntax provides a
>>> convenient way to safely *refer* to properties. Unfortunately, once
>>> validated, the expression becomes a String which has a number of
>>> important limitations:


>>>  * Loss of type information (requiring awkward Any APIs)
>>>  * Unnecessarily slow to parse
>>>  * Only applicable to NSObjects
>>>  * Limited to Darwin platforms
>>> Use/Mention Distinctions



>>> While methods can be referred to without invoking them (let x =
>>> foo.bar instead of  let x = foo.bar()), this is not currently
>>> possible for properties and subscripts.
>>> Making indirect references to a properties' concrete types also lets
>>> us expose metadata about the property, and in the future additional
>>> behaviors.
>>> More Expressive KeyPaths



>>> We would also like to support being able to use *Key Paths* to
>>> access into collections, which is not currently possible.
>>> Proposed solution



>>> We propose introducing a new expression akin to Type.method, but for
>>> properties and subscripts. These property reference expressions
>>> produce KeyPath objects, rather than Strings. KeyPaths are a family
>>> of generic classes *(structs and protocols here would be ideal, but
>>> requires generalized existentials)* which encapsulate a property
>>> reference or chain of property references, including the type,
>>> mutability, property name(s), and ability to set/get values.
>>> Here's a sample of it in use:



>>> Swift struct Person {  var name: String  var friends: [Person]  var
>>> bestFriend: Person? }

>>> var han = Person(name: "Han Solo", friends: []) var luke =
>>> Person(name: "Luke Skywalker", friends: [han])

>>> let firstFriendsNameKeyPath = Person.friends[].name

>>> let firstFriend = luke[path] // han

>>> // or equivalently, with type inferred from context let
>>> firstFriendName = luke[.friends[].name]

>>> // rename Luke's first friend luke[firstFriendsNameKeyPath] = "A
>>> Disreputable Smuggler"

>>> let bestFriendsName = luke[.bestFriend]?.name  // nil, if he is the
>>> last jedi
>>> Detailed design



>>> Core KeyPath Types



>>> KeyPaths are a hierarchy of progressively more specific classes,
>>> based on whether we have prior knowledge of the path through the
>>> object graph we wish to traverse.
>>> Unknown Path / Unknown Root Type



>>> AnyKeyPath is fully type-erased, referring to 'any route' through an
>>> object/value graph for 'any root'. Because of type-erasure many
>>> operations can fail at runtime and are thus nillable.
>>> Swift class AnyKeyPath: CustomDebugStringConvertible, Hashable {  //
>>> MARK - Composition  // Returns nil if path.rootType !=
>>> self.valueType  func 

Re: [swift-evolution] [Proposal] Factory Initializers

[Zach Waldowski via swift-evolution]

Big +1.



Two small nits/questions:



- What's the motivation behind using `return` rather than self-
  assignment, like we currently have in inits for structs/enums and
  protocol extensions? I didn't follow the original discussion in depth,
  so excuse me if this has been hashed out before.
- Is the "factory" keyword truly necessary, or could it be implied by
  "required" and using self-assignment in the init body?


Best,

  Zachary Waldowski

  z...@waldowski.me





On Fri, Mar 17, 2017, at 12:26 PM, Riley Testut via swift-evolution wrote:
> 

> 

> Hi again everyone!

> 

> Now that Swift 4 Stage 2 proposals are being considered, I thought it
> might be time to revisit this proposal and see if it might align with
> the goals set forth for Swift 4.
> 

> As a quick tl;dr, this proposal describes a new "factory initializer"
> that would allow you to return a value from an initializer. This would
> have several benefits, as mentioned in the proposal itself as well as
> throughout this mailing list. For convenience, here's a link to the
> proposal on GitHub:
> https://github.com/rileytestut/swift-evolution/blob/master/proposals/-factory-initializers.md
> 

> Would love to hear any more comments on this proposal, and if we feel
> this is appropriate for considering for Swift 4 I'll happily re-open
> the pull request!
> 

> Riley Testut

> 

> On Nov 19, 2016, at 7:45 AM, arkadi daniyelian
>  wrote:
>> i would appreciate this feature.

>> 

>> For unexperienced developers, its often hard to recognize *when*
>> factory is a good fit to do the job, and how exactly approach the
>> implementation. I imagine having this feature built into the
>> language may help to choose and implement factory when its the right
>> thing to do.
>>
>>> On Nov 18, 2016, at 12:23 AM, Charles Srstka via swift-evolution >> evolut...@swift.org> wrote:
>>>
>>> Is there any chance of reviving this? It seems to me that since this
>>> would require Swift initializers to be implemented internally in
>>> such a way that they can return a value (as Objective-C init methods
>>> do), it may affect ABI stability and thus may be germane to the
>>> current stage of Swift 4 development.
>>>
>>> Charles
>>>
 On Dec 17, 2015, at 3:41 PM, Riley Testut via swift-evolution >>> evolut...@swift.org> wrote:

 Recently, I proposed the idea of adding the ability to implement
 the "class cluster" pattern from Cocoa (Touch) in Swift. However,
 as we discussed it and came up with different approaches, it
 evolved into a functionality that I believe is far more beneficial
 to Swift, and subsequently should be the focus of its own proposal.
 So here is the improved (pre-)proposal:

 # Factory Initializers

 The "factory" pattern is common in many languages, including Objective-
 C. Essentially, instead of initializing a type directly, a method
 is called that returns an instance of the appropriate type
 determined by the input parameters. Functionally this works well,
 but ultimately it forces the client of the API to remember to call
 the factory method instead, rather than the type's initializer.
 This might seem like a minor gripe, but given that we want Swift to
 be as approachable as possible to new developers, I think we can do
 better in this regard.

 Rather than have a separate factory method, I propose we build the
 factory pattern right into Swift, by way of specialized “factory
 initializers”. The exact syntax was proposed by Philippe Hausler
 from the previous thread, and I think it is an excellent solution:

 class AbstractBase { public factory init(type:
 InformationToSwitchOn) { return
 ConcreteImplementation(type) } }

 class ConcreteImplementation : AbstractBase {

 }

 Why exactly would this be useful in practice? In my own
 development, I’ve come across a few places where this would
 especially be relevant:

 ## Class Cluster/Abstract Classes
 This was the reasoning behind the original proposal, and I still
 think it would be a very valid use case. The public superclass
 would declare all the public methods, and could delegate off the
 specific implementations to the private subclasses. Alternatively,
 this method could be used as an easy way to handle backwards-
 compatibility: rather than litter the code with branches depending
 on the OS version, simply return the OS-appropriate subclass from
 the factory initializer. Very useful.

 ## Protocol Initializers
 Proposed by Brent Royal-Gordon, we could use factory initializers
 with protocol extensions to return the appropriate instance
 conforming to a protocol for the given needs. Similar to the class
 cluster/abstract class method, but can work with structs too. This
 would be closer to the factory method pattern, since you don’t need
 to know 

Re: [swift-evolution] [Proposal] Foundation Swift Encoders

[Zach Waldowski via swift-evolution]

> On Mar 16, 2017, at 4:18 PM, Itai Ferber  wrote:
> 
> Foundation’s common currency type for errors is unequivocally NSError, and 
> we’re not looking to change that as part of this proposal.
> 
Not in Swift, where it’s unequivocally Error, and errors thrown from Foundation 
bridge to CocoaError. Types that conform to Error can have custom bridges both 
to and from NSError. I didn’t suggest breaking up Foundation’s error types as 
part of this proposal, merely that while all this new code is being written, 
it’s a little backwards to tack on new home-brewed error codes to 
NSCocoaErrorDomain that don’t even exist in Objective-C.
> Reusing errors from the Cocoa domain has always been a reasonable choice for 
> 3rd-party developers, and we’d like to keep doing this.
> 
> We are looking to improve the experience of throwing such errors (with some 
> trivial extensions) by allowing you to do something like throw 
> CocoaError.error(.coderInvalidValue). (Of course, don’t quote me on the exact 
> syntax, as this is totally subject to change.)
> This is pretty simple, and nets you free user-facing localization.
> 
But, again, none of the three advantages mentioned here are exclusive to errors 
vended through NSError.

Zach Waldowski
z...@waldowski.me
> On 15 Mar 2017, at 22:46, Zach Waldowski wrote:
> 
> 
> Just a little one that came up with when thinking over the companion 
> proposal… see inline.
> 
>> On Mar 15, 2017, at 6:43 PM, Itai Ferber via swift-evolution 
>> > wrote:
>> Foundation-Provided Errors
>> 
>> Along with providing the above encoders and decoders, we would like to 
>> promote the use of a common set of error codes and messages across all new 
>> encoders and decoders. A common vocabulary of expected errors allows 
>> end-users to write code agnostic about the specific encoder/decoder 
>> implementation they are working with, whether first-party or third-party:
>> 
>> extension CocoaError.Code {
>> public static var coderInvalidValue: CocoaError.Code
>> public static var coderTypeMismatch: CocoaError.Code
>> public static var coderReadCorrupt: CocoaError.Code
>> public static var coderValueNotFound: CocoaError.Code
>> }
> 
> I find all the reasons compelling, but I don’t with the overall choice. A 
> common vocabulary, side table info, and localization can be achieved with a 
> dedicated error type for coders. I understand ABI (sorta) concerns are 
> involved here, that older Foundations will continue to return the same 
> NSError codes. However, it's never felt appropriate to create my own error 
> instances with NSCocoaErrorDomain, and this feels very similar to that. What 
> are our options here?
> 
> Zach Waldowski
> z...@waldowski.me 
> 

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

Re: [swift-evolution] [Proposal] Foundation Swift Archival & Serialization

[Zach Waldowski via swift-evolution]

On Thu, Mar 16, 2017, at 02:23 PM, Matthew Johnson via swift-evolution wrote:
> I don’t have an example but I don’t see a problem either.  There are
> two options for specifying the return type manually.  We can use the
> signature you used above and use `as` to specify the expected type:
> 

> let i = decode(.myKey) as Int



The awkwardness of this syntax is exactly what I'm referring to. Would a
beginner know to use "as Int" or ": Int"? Why would they? The
"prettiness" of the simple case doesn't make up for how difficult it is
to understand and fix its failure cases.


Any official Swift or Foundation API shouldn't, or shouldn't need to,
make use of "tricky" syntax.


> If we don’t support this in Foundation we will continue to see 3rd
> party libraries that do this.


The proposal's been out for less than 24 hours, is it really productive
to already be taking our ball and go home over such a minor thing?


Zach Waldowski

z...@waldowski.me








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

Re: [swift-evolution] [Proposal] Foundation Swift Archival & Serialization

[Zach Waldowski via swift-evolution]

> On Mar 16, 2017, at 3:09 AM, David Hart via swift-evolution 
>  wrote:
> 
> 2) Libraries like Marshal (https://github.com/utahiosmac/Marshal 
> ) and Unbox 
> (https://github.com/JohnSundell/Unbox ) 
> don’t require the decoding functions to provide the type: those functions are 
> generic on the return turn and it’s automatically inferred:
> 
> func decode(key: Key) -> T
> 
> self.stringProperty = decode(key: .stringProperty) // correct specialisation 
> of the generic function chosen by the compiler
> 
> Is there a reason the proposal did not choose this solution? Its quite sweet.

IMHO those are only “sweet” until you need to decode a value out to something 
other than a typed value, then it’s ambiguity city. There are many ways to 
solve that, but none of them are conducive to beginners. Using the metatype to 
seed the generic resolution is the only thing I’d get behind, personally.

Zach Waldowski
z...@waldowski.me

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

Re: [swift-evolution] [Proposal] Foundation Swift Archival & Serialization

[Zach Waldowski via swift-evolution]

Another issue of scale - I had to switch to a native mail client as replying 
inline severely broke my webmail client. ;-)

Again, lots of love here. Responses inline.

> On Mar 15, 2017, at 6:40 PM, Itai Ferber via swift-evolution 
>  wrote:
> Proposed solution
> We will be introducing the following new types:
> 
> protocol Codable: Adopted by types to opt into archival. Conformance may be 
> automatically derived in cases where all properties are also Codable.
FWIW I think this is acceptable compromise. If the happy path is derived 
conformances, only-decodable or only-encodable types feel like a lazy way out 
on the part of a user of the API, and builds a barrier to proper testing.
> [snip]
> 
> Structured types (i.e. types which encode as a collection of properties) 
> encode and decode their properties in a keyed manner. Keys may be 
> String-convertible or Int-convertible (or both), and user types which have 
> properties should declare semantic key enums which map keys to their 
> properties. Keys must conform to the CodingKey protocol:
> public protocol CodingKey { <##snip##> }

A few things here:

The protocol leaves open the possibility of having both a String or Int 
representation, or neither. What should a coder do in either case? Are the 
representations intended to be mutually exclusive, or not? The protocol design 
doesn’t seem particularly matching with the flavor of Swift; I’d expect 
something along the lines of a CodingKey enum and the protocol 
CodingKeyRepresentable. It’s also possible that the concerns of the two are 
orthogonal enough that they deserve separate container(keyedBy:) requirements.

Speaking of the mutually exclusive representations - what above serializations 
that doesn’t code as one of those two things? YAML can have anything be a 
“key”, and despite that being not particularly sane, it is a use case.
> For most types, String-convertible keys are a reasonable default; for 
> performance, however, Int-convertible keys are preferred, and Encoders may 
> choose to make use of Ints over Strings. Framework types should provide keys 
> which have both for flexibility and performance across different types of 
> Encoders. It is generally an error to provide a key which has neither a 
> stringValue nor an intValue.
> 

Could you speak a little more to using Int-convertible keys for performance? I 
get the feeling int-based keys parallel the legacy of NSCoder’s older design, 
and I don’t really see anyone these days supporting non-keyed archivers. They 
strike me as fragile. What other use cases are envisioned for ordered archiving 
than that?
> [snip]
> 
> Keyed Encoding Containers
> 
> Keyed encoding containers are the primary interface that most Codable types 
> interact with for encoding and decoding. Through these, Codable types have 
> strongly-keyed access to encoded data by using keys that are semantically 
> correct for the operations they want to express.
> 
> Since semantically incompatible keys will rarely (if ever) share the same key 
> type, it is impossible to mix up key types within the same container (as is 
> possible with Stringkeys), and since the type is known statically, keys get 
> autocompletion by the compiler.
> 
> open class KeyedEncodingContainer {

Like others, I’m a little bummed about this part of the design. Your reasoning 
up-thread is sound, but I chafe a bit on having to reabstract and a little more 
on having to be a reference type. Particularly knowing that it’s got a bit more 
overhead involved… I /like/ that NSKeyedArchiver can simply push some state and 
pass itself as the next encoding container down the stack.

> open func encode(_ value: Value?, forKey key: Key) throws

Does this win anything over taking a Codable?

> open func encode(_ value: Bool?,   forKey key: Key) throws
> open func encode(_ value: Int?,forKey key: Key) throws
> open func encode(_ value: Int8?,   forKey key: Key) throws
> open func encode(_ value: Int16?,  forKey key: Key) throws
> open func encode(_ value: Int32?,  forKey key: Key) throws
> open func encode(_ value: Int64?,  forKey key: Key) throws
> open func encode(_ value: UInt?,   forKey key: Key) throws
> open func encode(_ value: UInt8?,  forKey key: Key) throws
> open func encode(_ value: UInt16?, forKey key: Key) throws
> open func encode(_ value: UInt32?, forKey key: Key) throws
> open func encode(_ value: UInt64?, forKey key: Key) throws
> open func encode(_ value: Float?,  forKey key: Key) throws
> open func encode(_ value: Double?, forKey key: Key) throws
> open func encode(_ value: String?, forKey key: Key) throws
> open func encode(_ value: Data?,   forKey key: Key) throws

What is the motivation behind abandoning the idea of “primitives” from the 
Alternatives Considered? Performance? Being unable to close the protocol?

What ways is encoding a value envisioned to fail? I understand wanting to allow 

Re: [swift-evolution] [Proposal] Foundation Swift Archival & Serialization

[Zach Waldowski via swift-evolution]

Holy cow. There's much to digest here (so much so that my initial
response, which quoted its content, was denied by the mailing list).
After an initial reading, I don't just want this now, I want it
yesterday. I'm already imaging the encoder/decoders I want to build.
Very exciting.


Best,

  Zachary Waldowski

  z...@waldowski.me


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

Re: [swift-evolution] Very limited scope for access control/(sub)modules in Swift 4

[Zach Waldowski via swift-evolution]

I'm sort of glad to see this; was worrying that access control was
getting buried in the shuffle.

Is there anything that the community can do to help address submodules
as more of a tooling problem than a language one in the Swift 4
timeframe? Is there any low-hanging fruit to work on or proposals to
review for SwiftPM, for instance? Radars we can dupe for DevTools? That
kind of thing?

All the best —
  Zachary Waldowski
  z...@waldowski.me

On Mon, Mar 6, 2017, at 12:31 PM, Douglas Gregor via swift-evolution
wrote:
> Hi all,
> 
> Like everyone else in the Swiftverse, the core team recently spent some
> time discussing access control in Swift. While we love to see the
> enthusiasm on this topic, wholesale changes to the access control
> model—such as the introduction of submodules or a complete shift to a
> more type-centric access control model—are out of scope for Swift 4.
> 
> The core team does feel that a small part of this discussion—the reversal
> of SE-0025’s separation of “private” and “fileprivate”---is in scope for
> Swift 4, for which there is a proposal draft here:
> 
>   https://github.com/apple/swift-evolution/pull/627
> 
>   - Doug
> 
> ___
> 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

[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] [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] Atomics

[Zach Waldowski via swift-evolution]

Huge +1, and for the prototype as well. Atomic.Bool and
Atomic.RawPointer would also be truly appreciated. An Atomic a la C++
would be even better but I don't know if we'd want to tie ourselves to
that.

I like the LLVM names for MemoryOrder et. al. better than the C std.
ones, in general, and have never liked acqrel.

Cheers! Awesome! Amazing! <3 <3 <3
  Zachary Waldowski
  z...@waldowski.me

On Thu, Feb 23, 2017, at 04:44 PM, Guillaume Lessard via swift-evolution
wrote:
> There is no clean way to use atomic operations in Swift at the moment,
> even less so after most of OSAtomic.h was deprecated in Sierra. Of
> course, the OSAtomic calls were never available in Linux, so there are no
> atomics at all on that side. It's technically possible to wrap clang’s
> C11 atomics for use in Swift; such a wrapper can be made cross-platform,
> but still isn't a particularly great solution.
> 
> It looks to me as if this would pretty much be a library addition, since
> atomics support seems to be fairly complete in the Builtin module. Would
> a proposal be welcome?
> 
> I sketched an atomic Int64 in the following branch:
> https://github.com/glessard/swift/tree/atomics-sketch
> 
> Cheers,
> Guillaume Lessard
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Proposal][Discussion] Modular Swift

[Zach Waldowski via swift-evolution]

I agree with Nevin’s points in large strokes, but I don’t think large files are 
the end of the world. I think an important takeaway idea from all the access 
control threads is that we need not provide facilities in the language to 
support antipatterns; we should more focus on how to encourage good patterns 
better.

On the face of it, I’m excited by the proposal; even if this isn’t the answer, 
we should seek to go down any road that removes fileprivate (and I mean remove 
- not just a new spelling) but preserves aspect the feature to please whatever 
it is that people like about that feature.

> On Feb 21, 2017, at 7:36 PM, Nevin Brackett-Rozinsky via swift-evolution 
>  wrote:
> 
> This proposal is definitely *not* what I want from a submodule system, 
> because it will exacerbate the problem of developers stuffing large amounts 
> of code into a single file.
> 
> The “fileprivate” keyword already encourages long files, because there is no 
> way to split up related components into separate files while retaining 
> encapsulation. And scope-based “private” is even worse of an offender, 
> because it requires nesting code inside the same *type declaration*, so you 
> can’t even benefit from extensions.
> 
> To my mind, any submodule system for Swift should be designed to relieve the 
> pressure for long files, and make it easy to group tightly related files into 
> a single unit with shared visibility. That way developers can easily organize 
> their code into smaller files while utilizing Swift’s pattern of providing 
> protocol conformances in extensions and keeping implementation details hidden 
> from the rest of the module at large.
> 
> For example, one possible design would enable us to replace both “private” 
> and “fileprivate” with a single new access level—probably spelled “private— 
> which restricts visibility to just the current submodule. That way it 
> provides all the benefits of “fileprivate” (implementation hiding and the 
> ability to use extensions) while also allowing code to be placed in separate 
> files rather than one large file.
> 
> 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

Re: [swift-evolution] [Draft] Fix Private Access Levels

[Zach Waldowski via swift-evolution]

> On Feb 21, 2017, at 11:47 AM, Ilya Belenkiy via swift-evolution 
>  wrote:
> 
> I joined the list primarily because I really wanted that change. After it was 
> accepted, I stopped following, partially because I cannot keep up with all 
> the emails. I saw this thread completely by accident when I was going to 
> unsubscribe! I hope to be back when the discussion moves to Discourse, but if 
> accepted proposals are not treated as final decisions (unless something 
> significant comes up), I don't know if I will. I am sure that my absence will 
> not be noticed, but there could be many people like me. People on this list 
> represent a very small percentage of the actual group who use the language, 
> but from what I read here, there seems to be an assumption that people on the 
> list is an accurate representation of the entire group of programmers using 
> Swift. It's not, and there could be a large number of people who silently 
> disagree with any particular proposal, and the actual usage statistics could 
> be different from what people here may think. Also, some people may not know 
> about particular features, and it may be a matter of education rather than a 
> feature not carrying its own weight. If you looked at GitHub, you could say 
> that nobody is using feature X, so it's not useful or needed, but it could 
> also be that if X were publicized better, GitHub would show much more 
> adoption. I really hope that features get decided on the merit of their 
> usefulness and not by vote of people on this list.

Swift shouldn’t be unnecessarily burdened by the opinions of people who feel 
the need to spend all their time on a mailing list. A language’s features 
should be useful in their own right. If “nobody" knows how to use a feature 
appropriately, then random code from GitHub _is_ data that it might not 
necessarily be well thought out. Proposals can’t be written in stone because we 
can’t see the future. I’m sorry you no longer want to participate, but the 
world will keep on turning.

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

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

[Zach Waldowski via swift-evolution]

On Mon, Feb 20, 2017, at 02:29 AM, Goffredo Marocchi via swift-evolution
wrote:
> Maybe the burden of proof required for this change is not met even though
> it frustrates those who dislike fileprivate.

It's more frustrating that it's seemingly now imperative to get the
burden of proof to remove it is now a, when the burden of proof was
ignored in the rush to add it to the language.

As you insist we spend our energies elsewhere, I meet more and more
people who are turned off by Swift because of arcana like fileprivate.
The language is 3 years old; it shouldn't have baggage like this.
"Similar but subtly different to another keyword by the addition of a
few letters of easily-confused spelling" is C++ to the tee.

No, I'll concede in the end it's just a papercut, albeit in the sea of
other paper cuts including compile times, generics limitations,
overcomplicating bridging, etc, etc. However, this is a battle for the
soul of the language as much as anything else is on Evolution. The
opinions of those who want to add an ill-considered keyword to solve
every problem are overrepresented; those for whom that pattern fatally
complicates the language are underrepresented, because they've already
stopped using Swift.

Sincerely,
  Zachary Waldowski
  z...@waldowski.me
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Draft] open and public protocols

[Zach Waldowski via swift-evolution]

On Sun, Feb 19, 2017, at 10:57 PM, Xiaodi Wu via swift-evolution wrote:
> Left unsaid from my reply about enums is that implicit conversions
> should absolutely be added. We already have this magic for one
> particular enum, Optional.


I can only see a generalization of this being used for evil.
Perhaps that's best left to be discussed on some other knock-down,
drag-out thread.


> I'm not arguing with you that enums are currently unsuitable. In fact
> I entirely agree. But Chris Lattner and others have said (now I'm
> paraphrasing, but I believe accurately) that they *should* be. What
> will it take? At minimum, some way to opt into implicit conversions.
> It's a no-brainer in my mind.
> 

> Bottom line: the language needs one excellent way to model Foo | Bar |
> Baz, not two or three mediocre workarounds. The core team has said
> that they want that excellence to be built through enums. Let's do it.


I don't understand how extending protocols to parallel the changes we
already made to classes — and in line with what's planned for enums — is
a mediocre workaround.


I have low confidence in Evolution being able to produce a passable
union type design in a meaningful amount of time, particularly for Swift
4 Phase 2; I also question their need in the first place.


Sincerely,

  Zachary Waldowski

  z...@waldowski.me


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

Re: [swift-evolution] [Draft] open and public protocols

[Zach Waldowski via swift-evolution]

On Sun, Feb 19, 2017, at 06:40 PM, Xiaodi Wu via swift-evolution wrote:
> On Sun, Feb 19, 2017 at 5:15 PM, Brent Royal-Gordon via swift-
> evolution  wrote:
>> What is the harm of permitting an outside conformance to
>> `SQLiteValue`?


I'll put words in Brent's mouth here as an attempt at an answer: you
sometimes need to exclusively switch a downcast of an existential.
Consider a serialization type - or SQLiteValue - where need to treat
specific fundamental types ("primitives") in implementation-dependent
ways. In a theoretical serialization design, all non-primitives would
have an explicit protocol of semantics to conform to support
serialization, much like the stdlib's "Custom" protocol pattern, and you
compose from there.


Using an enum to represent this exclusivity remains unconvincing to me,
unless we choose to add implicit conversions to the language. `.int(42)`
is an overwhelming level of duplicate type information in any practical,
non-trivial use case. Yes, (closed) enums model exclusivity. They are
not the only things to do so.


The stdlib alone is reason enough for this feature to exist, even if not
exposed publicly.


Zachary


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

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

[Zach Waldowski via swift-evolution]

On Fri, Feb 17, 2017, at 07:52 PM, Jose Cheyo Jimenez via swift-evolution wrote:
> I don’t think there is evidence that scope private in Swift3 is
> "actively harmful”.


This thread would quite simply not exist if not to present exactly that
evidence. It exists; we, the change's detractors, exist.


Zachary


___
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

[Zach Waldowski via swift-evolution]

On Fri, Feb 17, 2017, at 08:45 PM, Joe Groff via swift-evolution wrote:
> • What is your evaluation of the proposal?



Extremely strong +1.



Unlike others, I agree with the proposed deprecation of
BitwiseOperations. It's not pulling its own weight under this new model.
I encourage other reviewers to try, as the proposal suggests, to come up
with a compelling user of just BitwiseOperations.


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


Yes; it's not as easy to work with integers in Swift 3 as floating
point, which is annoying, since integers are important to binary
programming.


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



The graph of methods and protocols is well-considered, and while it's
probably not mathematically perfect, I could easily see the API being
used to teach binary arithmetic.


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


I've tried (and failed) to use Swift's previous protocols for generic
programming.


> • How much effort did you put into your review? A glance, a quick
> reading, or an in-depth study?


Thorough reading of previous revisions, glance through of this one.
Thanks for providing the updates section!


Sincerely,

  Zachary Waldowski

  z...@waldowski.me




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

Re: [swift-evolution] Pitch: Replacement for FileHandle

[Zach Waldowski via swift-evolution]

I can scarcely think of a less productive or more disrespectful thing to
do in a thread chock full of Apple engineers actively trying to help you
out. They're just humans, led by other humans. They can't divine the
presence of issues, just like they can't divine the priorities of
individual tasks without a holistic view of them. It would be far more
productive to figure out how we can get the changes we want done in a
public release of software as soon as possible. Everything else is
extraneous.


Best,

Zachary



On Thu, Feb 16, 2017, at 08:08 AM, Nick Keets via swift-evolution wrote:
> I’m going OT here, but even though I understand your reasons, you need
> to acknowledge that for developers the rational thing to do is to not
> file radars at all.
> 

> Any bug fix will get released at best a few months later and you can
> only actually take advantage of it a few years later (if you care
> about supporting older versions). More realistically we are talking
> 3-4 years of having to work around it (in the best cases). This is a
> lot of work (with almost zero feedback) for some far future benefit
> that probably will not even be relevant to you then.
> 

> So to me, when an Apple developer asks me to file a radar, it feels
> like they are asking me to do their job.
> 

> I’m sorry for the off-topic rant.

> 

> On Thu, Feb 16, 2017 at 1:45 AM, Tony Parker via swift-evolution  evolut...@swift.org> wrote:
>> 

>>> On Feb 15, 2017, at 2:25 PM, Charles Srstka
>>>  wrote:
>>> 

 On Feb 15, 2017, at 3:11 PM, Itai Ferber  wrote:
 

 FYI, Tony is the manager of the Foundation team. :) We care very
 much about making sure that the experience of using our framework
 is a positive one — the more Radars we get, the better we can
 prioritize improving APIs that are not working as well as they
 could be for our users. Even if the Radar gets duped to an existing
 one, thats one more +1 for that Radar saying "this is a problem".
>>> Yeah I know, but it’s a frustrating experience, spending a half hour
>>> writing a detailed bug report (sometimes with videos attached to
>>> demonstrate the issue), just to effectively do the same thing as
>>> spending 5 seconds to hit the +1 button on most issue trackers you
>>> come across.
>>> 

>>> Especially since you never find out what happened to the original
>>> bug report. You can see if it’s open or closed, but did they fix it
>>> in some internal build? Did they decide it “behaves correctly?” Did
>>> somebody just skim your report, and mistakenly attach it to some
>>> other, unrelated issue? There’s no way to know.
 I will search for your old Radar, but in any case, please do file a
 new one about this, and about any other issues you have, because we
 are indeed listening.
>>> I was pretty sure I'd submitted something way, way back in the misty
>>> days of yore, but I can’t find it. I’ve filed a couple of new ones:
>>> rdar://30543037 and rdar://30543133.
>>> 

>>> Charles

>>> 

>> 

>> Thanks for filing these.

>> 

>> Sometimes, for process reasons, we do indeed mark bugs as dupes of
>> other ones. Usually the polite thing to do is to dupe to the earliest
>> filed one. Sometimes this comes across with an appearance of not
>> caring to the filer of the new bug, but our intent is simply to
>> consolidate the reports we have so that we know that the issue is
>> serious.
>> 

>> We do not make API changes without going through a vigorous review
>> process, to avoid churn for the many clients above us. The flip side
>> is that this can take some time. I’m sure you understand that all
>> software engineering is about tradeoffs.
>> 

>> All of that said, we’ll take a look at these and see what
>> improvements we can make here. As I said, I’m not a fan of exception-
>> based API.
>> 

>> - Tony

>> 

>> 

>> 

>> ___

>>  swift-evolution mailing list

>> swift-evolution@swift.org

>> https://lists.swift.org/mailman/listinfo/swift-evolution

>> 

> _

> swift-evolution mailing list

> swift-evolution@swift.org

> https://lists.swift.org/mailman/listinfo/swift-evolution


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

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

[Zach Waldowski via swift-evolution]

I still haven't been convinced by this. What are these incredibly large
files that people are dealing with, and why should a crucial feature of
the language be built around servicing anti patterns?


Zachary



On Mon, Feb 13, 2017, at 01:26 PM, William Sumner via swift-evolution wrote:
> 

>> On Feb 12, 2017, at 9:19 AM, David Hart via swift-evolution > evolut...@swift.org> wrote:
>> 

>> 

>> *Fileprivate* 

>> 

>> I started the discussion early during the Swift 4 timeframe that I
>> regret the change in Swift 3 which introduced a scoped private
>> keyword. For me, it's not worth the increase in complexity in access
>> modifiers. I was very happy with the file-scope of Swift pre-3. When
>> discussing that, Chris Latner mentioned we'd have to wait for Phase 2
>> to re-discuss it and also show proof that people mostly used
>> 'fileprivate' and not the new 'private' modifier as proof if we want
>> the proposal to have any weight. Does anybody have a good idea for
>> compiling stats from GitHub on this subject? First of all, I've
>> always found the GitHub Search quite bad and don't know how much it
>> can be trusted. Secondly, because 'private' in Swift 2 and 3 have
>> different meanings, a simple textual search might get us wrong
>> results if we don't find a way to filter on Swift 3 code.
> 

> I find the “Motivation” section of SE-0025 convincing.
> Private/fileprivate allows for distinguishing between shared and
> hidden details among related code in a file. Not only is there benefit
> in knowing intent when reading, but there is also benefit in writing
> because the IDE won’t autocomplete hidden details. I work on large
> files I’m not the sole author of, so this is important to me.
> 

> Preston

> _

> swift-evolution mailing list

> swift-evolution@swift.org

> https://lists.swift.org/mailman/listinfo/swift-evolution


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

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

[Zach Waldowski via swift-evolution]

I  vehemently agree on these points. New-private and fileprivate "[add]
more information" to a file  the same way requiring `self.` and other
sorts of visual noise that Swift normally eschews.


I wish for the Swift community to be  introspective enough to count both
its successes and failures. SE-0025 was a botched addition to the
language. That the migrator did such a bad job is evidence of its poor
overall consideration. Adding a fix-it strikes me as the compiler
waggling its finger at me for code that would've been perfectly fine in
the past, something that it is not at all true with the "let" fix it;
accidental mutation has been discussed a ton by the larger programming
community, not-so-much for obscure access control mechanics.


It's perplexing that fileprivate advocates continue to stand on mostly
theoretical benefits about new-private. I feel nothing for the
mathematical purity about the types in a file. In practice, I can with
much experience now how awful it is. There has been no end to the
confusion its introduction has inflicted upon my team(s),  people new to
the language, and people revisiting the language:


- My teams and coworkers are less effective at code review from constant
  litigation about access control. "'Did this need to change?' / 'No, it
  was just the migrator.'" has become a disturbingly common refrain.


- New users are just struggling to figure out where to put the curly
  braces in the first place. Having to make them check and re-check
  where things go in a file, or just tell them to use this clunky 
get-out-of-jail-
  free keyword, feels like visiting a special kind of Pythonic hell on a
  language I otherwise love and love to teach.


- People returning to the language feel (and often say - just look at
  Twitter) Swift has a lot of syntax, and are frustrated that the
  addition of a new keyword  was burned on adding something that amounts
  to mostly a stylistic opinion.


All the best,

  Zachary Waldowski

  z...@waldowski.me



On Sun, Feb 12, 2017, at 04:45 PM, Xiaodi Wu via swift-evolution wrote:
> On Sun, Feb 12, 2017 at 3:24 PM, Matthew Johnson
>  wrote:
>> 

>> 

>>> On Feb 12, 2017, at 2:35 PM, Xiaodi Wu via swift-evolution >> evolut...@swift.org> wrote:
>>> 

>>> _Potentially_ meaningful, certainly. But what I'm hearing is that it
>>> isn't actually meaningful. Here's why:
>>> 

>>> If I see `fileprivate` and can understand that to mean "gee, the
>>> author _designed_ this member to be visible elsewhere inside the
>>> file," then it's actually meaningful. OTOH, if I see `fileprivate`
>>> and can only deduce "gee, the author mashed some button in his or
>>> her IDE," then it's not really telling me anything.
>> 

>> 

>> You’re looking at it backward.  It’s when you see `private` and can
>> deduce “this member is only visible inside it’s declaring scope” that
>> can be really helpful.  *This* is what matters.
> 

> In what ways can that information help you?

> 

>> 

>>> What you've said above, as I understand it, is that it's not
>>> currently meaningful to see `fileprivate` because the migrator is
>>> writing it and not the author. The improved approach you proposed is
>>> the additional warning. In that case, the compiler will help to
>>> ensure that when I see `fileprivate`, at least I know it's
>>> necessary. But that's only telling me a fact (this member is
>>> accessed at least once outside the private scope), but it's still
>>> machine-based bookkeeping, not authorial intent.
>> 

>> 

>> The important thing is that this machine-based bookkeeping results in
>> a proof about the code.  This facilitates reasoning about the code.
>> You can make an argument that this proof is not important enough to
>> matter, but you must admit that this is a real concrete gain in
>> information that is immediately available to a reader of the code
>> (after they know that it compiles).  Personally, I find this proof to
>> be valuable.
> 

> Comparison has been made to `let` and `var`. In that case, whether a
> variable is mutated can be non-trivial to deduce (as Swift has no
> uniform scheme for distinguishing mutating from non-mutating
> functions; the ed/ing rule has many exceptions). By contrast, here, I
> don't see any gain in information. You can literally *see* where the
> (file)private member is accessed, and when a file gets too long, even
> a simple text editor can do a decent enough find.
> 

> If you're right that the real value is that seeing `private` helps you
> reason about the code, then that value must be commensurate to how
> often we see Swift users amending the migrator to take advantage of
> it. For me, the compelling evidence that Swift users don't find this
> proof to be valuable is that, by examination of Swift 3 code, Swift
> users haven't bothered. If we add a new fix-it to force them to, then
> of course they'll mash the buttons, but it's pretty much declaring
> that they are wrong not to care about what it seems 

Re: [swift-evolution] Shouldn't ".withUnsafeBufferPointer" and ".withUnsafeMutableBufferPointer" be parts of protocols?

[Zach Waldowski via swift-evolution]

I like the sound of it so far, but my first major thought is that isn't
it modeling a "has-a" relationship instead of an "is-a"? The buffer
methods indicate that the data type *can* be represented as a buffer for
the duration of the method call, but may not necessarily be before or
after. Such a semantic distinction would also allow Data and
DispatchData, as well as other theoretical data structures like a Deque
(I think?) to participate.


Cheers!

  Zachary Waldowski

  z...@waldowski.me





On Fri, Jan 27, 2017, at 06:40 PM, Daryle Walker via swift-evolution wrote:
> I was perusing the library for array ideas, and noticed that several
> types had methods in common, but without a grouping protocol.
> Shouldn’t that be fixed?
> 

> (Oh, if multiple protocols have an associated-type with the same name,
> is that a problem? Is it a problem if they resolve differently for
> each protocol attached to a given type? I’m asking because these
> protocols reuse Sequence’s Element for their own purpose.)
> 

> 

> Formal Protocol for Contiguous Storage Visitation


>  * Proposal: SE-
>  * Authors: Daryle Walker[1]
>  * Review Manager: TBD
>  * Status: *Awaiting review*
> *During the review process, add the following fields as needed:*


>  * Decision Notes: Rationale[2], Additional Commentary[3]
>  * Bugs: SR-[4], SR-[5]
>  * Previous Revision: 1[6]
>  * Previous Proposal: SE-
> Introduction



> The standard library types Array, ArraySlice, and ContiguousArray have
> an interface for visiting their elements as a contiguous block of
> memory (arranging said elements to that configuration first if
> necessary). These methods are all the same, but not under a common
> protocol (i.e. seeming to match by "coincidence").
> This proposal seeks to correct that with two new protocols that these
> types will implement.
> Swift-evolution thread: Discussion thread topic for that proposal[7]
> Motivation



> Just adding these protocols for consistency is relatively minor, but
> they may be used for other types. Particularly, they would be needed
> if fixed-sized arrays are added to the language.
> Proposed solution



> The library array types will follow the
> MutableContiguousBlockprotocol, which inherits from the
> ContiguousBlock protocol.
> extension Array: MutableContiguousBlock { }  extension ArraySlice:
> MutableContiguousBlock { }  extension ContiguousArray:
> MutableContiguousBlock { }
> For example, a repackaging of the library's example code:



> func change(object: inout T) -> T.Element
> where T.Element: Integer { let sum = object.withUnsafeBufferPointer {
> (buffer) -> T.Element in var result: T.Element = 0 for i in
> stride(from: buffer.startIndex, to: buffer.endIndex, by: 2) { result
> += buffer[i] } return result } object.withUnsafeMutableBufferPointer {
> buffer in for j in stride(from: buffer.startIndex, to: buffer.endIndex
> - 1, by: 2) { swap([j], [j + 1]) } } return sum }  var
> numbers = [1, 2, 3, 4, 5] print(change(object: ))  // 9
> print(numbers)   // [2, 1, 4, 3, 5]
> Detailed design



> /** Visitation protocol of the receiver's contiguous storage of
> immutable elements. */ protocol ContiguousBlock {  /// Inferred alias
> to the element type to visit associatedtype Element  /** Calls a
> closure with a pointer to the receiver's contiguous storage. If no
> such storage exists, it is first created.  Often, the optimizer can
> eliminate bounds checks within an array algorithm, but when that
> fails, invoking the same algorithm on the buffer pointer passed into
> your closure lets you trade safety for speed.  The following example
> shows how you can iterate over the contents of the buffer pointer:
> let numbers = [1, 2, 3, 4, 5] let sum =
> numbers.withUnsafeBufferPointer { buffer -> Int in var result = 0 for
> i in stride(from: buffer.startIndex, to: buffer.endIndex, by: 2) {
> result += buffer[i] } return result } // 'sum' == 9  - Parameter body:
> A closure with an `UnsafeBufferPointer` parameter that points to the
> contiguous storage for the receiver. If `body` has a return value, it
> is used as the return value for this method. The pointer argument is
> valid only for the duration of the closure's execution.  - Returns:
> The return value of the `body` closure parameter, if any.  - SeeAlso:
> Swift.UnsafeBufferPointer */ func withUnsafeBufferPointer(_ body:
> (UnsafeBufferPointer) throws -> R) rethrows -> R  }  /**
> Visitation protocol of the receiver's contiguous storage of elements,
> allowing mutation. */ protocol MutableContiguousBlock: ContiguousBlock
> {  /** Calls the given closure with a pointer to the receiver's
> mutable contiguous storage. If no such storage exists, it is first
> created.  Often, the optimizer can eliminate bounds checks within an
> array algorithm, but when that fails, invoking the same algorithm on
> the buffer pointer passed into your closure lets you trade safety for
> speed.  The following example shows modifying the 

Re: [swift-evolution] Strings in Swift 4

[Zach Waldowski via swift-evolution]

On Wed, Jan 25, 2017, at 04:54 PM, Ben Cohen wrote:
> I’m normally all in favor of the “don’t give people features, or they'll
> use them too much” argument but in this case I don’t think it applies.

That's not what I'm calling for at all. In fact, ContiguousArray and co.
are a great example of the problem I'm having here. After reading,
learning, profiling, and tuning, more than once on my teams has a
correct use of ContiguousArray been shot down by "why isn't this just
Array?" during code review. I've more than once had to babysit an angry
coworker or walk a confused student through why they have a variable of
type ArraySlice and not Array.

I cannot emphasize more thoroughly that I want all this power (and
more!) to exist in the stdlib, but, and don't take this the wrong way,
the concern that I'm voicing is the team must balance the desire for a
perfect, beautiful, complete String model and how, in practice, it's
actually gets used — a set of possibilities which includes "not at all"
and many varieties of "incorrectly".

Best,
  Zachary Waldowski
  z...@waldowski.me
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Strings in Swift 4

[Zach Waldowski via swift-evolution]

The ultimate model of strings is going to be complicated whether or not it’s on 
String itself, although I argue that regardless of that complexity, Swift 
inherently starts from a much better place than f.ex. Java from just having 
Array vs. 30 different Array-like things. That dovetails into the point I was 
trying to make up-thread, which is that complicating the overall type space to 
serve specific use cases practically results in less-experienced users not 
knowing about or not finding it, even when they need to. Furthermore, “use 
UTF8String when you need to to be super-fast (and don’t we all want to be super 
fast???)” is the kind of cargo-culting that sticks, not “when caveats A, B, C, 
and D apply and you want to be fast and you’ve considered all the Unicode 
implications and when the optimizer breaks down and you have observed a 
performance problem you should consider etc etc etc”.

> On Jan 25, 2017, at 4:21 PM, Ben Cohen <ben_co...@apple.com> wrote:
> 
> 
>> On Jan 24, 2017, at 8:16 PM, Zach Waldowski via swift-evolution 
>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>> 
>> I strongly want Swift to have world-class string processing, but I believe 
>> even more strongly in the language's spirit of progressive disclosure. 
>> Newcomers to Swift's current String API find it difficult (something I 
>> personally disagree with, but that's neither here nor there); I don't think 
>> that difficulty is solved by aggressively use-specific type modeling. I 
>> instead think it gives rise to the same severe cargo-culting that gets us 
>> the scarily prevalent String.Index.init(offset:) extensions in the current 
>> model.
> 
> This cuts both ways though. In the spirit of progressive disclosure, should 
> we complicate String’s model for users in order for it to accommodate both 
> UTF8 and UTF16 backing stores?
> 
> If String can be UTF8-backed, that would mean that we could not tag the UTF16 
> collection view as conforming to RandomAccessCollection. That would mean you 
> couldn’t use algorithms that relied on random access on it. It would exhibit 
> random access characteristics sometimes  – UTF16View.index(:offsetBy) would 
> run in constant time when the string was backed by UTF16, but when backed by 
> UTF8, it would run in linear time. Given, as we’ve discussed here, you need 
> to do these kind of index calculations sometimes to interoperate with APIs 
> that traffic in code unit offsets, what do we need to tell users about 
> performance when they need to do it? That "it’s probably OK unless caveat 
> caveat caveat"?
> 
> On the other hand, if we separate UTF8-backed strings into another type, we 
> can keep String simple. Then for those power users who really absolutely must 
> operate on a UTF8-backed string because of their performance needs, they have 
> another type, which they can progressively discover when they find they need 
> it.
> 
> I’m not saying this is enough to rule out UTF8-backed strings, but I don’t 
> think “it’ll be a simpler model for most users” is the argument in favor of 
> it.
> 
> 

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

Re: [swift-evolution] Strings in Swift 4

[Zach Waldowski via swift-evolution]

I'll use Karl's point here as a minor jumping-off point for a semi-
related train of thought… I'm excited by the content of the original
manifesto, including a powerful Unicode  namespace and types. But as
I've continued down the thread, I've had growing concern about  modeling
strings breadthwise in the type system i.e., with UTF8String and so on.


I strongly want Swift to have world-class string processing, but I
believe even more strongly in the language's spirit of progressive
disclosure. Newcomers to Swift's current String API find it difficult
(something I personally disagree with, but that's neither here nor
there); I don't think that difficulty is solved by aggressively use-
specific type modeling. I instead think it gives rise to the same severe
cargo-culting that gets us the scarily prevalent
String.Index.init(offset:) extensions in the current model.


Best

  Zach Waldowski

  z...@waldowski.me



On Tue, Jan 24, 2017, at 10:15 PM, Karl Wagner via swift-evolution wrote:
> 

>> 

>>> I hope I am correct about the no-copy thing, and I would also
>>> like to
>>> permit promoting C strings to Swift strings without
>>> validation.  This
>>> is obviously unsafe in general, but I know my strings... and I care
>>> about performance. ;)

>> 

>> We intend to support that use-case.  That's part of the reason
>> for the
>> ValidUTF8 and ValidUTF16 encodings you see here:

>> https://github.com/apple/swift/blob/unicode-rethink/stdlib/public/core/Unicode2.swift#L598
>> and here:

>> https://github.com/apple/swift/blob/unicode-rethink/stdlib/public/core/Unicode2.swift#L862
> 

> It seems a little strange to me that a pre-validated UTF8 string from
> C would have different types to a UTF8String (i.e. using ValidUTF8 vs
> UTF8). It defeats the point of having the encoding represented in the
> type-system.
> 

> For example, if I write a generic function:

> 

>> func sendMessage(from:
>> Source)
> 

> I would only be able to accept UTF-8 text which hasn’t already been
> validated.
> 

> What about if we allowed each encoding to provide multiple kinds of
> decoder? That would also allow us to substitute our own decoders in,
> if there are application-specific shortcuts we can take.
> 

>> protocol UnicodeEncoding {

>>   associatedtype CodeUnit

>> 

>>   associatedtype ValidatingDecoder: UnicodeDecoder

>>   associatedtype NonValidatingDecoder: UnicodeDecoder
>> }

>> 

>> protocol UnicodeDecoder {

>> associatedtype Encoding: UnicodeEncoding

>> associatedtype DecodedScalar: RandomAccessCollection where
>> Iterator.Element == Encoding.CodeUnit
>> 

>> static func parse1Forward(…) -> ParseResult> C.Index>
>> static func parse1Backward(…) -> ParseResult> C.Index>
>> }

>> // Not shown: UnicodeEncoder protocol, with transcodeScalar
>> function.
>> 

>> struct UTF8: UnicodeEncoding  { 

>> typealias CodeUnit = UInt8  

>> typealias ValidatingDecoder= ValidatingUTF8Decoder

>> typealias NonValidatingDecoder = NonValidatingUTF8Decoder

>> }

>> 

>> struct NonValidatingUTF8Decoder: UnicodeDecoder {

>> typealias Encoding = UTF8

>> struct DecodedScalar: RandomAccessCollection { … }

>> // Parsing functions

>> }

>> 

>> struct ValidatingUTF8Decoder: UnicodeDecoder {

>> typealias Encoding = UTF8

>> typealias DecodedScalar = NonValidatingUTF8Decoder.DecodedScalar
>> // newtype would be cool here
>> // Parsing functions

>> }

>> 

>> struct String {

>> init(from: C, encodedAs: Encoding, using:
>> Decoder = Encoding.ValidatingDecoder)
>> where C: Collection, C.Iterator.Element == Encoding.CodeUnit,
>> Decoder.Encoding == Encoding {
>> 

>>  // transcode to native String encoding using ‘Decoder’ we
>>  were given
>> }

>> }

> 

> - Karl

> _

> swift-evolution mailing list

> swift-evolution@swift.org

> https://lists.swift.org/mailman/listinfo/swift-evolution


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

Re: [swift-evolution] [Pitch] Making some RawRepresentable things bridge to ObjC as their raw value

[Zach Waldowski via swift-evolution]

I hate to be a thread necromancer, but I ran into the limits of the current 
behavior several times today alone. I was perhaps overexcited by the additional 
ObjectiveCBridgeable compliance of numeric types, and took off several 
`.rawValue`s in a way that were hard to track down.

A few other examples, similar to what came up in the original thread:

1. An options dictionary.

```
let detectedEncoding = NSString.stringEncoding(for: content, encodingOptions: [
.suggestedEncodingsKey: [ String.Encoding.utf8 ]
], convertedString: nil, usedLossyConversion: nil)
```

This syntax looks surprisingly Swifty, but fails at runtime. id-as-Any means a 
new developer can go a long way without knowing many types even /are/ 
RawRepresentable.

2. KVC. Given a newtype wrapper, I can have:

```
class StrawMan: NSObject {
dynamic var lookMa: Notification.Name?
}

var demo: StrawMan = …
demo.lookMa = .noStrings


But I can’t do:

```
demo.setValue(Notification.Name.noStrings, forKey: #keyPath(StrawMan.lookMa))
```

Worse, again, this only fails at runtime, rather than at compile time.

3. Generics, similar in scope to #2.

```
class ValueTransformer: Foundation.ValueTransformer {
// use your imagination, id-as-Any is involved
}

@objc enum TestEnum: Int { case one, two, three }

let t = ValueTransformer(…) // mysteriously fails because a 
TestEnum crosses Any as _SwiftValue
```

Like I say above, armed with the vague recollection of my proselytizing about 
id-as-Any, especially the extent to how well stuff like NSNull bridging works, 
a team member could easily make mistakes that aren’t caught until runtime. 
Between example #2 and #3 I consider the behavior today to be approaching bug 
territory because of its big breakage of the principle of least surprise.

Though I’m sympathetic with the fears from the original thread(s) about making 
the bridge too fuzzy, I think being @objc, conforming to RawRepresentable, and 
the RawValue conforming to ObjectiveCBridgeable is more than enough information 
to go on (without treading into territory of purposefully misusing 
RawRepresentable). RawRepresentable requires a failable initializer, and I 
expect a well-behaved initializer to tie in with casting of the RawValue to 
make an overall “as?” cast work as expected, fuzziness be damned.

In basically every case I can think of involving the Cocoa bridge, bridging 
using the RawValue is the right behavior. In most cases not considering the 
Cocoa bridge, a predictable set of rules combined with an explicit “as?” Cast 
is more than explicit enough to justify whatever behavior the compiler comes up 
with.

Overall, It makes me more than uneasy to use a compiler feature about which the 
most confidence I can get is reading the stdlib/overlay sources to find out 
what secret conformances are declared. 

Best,
Zach
z...@waldowski.me
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Pitch] Make `errno`-setting functions more usable from Swift

[Zach Waldowski via swift-evolution]

I could see the "swift_error" Clang attribute being extended with an
"errno" case (in the same vein as "nonzero_result" and "zero_result"),
which is then reflected into Swift via the importer. Although, having an
attribute for methods set errno seems like it would be useful for the
Clang Analyzer overall.

Cheers!
  Zach

On Wed, Nov 2, 2016, at 09:12 AM, Johannes Weiß via swift-evolution
wrote:
> Hey swift-evolution,
> 
> First of all apologies, this is not a full proposal yet, it's meant to
> kick off a discussion on how to resolve the issue.
> 
> # Make `errno`-setting functions more usable from Swift
> 
> ## Introduction
> 
> This is a pitch to make [`errno`][1]-setting functions properly usable,
> as in having a guarantee to get the correct `errno` value on failure of a
> [system call][2]. Currently, functions which set `errno` are just
> exported in the Darwin/Glibc modules with (as far as I understand) no
> guaranteed correct way of handling errors as the correct `errno` value
> can't be retrieved.
> This means that much of the Swift code which uses Darwin/Glibc out there
> relies on behaviour that isn't guaranteed.
> 
> 
> ## Motivation
> 
> In many Swift libraries that use the Darwin/Glibc modules there is code
> similar to:
> 
> ```
> /* import Darwin/Glibc */
> 
> let rv = some_system_call(some, parameters)
> if rv < 0 {
>throw SomeError(errorCode: errno) /* <-- errno use */
> }
> ```
> 
> That looks very innocent but please note that `errno` is used here. And
> `errno` is an interesting one as it's a thread-local variable which is
> written to by many functions. A thread-local variable is like a global
> variable except that setting it in one thread does not affect its value
> in any other thread. Pretty much all system calls and many library
> functions set `errno` if something went wrong.
> 
> The problem is that as far as I see (and Swift developers have
> confirmed), there is no guarantee that in between the call of
> `some_system_call` and the reading of `errno`, `errno` hasn't been
> overwritten by some other system call that has been call on the same
> thread.
> 
> To illustrate this further, let's consider this example
> 
> ```
> /* import Darwin/Glibc */
> public class SomeClass {
>   public let someValue: Int = 1
>   deinit {
>   /* call some failing syscall, for example */
>   write(-1, nil, 0) /* should set errno to EBADF */
>   }
> }
> 
> public func foo() {
>let x = SomeClass()
>let rv = write(x.someValue, nil, 0)
>let errnoSave = errno
>if rv != 0 {
>   throw SomeError(errorCode: errnoSave)
>}
> }
> ```
> 
> as you see in function `foo`, the instance `x` of `SomeClass` isn't
> needed anymore as soon as `write` has been called. So (as far as I
> understand) there's no guarantee that ARC doesn't turn the above code
> into
> 
> ```
> let x = SomeClass()
> let rv = write(x.someValue, nil, 42) /* should set errno to EFAULT */
> /* ARC generated */ x.release()
> let errnoSave = errno /* wrong errno value :( */
> if rv != 0 {
>   throw SomeError(errorCode: errnoSave)
> }
> ```
> 
> And the ARC generated `x.release()` will cause `x` to be deallocated
> which will call the failing `write` in the `deinit` of `SomeClass`. So
> `errnoSave` might be `EBADF` instead of `EFAULT` depending on where ARC
> put the `x.release()` call.
> 
> What `errno` value we read will depend on the optimisation settings and
> the Swift compiler version. That's IMHO a big issue as it might make the
> lowest layers unstable with hard-to-debug issues.
> 
> 
> ## Proposed solution
> 
> I don't have a full story on how to actually resolve the issue but I see
> a few options:
> 
> ### Option 1: always return errno
> 
> clang importer could be changed to make all `errno`-setting functions
> return a tuple of the actual return value and the `errno` value.
> 
> For example, currently write(2) is imported as:
> 
> ```
> public func write(_ __fd: Int32, _ __buf: UnsafeRawPointer!, _ __nbyte:
> Int) -> Int
> ```
> 
> which could be changed to
> 
> ```
>  public func write(_ __fd: Int32, _ __buf: UnsafeRawPointer!, _ __nbyte:
>  Int) -> (Int, Int32 /* for errno */)
> ```
> 
> Correct code to use write would then look like this:
> 
> ```
> let (bytesWritten, writeErrno) = write(fd, buf, len)
> if bytesWritten >= 0 {
>/* everything's fine */
> } else {
>throw POSIXError(code: writeErrno)
> }
> ```
> 
> 
> ### Option 2: make them throw
> 
> The second option is to teach clang importer to make the functions
> throwing. So write(2) would be imported as
> 
> ```
> public func write(_ __fd: Int32, _ __buf: UnsafeRawPointer!, _ __nbyte:
> Int) throws /* POSIXError */ -> Int
> ```
> 
> That would make these functions quite easy to use and would feel natural
> in Swift:
> 
> ```
> do {
>let bytesWritten = write(fd, buf, len)
> } catch let e as POSIXError {
>/* handle error */
> } catch {
>...
> }
> ```
> 
> 
> ### Discussion
> 
> The beauty of option 1 is simplicity. Clang 

Re: [swift-evolution] [swift-dev] SE-0047 - Defaulting non-Void functions so they warn on unused results

[Zach Waldowski via swift-evolution]

If you're engaging in a non-standard design pattern, that you are
willfully writing yourself, I really don't see what the problem is with
applying @discardableResult to declarations that need it, just like any
of Swift's other decorators that describe convention and use patterns.

Cheers,
  Zach


On Sun, Oct 30, 2016, at 01:52 PM, Jody Schofield via swift-evolution wrote:
> I think assumptions are being made that shouldn't be. For example I
> use a lot for design patterns such as the builder. Most of the methods
> return a reference to self so they can be chained together. The
> compiler shouldn't tell me I'm wrong for ignoring those return values.
> It use to be my decision.
> Swift was already a very opinionated language and I can see it's being
> taken even further. A mistake in my opinion and one that is certainly
> making the language more frustrating than pleasurable to use.
>
>
>
> On Oct 30, 2016, at 1:32 PM, Robert Widmann
>  wrote:
>> Functions that return values return them for a reason.  Ignoring them
>> is, more likely than not, an oversight that should be corrected,
>> hence @discardableResult.  We're talking error codes, object lifetime
>> tokens, failure indicators, etc.  All things that result in ignoring
>> critical code paths for the sake of convenience.  If you find
>> yourself executing a lot of side effects and ignoring return values,
>> I would take a look at why.  A lot of times you have control over the
>> API and can eliminate some of these unused return values.  Otherwise,
>> please try to see if the return values of these functions are
>> relevant to the well-being of your program.
>>
>> ~Robert Widmann
>>
>> 2016/10/30 8:49、Jody Schofield via swift-dev 
>> のメッセージ:
>>> Sorry, I'm sure this has been discussed before, but what the heck???
>>>
>>> This feature is killing me. Now I have go add @discardableResult to
>>> every function that returns a non-Void or use the ugly syntax `_ =`?
>>>
>>> Until swift 3 I've really enjoyed the new language. Now I find it to
>>> be getting too rigid for the sake of "protecting" me from myself.
>>> The safety levels needs to be dialled back some.
>>>
>>>
>>> ___
>>> swift-dev mailing list
>>> swift-...@swift.org
>>> https://lists.swift.org/mailman/listinfo/swift-dev
> _
> 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] [Discussion] API Guidelines

[Zach Waldowski via swift-evolution]

The base name of the function describes its core purpose.

There is no ambiguity instructing an Array to "append" something, but
there is context needed: "what are we appending? The contents of the
newElements parameter." But there is ambiguity asking URL to "give me a
new URL by appending". Appending what? Similarly, telling a collection
to "replace". Replace what?

A rule of thumb my team has applied is to put the parameter parens where
you would have put `with` in ObjC. This is instructive for your
questions as well. "URLByAppendingWithPathComponent" and
"replaceWithSubrange" wouldn't make sense, but "appendWithContentsOf"
does.

Cheers!
  Zachary Waldowski
  z...@waldowski.me

On Thu, Oct 13, 2016, at 10:30 PM, Charlie Monroe via swift-evolution
wrote:
> Hi there,
> 
> I am really grateful for the API guidelines that were created as part of
> Swift 3, however, I'm having trouble with distinguishing which part of
> the method name should be already an argument. To illustrate this, here
> are two examples:
> 
> // On Array
> public mutating func append(contentsOf newElements: S)
> 
> // On Foundation.URL
> public func appendingPathComponent(_ pathComponent: String) -> URL
> 
> 
> Is there a particular reason why it's not
> 
> public func appending(pathComponent: String) -> URL
> 
> ?
> 
> In my opinion the entire stdlib and Foundation is full of such
> discrepancies which make it hard to decide when you name your own methods
> since there are preceding cases in the language itself (or Foundation)
> that go both ways.
> 
> The same goes for why don't the replace methods (this is on String)
> follow the same - when there is append(contentsOf:):
> 
> public mutating func replaceSubrange(_ bounds: ClosedRange,
> with newElements: String)
> 
> instead of
> 
> public mutating func replace(subrange bounds: ClosedRange,
> with newElements: String)
> 
> 
> 
> I know there was an extensive discussion about this here when the stdlib
> names were discussed. And given that these would be breaking changes, I
> don't necessarily want to start a lengthy discussion about renaming those
> again - I'm just wondering what are the reasons behind this and what
> should be the correct naming conventions.
> 
> Thanks!
> 
> Charlie
> ___
> 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] private & fileprivate

[Zach Waldowski via swift-evolution]

On Fri, Oct 7, 2016, at 03:56 PM, Jordan Rose wrote:
> SE-0025 was *very* heavily discussed, and while many people were not
> satisfied with the solution we went with (including me!), it was what
> the core team and community converged on.

Politely playing the Devil's Advocate: it was still fairly early on in
the lifecycle of swift-evolution, particularly for the 3 cycle; the
discussion was heavily weighted towards the people who wanted a change,
versus those who were happy with the status quo. I don't like playing
the Silent Majority card, as it's a horribly weak fallacy, but it is
what it is.

(responding up-thread now to William…)

>>> On Oct 7, 2016, at 15:15, William Sumner via swift-evolution >> evolut...@swift.org> wrote:
>>>
>>> Really, there’s not much point in rehashing prior discussion of SE-
>>> 0025 unless there’s a previously unconsidered angle.

The new information is that Swift 3 is in the wild. People have gotten
to use it, users both new and old, and have been dismayed and confused,
respectively, with the change.

I appreciate the need for the community to keep pushing forward and not
constantly revisit and counter-proposal things, I really do. It's why I
was glad it seemed like "requiring `self.`" was laid to bed so
conclusively. But this isn't like C-style for loops, I'm not clinging to
my guns and incrementors; we've taken something that enjoyed a quite
simple mental model, even though it was limited compared to other
languages, and made it arbitrarily more complex.

Having come to a consensus (which I disagree happened; more the clock
ran ) shouldn't mean it's locked in stone forever. In fact, the
potential for reconsidering was mentioned by many in response to the
blowback to sealed-by-default, and was  used for justification as to why
it "had" to be considered for Swift 3.

It's important to recognize our mistakes and not get into the trap of
thinking the mailing list is the ground truth of all  Swift users.

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

Re: [swift-evolution] private & fileprivate

[Zach Waldowski via swift-evolution]

On Fri, Oct 7, 2016, at 02:08 PM, Shawn Erickson via swift-evolution wrote:
> Also based on what do we really see an issue with the addition of
> fileprivate? It seems more theory then examples of problems in the
> discussions I have seen.

I've migrated multiple projects, both for my own use and for clients.
I've taught Swift 3 to my colleagues as we upgrade, and have to help
seasoned developers through confusion. I've taught Swift 3 to people who
don't know Swift, and have to help novice developers through confusion.
I watch as other developers fight this, such as on Twitter, while
fileprivate is a joke unto its own. That's hardly theoretical.

Sincerely,
  Zachary Waldowski
  z...@waldowski.me
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] private & fileprivate

[Zach Waldowski via swift-evolution]

I third this sentiment. fileprivate is a nice idea and very clearly has
its uses (which is why the proposal got traction in the first place),
but when  combined with the other access levels, the language feature as
a whole feels arbitrary. In practical use, files that I felt were nicely
encapsulated and hiding implementation details are now a scattered mix
of access levels, adding cognitive load and making the code look
unorganized for having the gall to use extensions to split up
functionality.

Sincerely,
  Zachary Waldowski
  z...@waldowski.me


On Fri, Oct 7, 2016, at 01:55 PM, Russ Bishop via swift-evolution wrote:
>
>> On Oct 7, 2016, at 9:13 AM, David Hart via swift-evolution > evolut...@swift.org> wrote:
>>
>> I started the topic, but I also believe like you that the
>> *fileprivate* vs *private(file)* discussion has already been
>> thoroughly discussed and nothing new has been brought up. That’s not
>> what I want to discuss.
>>
>> I instead want to share my experience using *private* and
>> *fileprivate* since release. Here are my thoughts:
>>
>>  1. We should start with the premise that the proposal has added a
>> substantial amount of complexity:
>>1. It has added an extra modifier and access level to learn.
>>2. It has complicated the access level rules with Inner types as
>>   mentioned in the *Complications with private types* section of
>>   the proposal.
>>3. I have seen many people (twitter, work, slack) be confused
>>   about the difference between *private* and *fileprivate* at the
>>   global level. The answer is none, which shows that both
>>   modifiers are not very orthogonal.
>>4. Since release, I saw people prefer one over the other, as a
>>   matter of style. They tend to always use *fileprivate* or
>>   always using *private*. In the latter case, functions and
>>   properties get clumped in the same class scope instead of be
>>   written through multiple extensions.
>>  2. I have the impression that the motivations for the proposal are
>> much less real in practice:
>>1. The first motivation stated is: *"It is not clear whether the
>>   implementation details are meant to be completely hidden or can
>>   be shared with some related code without the danger of misusing
>>   the APIs marked as private.”* I’ve found that to be fairly rare
>>   in practice because the implementation details only used to
>>   leak inside the same file, which greatly reduces the dangers.
>>2. The second motivation stated is: *"It forces a one class per
>>   file structure, which is very limiting." *First of all, this is
>>   partly false. I think it forces putting classes which share
>>   implementation details in the same file, which I don’t think is
>>   necessarily a bad thing.
>>
>> To summarise, it seems that the confusion the proposal brought over
>> semantics and style are not worth the limited benefits that it
>> brought. I’d be tempted to backtrack the proposal and re-introduce
>> private as a file scoped access-level and deprecate fileprivate.
>>
>> Thoughts?
>> David.
>>
>
>
> I agree. The minor benefit that fileprivate brings is not worth the
> cognitive overhead it introduces. We should just admit it was a
> mistake and back it out. We can avoid source-breaking changes by
> making fileprivate a synonym for private and provide fixits/warnings
> for a release to give people a chance to move off it.
>
>
>
> Russ
>
> _
> 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] Making some RawRepresentable things bridge to ObjC as their raw value

[Zach Waldowski via swift-evolution]

I think limiting to types that are both @objc and RawRepresentable is a
nice compromise; that limits the type preservation needed to work around
"slushiness" to NSString, NSNumber (already done), and NSError.

I know your pitch doesn't cover this problem, but I would also note that
C varargs suffer from the same "needing to know to get the rawValue"
problem.

Sincerely,
  Zachary Waldowski
  z...@waldowski.me

On Thu, Sep 29, 2016, at 10:16 AM, Joe Groff via swift-evolution wrote:
> In the discussion around SE-0139 (bridging NSNumber and NSValue), many
> people pointed out that it's common in ObjC to use NSNumbers holding enum
> constants in Cocoa containers. Many ObjC interfaces look something like
> this:
> 
>   /// A washing machine.
>   @interface QXWashingMachine
> 
>   /// Wash cycles supported by the washing machine.
>   typedef NS_ENUM(NSInteger, QXWashCycle) {
> QXWashNormal,
> QXWashDelicates,
> QXWashLinens,
>   };
> 
>   /// Perform a sequence of wash cycles. Takes an NSArray of QXWashCycle 
> constants passed
>   /// as NSNumbers.
>   - (void)performWashCycles:(NSArray *)cycles;
> 
>   @end
> 
> In ObjC, you can call this API like this:
> 
>   [washingMachine performWashCycles:@[
> @(QXWashLinens),
> @(QXWashDelicates),
>   ]];
> 
> In Swift 3, the equivalent code will compile, but fail at runtime,
> because the enum type falls back to opaque object bridging instead of
> using NSNumbers:
> 
>   // Fails at runtime, because WashCycle constants don't implicitly 
> bridge to NSNumber
>   washingMachine.perform(washCycles: [WashCycle.linens, 
> WashCycle.delicates])
> 
> so you have to know to get the `rawValue`s out first:
> 
>   // Fails at runtime, because WashCycle constants don't implicitly 
> bridge to NSNumber
>   washingMachine.perform(washCycles: [WashCycle.linens.rawValue, 
> WashCycle.delicates.rawValue])
> 
> We encountered similar problems last year as we developed the
> `swift_newtype` ObjC feature last year, which enabled us to import some
> stringly-typed ObjC APIs with stronger types in Swift. A type like
> `Notification.Name`, which represents a set of NSString constants, is
> imported to be RawRepresentable as String and also to bridge to
> Objective-C as one, by having the compiler implicitly generate a
> conformance to the internal _ObjectiveCBridgeable protocol for it. We
> could conceivably do one of the following things:
> 
> - Have the compiler generate a bridging conformance for imported NS_ENUM
> and NS_OPTIONS types, and perhaps also for @objc enums defined in Swift,
> like we do for newtypes.
> - Alternatively, we could say that *anything* with a RawRepresentable
> conformance bridges to ObjC as its rawValue.
> 
> The second one is conceptually appealing to me, since RawRepresentable is
> already something newtypes, enums, and option sets have in common in
> Swift, but I think it may be too lax—it would effectively make
> RawRepresentable the user interface to Objective-C bridging, which I'm
> not sure is something we want. Limiting the bridging behavior to @objc
> enums and imported option sets limits the impact, though there are still
> tradeoffs to consider:
> 
> - Adding any new bridging behavior has the potential to break existing
> code that relies on the current opaque object bridging. We tell people
> not to do that, of course, but that's no guarantee that people don't.
> - As with newtypes, the bridged Objective-C representation loses type
> information from Swift, meaning that dynamic casts potentially need to
> become "slushier". Swift maintains the distinction between
> Notification.Name and String, for example, but once a value of either
> type has been bridged to NSString, the distinction is lost, so we have to
> allow casts from NSString back to either String or Notification.Name. If
> we bridge enums and option sets, we would similarly lose type information
> once we go to NSNumber. We can in some cases mitigate this for class
> clusters like NSString or NSNumber by using our own subclasses that
> preserve type info, which can at least preserve type info for
> Swift-bridged objects, though we can't do this universally for all
> Cocoa-sourced objects.
> 
> -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] class/struct inner member access scope classifier

[Zach Waldowski via swift-evolution]

On Tue, Sep 27, 2016, at 01:34 AM, Jeremy Pereira via swift-evolution
wrote:
> As for dropping file private, why? You don’t have to use it if you don’t
> want to, so it’s not hurting you. On the other hand, I can use it when I
> deem it to be the right thing to do. 

I'll politely disagree and point out you *must* use fileprivate in order
to get what it provides. It's unavoidable in that sense.

As the access control change has been implemented for what only can be
described in a number of weeks, it's disappointing that a feature I used
to great effect in prior versions of Swift has already been relegated to
"if you don't like the name, don't use it." 

Sincerely,
  Zachary Waldowski
  z...@waldowski.me
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] The great renaming and the state of new Unified Logging in Swift

[Zach Waldowski via swift-evolution]

For a wrapper, are there any public hooks into dyld that allow us to do
anything meaningful with #dsoHandle on prior OS? Without that, and
without using #dsoHandle, wrapping os_log is essentially useless.

Cheers!
  Zachary Waldowski
  z...@waldowski.me


On Mon, Sep 5, 2016, at 10:59 AM, Douglas Gregor via swift-evolution wrote:
>
>
> Sent from my iPhone
>
> On Sep 4, 2016, at 11:48 PM, Goffredo Marocchi
>  wrote:
>> Hey Doug,
>>
>> How do I use it in Swift code without a wrapper, which is
>> understandably a bit pointless, if I still support iOS 9?
>
> #if or a wrapper are your best options.
>
>   - Doug
>
>>
>> Sent from my iPhone
>>
>> On 5 Sep 2016, at 05:05, Brandon Knope via swift-evolution > evolut...@swift.org> wrote:
>>> Where should the lack of {public} be reported then?
>>>
>>> This seems like it falls under jira and not radar because it's in
>>> swift open source but I'm not 100 percent
>>>
>>> Brandon
>>>
>>> Sent from my iPad
>>>
>>> On Sep 4, 2016, at 11:48 PM, Douglas Gregor 
>>> wrote:


 Sent from my iPhone

 On Sep 3, 2016, at 11:32 AM, Ben Rimmington via swift-evolution >>> evolut...@swift.org> wrote:
>
>> On 3 Sep 2016, at 19:13, Brandon Knope  wrote:
>>
>> Thank you! I was looking for this last night and failed.
>>
>> Why do you think {public} isn't included?
>
> I don't know, but trying to reimplement __builtin_os_log_format in
> the overlay seems wrong. It would be better to have a variant of
> __builtin_os_log_format which takes a va_list.


 __builtin_os_log_format is implemented by Clang, not a library, and
 is quite involved. Implementing os_log in an overlay to provide
 near feature-compatibility with the C API is the right approach for
 Swift 3, where a more comprehensive solution (say, a general
 logging API based on string interpolation or similar) is way out of
 scope.

   - Doug


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

Re: [swift-evolution] [Proposal draft] Bridge Numeric Types to NSNumber and Cocoa Structs to NSValue

[Zach Waldowski via swift-evolution]

Early feedback is +1, you folks sure know how to write proposals on
Foundation. ;-)

I filed radar  related to this a while ago. Is
there any chance the struct conformances could be applied using the
objc_boxable attribute added to Clang last year? Apple's definition of
what they consider to be simple, fixed structs should ideally live in
one place (apinotes would do as well).

Sincerely,
  Zachary Waldowski
  z...@waldowski.me


On Tue, Aug 23, 2016, at 03:36 PM, Douglas Gregor via swift-evolution wrote:
> Introduction
> A handful of Swift numeric types are bridged to NSNumber when passed
> into Objective-C object contexts. We should extend this bridging
> behavior to all Swift numeric types. We should also bridge common
> Cocoa structs such as NSRangeby boxing them into NSValue objects.
> Swift-evolution thread: TBD[1]
> Motivation
> SE-0116[2] changed how Objective-C's id and untyped collections import
> into Swift to use the Any type. This makes it much more natural to
> pass in Swift value types such as String and Array, but introduces the
> hazard of passing in types that don't bridge well to Objective-C
> objects. Particularly problematic are number types; whereas Int, UInt,
> and Double will automatically bridge as NSNumber, other-sized numeric
> types fall back to opaque boxing:
> let i = 17 let plist = ["seventeen": i] // OK try!
> NSJSONSerialization.data(withJSONObject: plist)

> let j: UInt8 = 38 let brokenPlist = ["thirty-eight": j] // Will throw
> because `j` didn't bridge to a JSON type try!
> NSJSONSerialization.data(withJSONObject: brokenPlist)
> We had shied away from enabling this bridging for all numeric types in
> the Swift 1.x days, among other reasons because we allowed implicit
> bridging conversions in both directions from Swift value types to NS
> objects and back, which meant that you could slowly and brokenly
> convert between any two numeric types transitively via NSNumber if we
> allowed this. We killed the implicit conversions completely with SE-
> 0072[3] so that is no longer a concern, so expanding the bridging
> behavior should no longer be a major problem, since it must now always
> be explicitly asked for.
> There are also many Cocoa APIs that accept NSArray and NSDictionary
> objects with members that are NSValue-boxed structs. Matt Neuberg
> highlights Core Automation as an example in this bug report[4]. With
> id-as-Any, it's natural to expect this to work:
> anim.toValue = CGPoint.zero
> However, the CGPoint value does not box as a meaningful Objective-C
> object, so this currently breaks Core Animation at runtime despite
> compiling successfully. It would be more idiomatic to bridge these
> types to NSValue.
> Proposed solution
> All of Swift's number types should be made to bridge to NSNumber when
> used as objects in Objective-C:


>  * Int8
>  * Int16
>  * Int32
>  * Int64
>  * UInt8
>  * UInt16
>  * UInt32
>  * UInt64
>  * Float
>  * Double
> Cocoa structs with existing NSValue factory and property support
> should be made to bridge to NSValue when used as objects:


>  * NSRange
>  * CGPoint
>  * CGVector
>  * CGSize
>  * CGRect
>  * CGAffineTransform
>  * UIEdgeInsets
>  * UIOffset
>  * CATransform3D
>  * CMTime
>  * CMTimeRange
>  * CMTimeMapping
>  * MKCoordinate
>  * MKCoordinateSpan
>  * SCNVector3
>  * SCNVector4
>  * SCNMatrix4
> Detailed design
> Bridged NSNumber and NSValue objects must be castable back to their
> original Swift value types. NSValue normally preserves the type
> information of its included struct in its objCType property. We can
> check the objCType of an NSValue instance when attempting to cast back
> to a specific bridged struct type.
> NSNumber is a bit trickier, since Cocoa's implementation does not
> generally guarantee to remember the exact number type an instance was
> constructed from. We can instead say that casting an NSNumber to a
> Swift number type succeeds if the value of the NSNumber is exactly
> representable as the target type. This is imperfect, since it means
> that an NSNumbercan potentially be cast to a different type from the
> original value, but it at least ensures that Swift values round-trip
> through the bridge without depending on NSNumber implementation
> details.
> Impact on existing code
> This change has no static source impact, but changes the dynamic
> behavior of the Objective-C bridge. From Objective-C's perspective,
> values that used to bridge as opaque objects will now come in as
> semantically meaningful Objective-C objects. This should be a safe
> change, since existing code should not be relying on the behavior of
> opaque bridged objects. From Swift's perspective, values should still
> be able to round-trip from concrete number and struct types to Anyto
> id to Any and back by dynamic casting. The ability to reliably
> distinguish the exact number type that an NSNumberwas constructed from
> would be lost.
> Alternatives considered
> We can of course do nothing and leave the behavior as-is.
> 

Re: [swift-evolution] InternalString class for easy String manipulation

[Zach Waldowski via swift-evolution]

It's 2016, "the thing people would most commonly expect"
impossible-to-screw-up Unicode support that's performance. Optimizing
developer experience for beginning developers is just going to lead to
software that screws up in situations the developer doesn't anticipate,
as F+¬lix notes above.

Zachary

On Wed, Aug 17, 2016, at 09:40 AM, Kenny Leung via swift-evolution
wrote:
> I understand that the most friendly approach may not be the most
> efficient, but that’s not what I’m pushing for. I’m pushing for "does the
> thing people would most commonly expect”. Take a first-time programmer
> who reads any (human) language, and that is what they would expect.
> 
> Why couldn’t String’s internal storage format be glyph-based? If I were,
> say, writing a text editor, it would certainly be the easiest and most
> efficient format to work in.
> 
> -Kenny
> 
> 
> > On Aug 15, 2016, at 9:20 PM, Félix Cloutier  wrote:
> > 
> > The major problem with this approach is that visual glyphs themselves have 
> > one level of variable-length encoding, and they sit on top of another 
> > variable-length encoding used to represent the Unicode characters 
> > (Swift-native Strings are currently encoded as UTF-8). For instance, the 
> > visual glyph  is the the result of putting side-by-side the Unicode 
> > characters  and  ("REGIONAL INDICATOR SYMBOL LETTER U" and "REGIONAL 
> > INDICATOR SYMBOL LETTER S"), which are themselves encoded as UTF-8 using 4 
> > bytes each. A design in which you can "just write" string[4544] hides the 
> > fact that indexing is a linear-time operation that needs to recompose UTF-8 
> > characters and then recompose visual glyphs on top of that.
> > 
> > Generally speaking, I *think* that I agree that human-geared "long string" 
> > on which you probably won't need random access, and machine-geared smaller 
> > strings that encode a command, could benefit from not being considered the 
> > same fundamental thing. However, I'm also afraid that this will end with 
> > more applications and websites that think that first names only contain 
> > 7-bit-clean characters in the A-Z range. (I live in the US and I can attest 
> > that this is still very common.)
> > 
> > You could make a point too that better facilities to parse strings would 
> > probably address this issue.
> > 
> > Félix
> > 
> >> Le 15 août 2016 à 10:52:02, Kenny Leung via swift-evolution 
> >>  a écrit :
> >> 
> >> I agree with both points of view. I think we need to bring back 
> >> subscripting on strings which does the thing people would most commonly 
> >> expect.
> >> 
> >> I would say that the subscripts indexes should correspond to a visual 
> >> glyph. This seems reasonable to me for most character sets like Roman, 
> >> Cyrillic, Chinese. There is some doubt in my mind for things like 
> >> subscripted Japanese or connected (ligatured?) languages like Arabic, 
> >> Hindi or Thai.
> >> 
> >> -Kenny
> >> 
> >> 
> >>> On Aug 15, 2016, at 10:42 AM, Xiaodi Wu via swift-evolution 
> >>>  wrote:
> >>> 
> >>> On Sun, Aug 14, 2016 at 5:41 PM, Michael Savich via swift-evolution 
> >>>  wrote:
> >>> Back in Swift 1.0, subscripting a String was easy, you could just use 
> >>> subscripting in a very Python like way. But now, things are a bit more 
> >>> complicated. I recognize why we need syntax like 
> >>> str.startIndex.advancedBy(x) but it has its downsides. Namely, it makes 
> >>> things hard on beginners. If one of Swift's goals is to make it a great 
> >>> first language, this syntax fights that. Imagine having to explain 
> >>> Unicode and character size to an 8 year old. This is doubly problematic 
> >>> because String manipulation is one of the first things new coders might 
> >>> want to do. 
> >>> 
> >>> What about having an InternalString subclass that only supports one 
> >>> encoding, allowing it to be subscripted with Ints? The idea is that an 
> >>> InternalString is for Strings that are more or less hard coded into the 
> >>> app. Dictionary keys, enum raw values, that kind of stuff. This also has 
> >>> the added benefit of forcing the programmer to think about what the 
> >>> String is being used for. Is it user facing? Or is it just for internal 
> >>> use? And of course, it makes code dealing with String manipulation much 
> >>> more concise and readable.
> >>> 
> >>> It follows that something like this would need to be entered as a literal 
> >>> to make it as easy as using String. One way would be to make all String 
> >>> literals InternalStrings, but that sounds far too drastic. Maybe 
> >>> appending an exclamation point like "this"! Or even just wrapping the 
> >>> whole thing in exclamation marks like !"this"! Of course, we could go old 
> >>> school and write it like @"this" …That last one is a joke.
> >>> 
> >>> I'll be the first to admit I'm way in over my head here, so I'm very open 
> >>> to suggestions 

Re: [swift-evolution] Addition of a standardError OutputStream

[Zach Waldowski via swift-evolution]

`Process` might be a good place for namespacing these. You'll also note
that `print` can take an OutputStream to make this even more idiomatic.
Straw man example at
https://gist.github.com/zwaldowski/4ed2fd48da2af3193b0cbd3ec1883c9d.
 
Cheers!
  Zachary Waldowski
  z...@waldowski.me
 
 
On Mon, Jul 11, 2016, at 12:24 PM, Erica Sadun via swift-evolution wrote:
> Just throwing this here. Unfortunately `Stream` is already taken (and
> tied to Foundation).
>
> public struct StdStream {
>  public struct StderrStream: OutputStream {
>  public func write(_ string: String) { fputs(string, Darwin.stderr) }
> }
>
>  public struct StdoutStream: OutputStream {
>  public func write(_ string: String) { fputs(string, Darwin.stdout) }
> }
>
>  public static var err = StderrStream()
>  public static var out = StdoutStream()
> }
>
> So in use, it would look something like
>
> str.write(to: )
> str.write(to: )
>
> I also considered DarwinStream (seemed too on the nose), UnixStream,
> Streamfd, BSDStream, etc. Didn't like any of them.
>
> -- E, have paintbrush will bikeshed
>
>
>> On Jul 11, 2016, at 12:58 PM, Saagar Jha via swift-evolution > evolut...@swift.org> wrote:
>>
>> Thanks, I’ll write it up.
>>> On Jul 11, 2016, at 11:20, Dave Abrahams via swift-evolution >> evolut...@swift.org> wrote:
>>>
>>>
>>> on Sun Jul 10 2016, Saagar Jha  wrote:
>>>
 What is the process for smaller issues like these? I’m
 guessing that
 this doesn’t need a proposal; where should it go? On bugs.swift.org
 ?
>>>
>>> If it adds an API, it needs a proposal.  Doesn't necessarily
>>> have to be
>>> a big proposal, and the review period can be short, but we don't add
>>> APIs without the evolution process.
>>>
>>> Thanks,
>>> 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
> _
> 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] Extending Swift Literals

[Zach Waldowski via swift-evolution]

I share the concern with others about the usefulness of these, but I
also like your note about standardizing syntax, and really like that
these merge together all the different syntaxes for literals we've seen.
 
To that end, I'd like to modestly suggest that #literal.foo (as already
written in the proposal) should be the canonical form of a literal in
source text, whereas #foo is the one you see used in the code editor.
I'm not a fan of namespacing in #literal, because every literal should
obviously be a literal; I wouldn't ever recommend numerals fall under
this proposal as written, for instance.
 
Sincerely,
  Zachary Waldowski
  z...@waldowski.me
 
 
On Sun, Jul 10, 2016, at 08:48 PM, Erica Sadun via swift-evolution wrote:
> This is purely additive and would not be eligible for Swift 3.
> gist: https://gist.github.com/erica/c92f6ab115af89d5c4b9161487df6a3c
>
> -- E
>
> Extending Swift Literals


>  * Proposal: TBD
>  * Author: Erica Sadun[1]
>  * Status: TBD
>  * Review manager: TBD
> Introduction
> This proposal expands Swift's language literals to include common cross-
> platform concepts that need not require.
> Motivation
> A Swift literal represents a fixed value in source code. A literal can
> be a string, a number (for example an integer), a compound value (such
> as an array), or one of several predefined "playground" literals
> including colors, resource file paths, and resource images.
> Swift literals do not have types. They are universal representations
> that are evaluated and their types inferred from the context in which
> they are used. Because their nature is typeless, the same color
> literal can initialize UIColor, NSColor, and SKColor instances. The
> type cannot be inferred from the source without the context of its
> destination.


> let color = #colorLiteral(red: 0.8100712299, green: 0.1511939615,
> blue: 0.4035313427, alpha: 1)
>
> Detailed Design


> *Namespace redesign*** Kind Literal Parameters Color
> `#literal.color(red:, green:, blue:, alpha:)` floating point values
> Image `#literal.image(resourceName:)` String with resource name File
> `#literal.file(resourceName:)` String with resource name *General***
> Kind Literal Parameters Sound `#literal.audio(resourceName:)` String
> with resource name URL `#literal.url(string:)`,
> `#literal.url(filePath:)` String with resource location Font
> `#literal.font(face:, size:)` string, floating point Date
> `#literal.date(timeInterval:)` floating point offset from Unix epoch
> Unicode `#literal.unicode(name:)` Official unicode name, e.g.
> `#literal.unicode(name:"DOG FACE")` *Geometry*** Kind Literal
> Parameters Point `#literal.point(x:, y:)`, `#literal.point(x:, y:,
> z:)`, `#literal.point(x:, y:, z:, w:)` floating point values Vector
> `#literal.vector(dx:, dy:)`, `#literal.vector(dx:, dy:, dz:)`,
> `#literal.vector(dx:, dy:, dz:, dw:)` floating point Size
> `#literal.size(width:, height:)`, `#literal.size(width:, height:,
> depth:)` floating point Rect `#literal.rect(x:, y:, width:, height:)`
> floating point Affine Transform
> `#literal.affineTransform(a:,b:,c:,d:,tx:,ty:)`,
> `#literal.affineTransform(translateX:, translateY:)`,
> `#literal.affineTransform(scaleY:, scaleY:)`,
> `#literal.affineTransform(rotation:)`, floating point Bezier Path
> `#literal.bezier("M92.21,24.29H75L73,17a8.32,8.32, 
> 0,0,0-8.27-6.74H34.55A7.69,7.69,0,0,0,27,16.6l-
> 2.08 4z")` String with SVG path notation
> Not included:
> Attributed Strings: I would like to see a way to define attributed
> strings (using some system like CSS/HTML) but could not think up a
> simple representation similar to the others mentioned in the
> preceding table.
> JSON Literals: Again, probably too complex and possibly not worth
> their weight. If they could exist, they'd have to be imported via a
> resource or URL and transformed to a local type.
> Impact on Existing Code
> This proposal is purely additive.
> Alternatives Considered
> Using distinct literal names without subsuming them into a namespaced
> umbrella.
> _
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
 

Links:

  1. http://github.com/erica
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Review] SE-0099: Restructuring Condition Clauses

[Zach Waldowski via swift-evolution]

I have  concerns. Responses inline.
 
Sincerely,
Zachary Waldowski
z...@waldowski.me
 
 
On Fri, May 27, 2016, at 12:11 PM, Joe Groff via swift-evolution wrote:
> • What is your evaluation of the proposal?
 
-1. Neither semicolon-based nor newline-based conditionals strike me as
sufficiently better, and I do not feel it achieves its overall goal of
being easier to read.
 
The ";" did not pass my initial sniff test of readability. Though its
rationale is convincing, I found it difficult to parse a ";"-based
conditional as something being capable of short-circuiting and
binding. I personally would prefer resolving the ambiguities around
the ",", though I cannot speak to the feasibility of that relative to
the compiler.
 
The newline-based version gives me particular heartburn. I do not agree
with the notion that conditional lists and multi-line statements are
long-lost twins. The proposed syntax damages the context-awareness of
an element in a conditional list; conditionals must be read and
executed holistically, but, with the new syntax, an isolated line is
not clearly a part.
 
Consider, for example, a transposition of a few lines; regular
statements enjoy a low rate of accidental behavioral change  without
comparable syntax change (because of optional bindings, guard, etc). My
current project team has a hard time resolving merge conflicts (ironic -
it causes a lot of them too). I don't have to work hard to imagine a
scenario like "goto fail;" with one of these newline-based conditionals,
which would be an unfortunate backslide for Swift.
 
> • Is the problem being addressed significant enough to warrant a
> change to Swift?
 
Yes. The current syntax(es) are often surprising as to what kinds of
checks, bindings, and pattern matches can be achieved in a single
conditional. If one member of a team is more fluent in the available
combinations of Swift conditionals than another, it's not uncommon
for the other member to review code and say, "Wow, are you sure you
can do that?"
 
> • Does this proposal fit well with the feel and direction of Swift?
 
It is strongly in line with Swift's direction to combine many organically-
added syntax variations into a single overarching vision.
 
I have misgivings about a change like this coming to a head so close to
Swift 3's coming-out party.
 
> • If you have used other languages or libraries with a similar
> feature, how do you feel that this proposal compares to those?
 
I haven't seen the semicolon syntax before (except maybe in C-
style for loops), making it a fairly novel and surprising addition
to the language.
 
Both forms of the new syntax give me concerns, but the Pythonic quality
of the newline-based version does in particular.
 
> • How much effort did you put into your review? A glance, a quick
> reading, or an in-depth study?
 
I read through the revised proposal in detail.
 
> _
> 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] Winding down the Swift 3 release

[Zach Waldowski via swift-evolution]

On Thu, May 19, 2016, at 02:33 AM, Jeremy Pereira via swift-evolution
wrote:
> 
> > On 17 May 2016, at 23:45, Eric Wing via swift-evolution 
> >  wrote:
> > 
> > So I don’t mind (too much) if it takes longer to get a stable ABI. It
> > makes my life harder, but on the flip-side, I don’t want to be stuck
> > with yet another broken language and ABI. I want this done right
> > because it will be almost impossible to fix later.
> > 
> > Here’s a simple, yet tragic example: BOOL in Objective-C. We were
> > stuck with signed char instead of getting a real boolean. Back in 10.4
> > Tiger when the Intel migration was announced, I filed a bug report
> > reminding them that this was the chance to fix this. They didn’t fix
> > it, so we were stuck. Then I filed again in the 10.5 beta Leopard time
> > frame during the 64-bit transition, I filed again reminding them that
> > this should be fixed before the 64-bit ABI gets locked down. Again, it
> > wasn’t fixed so we were stuck. Then when the iOS SDK was going to
> > become public, I filed again. Still not fixed. Then armv7, still
> > nothing. Finally, for arm64, this was finally fixed. Too bad we’re
> > stuck on Mac with this probably forever.
> 
> Objective-C had a real boolean type as soon as the compiler was C99
> compatible and that’s when I started using it. BOOL is a typedef that is
> part of the Foundation/Cocoa API, not the Objective-C ABI.
> 
> 
> > 
> > Anyway, I don’t want to deal with another monstrous broken language.
> 
> Objective-C is not broken. It’s a fine language that has served the Apple
> development community for at least 15 years. It has quirks and problems
> but it is fit for purpose. The first binary I compiled in 64 bit mode
> will still run on my current OS X 10.11 laptop. Swift is already vastly
> nicer to program in but if I was a PHB trying to decide whether to invest
> in Swift skills for the future, things like “unstable ABI” and “source
> code breaking changes for Swift 3” would be colouring my opinion now and
> not in a good way.
> 
> I’d rather have a good language that is fit for production than one that
> is promised to be theoretically perfect at some as yet undefined future
> date.

Much like people are expressing relief that the compatibility goals for
the language are not being dictated by specific timelines, I would be
wholly concerned if any of Swift's goals were being defined by winning
the short-term favor of business people.

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

Sincerely,
  Zachary Waldowski
  z...@waldowski.me
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Review] SE-0088: Modernize libdispatch for Swift 3 naming conventions

[Zach Waldowski via swift-evolution]

dispatch_get_context, dispatch_set_context are not around simply in the
absence of blocks. They're just as useful as the queue-specific data
APIs as they have thread-specific storage.
 
Zach Waldowski
z...@waldowski.me
 
 
On Thu, May 12, 2016, at 08:50 PM, Pierre Habouzit via swift-evolution wrote:
>> On May 12, 2016, at 10:49 AM, Jose Cheyo Jimenez via swift-evolution
>>  wrote:
>>
>>
>>> On May 11, 2016, at 7:09 AM, Matt Wright via swift-evolution >> evolut...@swift.org> wrote:
>>>

 On May 10, 2016, at 11:52 PM, Jacob Bandes-Storch via swift-
 evolution  wrote:


 * What is your evaluation of the proposal?

 I'm generally in favor of a modernized API overlay like this (and
 I've written something like it myself, albeit much simpler), but
 I'm hoping this proposal can go through another round or two of
 discussion/bikeshedding/revision before approval.

 (Small note: I'm really happy about the strong-typed-ness of the
 Source subclasses, e.g. how mergeData is only available for
 Add/Or.)

 In no particular order, here are some things on which I'm unclear,
 or not-so-+1:

 - synchronously()'s block parameter should be @noescape. Perhaps
   more arguably, it should have a generic return type and rethrows,
   like autoreleasepool now does.
>>>
>>> Both of these are present in the changes I have for this proposal.
>>> The former point is a mistake in my proposal text, the latter is an
>>> unfortunate oversight on my part in putting together the proposal
>>> document.
>>>
 - The names asynchronously(execute:) and synchronously(execute:)
   don't seem to fit with any API guidelines I'm aware of. Did you
   consider including the verb in the method name?
>>>
>>> We did. Of the number of names that we discussed, none of them were
>>> perfect. sync/async are common in other languages but don’t fit the
>>> general direction of the Swift 3 naming conventions. Using
>>> `dispatchAsynchronously` is an extremely long method name, even more
>>> so than `asynchronously`. `perform` does not capture the sync/async
>>> nature of the calls particularly well, compared to DispatchWorkItem
>>> where `perform` immediately executes the block.
>>>
 (And I'm guessing that "func synchronously(work:...)" is meant to
 be "func synchronously(execute work:...)”?)
>>>
>>> Right.
>>>
 As another bikeshed-item, I'd vote for
 "Data.init(withoutCopying:...)" rather than "(bytesNoCopy:...)",
 and perhaps whenDone() instead of notify().
>>>
>>> Here the init() functions closely mirror Data from Foundation, the
>>> Objective-C class is toll-free bridged to NSData and we desired a
>>> close match to the Foundation Swift API. `notify` is Dispatch-only
>>> API though, I’ll go think over that one.
>>>
 - Are DispatchWorkItemFlags meant to overlay dispatch_block_flags?
   It would be nice to explicitly list these in the proposal.
>>>
>>> The dispatch_block_* API is completely superseded by
>>> DispatchWorkItem in the proposal. DispatchWorkItemFlags is the
>>> equivalent to dispatch_block_flags.
>>>
 - Are functions like dispatch_barrier_sync totally gone in favor of
   passing a .barrier flag? It would be nice to explicitly state
   this in the proposal.
>>>
>>> Yes, you can supply .barrier to either `synchronously` or
>>> `asynchronously`, or create a DispatchWorkItem as a barrier item.
>>> Where possible the multiple variants of a class (dispatch_async,
>>> dispatch_barrier_async, etc) are collapsed into a single method with
>>> default arguments.
>>>
 - I echo Austin's concerns about subclassability. I think it would
   be dangerously misleading if the classes were subclassable from
   user code, even if it didn't work properly.
>>>
>>> Building at compile time will fail. So you wouldn’t get very far
>>> trying to use them, I plan to investigate adding `final` here (it’s
>>> only absent for technical reasons, as the classes originate from
>>> Objective-C).
>>>
 - What of the APIs provided on Semaphore and Group objects? I'd
   like to see these before I vote for the proposal.
>>>
>>> These would be transformed similarly, I will include them when
>>> updating the proposal.
>>>
>>> class DispatchSemaphore : DispatchObject {
>>>
>>> init(value: Int)
>>>
>>> func wait(timeout: DispatchTime = default) -> Int
>>>
>>> func wait(walltime timeout: DispatchWalltime) -> Int
>>>
>>> func signal() -> Int
>>>
>>> }
>>>
>>> class DispatchGroup : DispatchObject {
>>>
>>> init()
>>>
>>> func wait(timeout: DispatchTime = default) -> Int
>>>
>>> func wait(walltime timeout: DispatchWalltime) -> Int
>>>
>>> func notify(queue: DispatchQueue, block: () -> Void)
>>>
>>> func enter()
>>>
>>> func leave()
>>>
>>> }
>>>
>>>
 - What will dispatch_set_target_queue's replacement look like look
   like?
>>>
>>> extension DispatchObject {
>>>
>>> func 

Re: [swift-evolution] Standard library 'Data' type pre-proposal

[Zach Waldowski via swift-evolution]

On Wed, May 11, 2016, at 11:38 AM, Austin Zheng via swift-evolution wrote:
> One question that this brings up is whether supporting non-contiguous
> data regions in a native Swift data type is worth the complexity
> costs. There are good reasons for dispatch_data_t to be implemented
> the way it is, but NSData has always assumed that it is modeling a
> contiguous area in memory, and it provides users with raw access to
> the underlying buffer. A cursory examination of a few other languages
> (Java, Python, Haskell) show that these languages all model binary
> data as some sort of contiguous array-like construct containing bytes.
 
I do not find this convincing.
 
NSData has not "always assumed" this; that it is transparently bridged
with dispatch_data_t on Darwin contradicts that directly.
 
It would be prohibitive on efficiency to have to use the lowest-common-
denominator of contiguous bytes to be useful in Swift. XPC and
NSURLSession, among others, both use dispatch_data_t via NSData to
efficiently push large buffers across process boundaries.
 
That there are complexities involved should not be reason to not address
them. It's 2016 and we don't always deal with buffers of a conveniently
small size, just like we don't deal with Strings that are conveniently
UTF-8. If sufficiently small buffers are the only thing being addressed
for ease, then I don't find the described API that much more valuable
than [UInt8] and UnsafeBufferPointer.
 
Another language having represented it a certain way does not make it
foregone how Swift must do it. Other languages also lack value types,
Unicode-correct strings, or memory safety. Swift is living proof that
doing things the way C or Java did is not the automatic solution.
 
Zachary Waldowski
z...@waldowski.me
 
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] NSRange and Range

[Zach Waldowski via swift-evolution]

That makes sense. However, wouldn't this still be workable in terms
of bridging? If UTF16Index had an alternate representation for Swift-
side UTF-8 storage, that wouldn't ever come up for roundtripping
across the bridge. The offsets that come back from Foundation would
always be "UTF-16 indices how NSString understands it", which Swift
would necessarily understand because it implements -characterAtIndex:
for the bridge wrapper.
 
Zach
 
On Wed, May 11, 2016, at 01:19 PM, Jordan Rose wrote:
> I’m not sure we’re going to stick to that in the future. It’s possible
> we’ll want String to support UTF-8 buffers as well.
>
> Jordan
>
>
>> On May 11, 2016, at 10:15, Zach Waldowski <z...@waldowski.me> wrote:
>>
>> Conceptually, yes, but is that not exactly how it is implemented?
>> https://github.com/apple/swift/blob/master/stdlib/public/core/StringUTF16.swift#L24
>>
>> Sincerely,
>> Zachary Waldowski
>> z...@waldowski.me
>>
>>
>> On Wed, May 11, 2016, at 01:13 PM, Jordan Rose wrote:
>>> That’s correct, but how would you *make* the String.UTF16Index
>>> values without the reference String? They’re not (guaranteed to be)
>>> integers.
>>>
>>> Jordan
>>>
>>>
>>>> On May 10, 2016, at 16:04, Zach Waldowski <z...@waldowski.me>
>>>> wrote:
>>>>
>>>> Right, I 100% get it. :) This is a difficult problem space, and I'm
>>>> sure you folks are aware that that difficulty is also reflected in
>>>> how brutal it is to use all of these derivative string-range-based
>>>> things in Swift right now. In this case, having no answer to this
>>>> problem is worse than not having the API at all — check Stack
>>>> Overflow or GitHub for how often a "just paste this in"
>>>> String.Index.init(_: Int) comes up.
>>>>
>>>> As far as NSTextCheckingResult goes, its ranges are always in the
>>>> "indices" always in the space of the original string… do I have
>>>> that right? So it would be programmer error to use those ranges in
>>>> the wrong string just like it is with any Range
>>>> today.
>>>>
>>>> Zach Waldowski
>>>>
>>>>
>>>> On Tue, May 10, 2016, at 06:51 PM, Jordan Rose wrote:
>>>>> By the way, this doesn’t mean it can’t be done, or that we can’t
>>>>> decide on some kind of partial solution! It just means that it
>>>>> needs to be carefully considered and explicitly addressed.
>>>>>
>>>>> Jordan
>>>>>
>>>>>
>>>>>> On May 10, 2016, at 15:49, Jordan Rose <jordan_r...@apple.com>
>>>>>> wrote:
>>>>>>
>>>>>> We thought about that too. The problem is that it’s not always
>>>>>> obvious what NSString or NSAttributedString the indexes refer to.
>>>>>> For example, most of the NSRegularExpression APIs produce matches
>>>>>> in the form of NSTextCheckingResult, which then doesn’t have a
>>>>>> reference to the original string.
>>>>>>
>>>>>> Jordan
>>>>>>
>>>>>>
>>>>>>> On May 10, 2016, at 13:43, Zach Waldowski via swift-evolution
>>>>>>> <swift-evolution@swift.org> wrote:
>>>>>>>
>>>>>>> Would it be feasible to annotate those and have them
>>>>>>> appropriately converted to Range upon
>>>>>>> crossing the bridge? Thinking in particular of TextKit and
>>>>>>> friends — it'd away with quite a lot of the pain of, e.g., not
>>>>>>> having a native struct-y AttributedString.
>>>>>>>
>>>>>>> Cheers!
>>>>>>> Zachary Waldowski
>>>>>>> z...@waldowski.me
>>>>>>>
>>>>>>>
>>>>>>> On Tue, May 10, 2016, at 12:37 PM, Jordan Rose via swift-
>>>>>>> evolution wrote:
>>>>>>>> One particular concern we've had is that many NSRanges aren’t
>>>>>>>> Range; they’re Range. I suppose things
>>>>>>>> wouldn’t get any *worse* there, though.
>>>>>>>>
>>>>>>>> Jordan
>>>>>>>>
>>>>>>>>
>>>>>>>>> On May 10, 2016, at 00:14, David Hart via swift-evolution >>>>>>>> evo

Re: [swift-evolution] [Review] SE-0088: Modernize libdispatch for Swift 3 naming conventions

[Zach Waldowski via swift-evolution]

I don't recall seeing this proposal being pitched, and will also include
feedback of that stripe. Other responses inline.

On Wed, May 11, 2016, at 12:39 AM, Chris Lattner via swift-evolution
wrote:
>   * What is your evaluation of the proposal?

Strong +1 in concept. I'm thrilled that this might happen.

+0 in current implementation. The proposal as written does not fully
conform to Swift API standards and does not fully address the current
surface area of the Dispatch API. I am concerned about losing features
and performance in our haste to make something "more Swifty."

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

GCD's lack of integration with Swift — in part from the contusions the
API performs to be compatible with multiple languages at the API level

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

See other feedback below. Making changes in general is very much a good
idea. The APIs described do not always fit with Swift.

Separate from the APIs described herein, I am curious as to how much of
what needs to be done can or should be accomplished with apinotes and
the auditing facilities from SE-0044; it seems like 

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

With additions, the resulting API would be a nice improvement and go a
long way to making Swift feel like it has high-level multithreading
support.

>   * How much effort did you put into your review? A glance, a quick 
> reading, or an in-depth study?

In-depth study. I am an aggressive user of GCD in Swift.

---

## Type Naming and Structures

The namespace of GCD is already "Dispatch". The existing types in the
proposal are translating from snake-case to camel-case; this isn't
wholly necessary to me as Swift doesn't suffer from C's global
namespace.

dispatch_object_t is obviously a problem in this respect, but its use is
already fuzzy in current GCD (incl. in other languages; its use in C is
equally sketchy). I almost feel like the features of dispatch_object_t
should be encapsulated in protocols. (resume, cancel, etc.)

## Missing API

- Group, IO, and Semaphore are missing in their entirety.
- Data needs init() to match the dispatch_data_empty constant.
- There's no equivalent to dispatch_data_copy_region(3), which can be
used to step through the contiguous buffers (among other things).
- The shared functionality of dispatch_get_context(1),
dispatch_set_context(2), and dispatch_set_finalizer_f(2) are not
modeled.
- The shared functionality of dispatch_suspend(2) and dispatch_resume(2)
are not modeled.
- Queue has no getters for its label and QoS class.
- Queues do not have any modeling for their target queue.
- Custom queues cannot be created.
- dispatch_barrier_sync(2) is not represented. (Neither is
dispatch_barrier_async(2), but this is modeled by
DispatchWorkItemFlags.)
- No equivalents for dispatch_apply(3), dispatch_main(),
dispatch_after(3).

## API comments

- WorkItem
   * DispatchQueue.asynchronously(_:qos:flags:work:) should have a
   variant that takes a DispatchWorkItem. With the API as written, you
   could not enqueue a work item then cancel it.
   * Flags should be a nested type.

- Source
   * The details section needs examples of at least one of the
   DispatchSource protocols (i.e., DispatchSourceFileSystemObject). The
   current approach would seem to lose API inherited from DispatchSource
   and DispatchObject unless those are modeled in some other way.
   * None of Source's APIs for assigning handlers, configuring timers,
   getting or merging the user-defined data, or cancelling are exposed.

- Data
   * Overall, the API does not encapsulate dispatch_data_t's status as a
   tree of discontiguous buffers. I'd expect at least to have API to
   have a view of the contiguous buffers, for instance.
   * The alternate forms of append(_:) don't address management of the
   appended buffer's memory. Do they copy?
   * What are the COW semantics? In-place mutation is not thread-safe,
   whereas dispatch_data_t's current concatenation mechanisms are.
   * enumerateBytes(_:) is unclear, as it is enumerating the underlying
   byte buffers.

- Queue
   * Queue.asynchronously(group:qos:flags:work:) and
   Queue.synchronously(_:) does not conform to the API guidelines.
   * Queue.synchronously(_:) should be @noescape. If possible,
   rethrowing and returning a  would be optimal.

Sincerely,
  Zachary Waldowski
  z...@waldowski.me
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] NSRange and Range

[Zach Waldowski via swift-evolution]

Right, I 100% get it. :) This is a difficult problem space, and I'm sure
you folks are aware that that difficulty is also reflected in how brutal
it is to use all of these derivative string-range-based things in Swift
right now. In this case, having no answer to this problem is worse than
not having the API at all — check Stack Overflow or GitHub for how often
a "just paste this in" String.Index.init(_: Int) comes up.
 
As far as NSTextCheckingResult goes, its ranges are always in the
"indices" always in the space of the original string… do I have that
right? So it would be programmer error to use those ranges in the wrong
string just like it is with any Range today.
 
Zach Waldowski
 
 
On Tue, May 10, 2016, at 06:51 PM, Jordan Rose wrote:
> By the way, this doesn’t mean it can’t be done, or that we can’t
> decide on some kind of partial solution! It just means that it needs
> to be carefully considered and explicitly addressed.
>
> Jordan
>
>
>> On May 10, 2016, at 15:49, Jordan Rose <jordan_r...@apple.com> wrote:
>>
>> We thought about that too. The problem is that it’s not always
>> obvious what NSString or NSAttributedString the indexes refer to. For
>> example, most of the NSRegularExpression APIs produce matches in the
>> form of NSTextCheckingResult, which then doesn’t have a reference to
>> the original string.
>>
>> Jordan
>>
>>
>>> On May 10, 2016, at 13:43, Zach Waldowski via swift-evolution >> evolut...@swift.org> wrote:
>>>
>>> Would it be feasible to annotate those and have them appropriately
>>> converted to Range upon crossing the bridge?
>>> Thinking in particular of TextKit and friends — it'd away with quite
>>> a lot of the pain of, e.g., not having a native struct-y
>>> AttributedString.
>>>
>>> Cheers!
>>> Zachary Waldowski
>>> z...@waldowski.me
>>>
>>>
>>> On Tue, May 10, 2016, at 12:37 PM, Jordan Rose via swift-evolution
>>> wrote:
>>>> One particular concern we've had is that many NSRanges aren’t
>>>> Range; they’re Range. I suppose things
>>>> wouldn’t get any *worse* there, though.
>>>>
>>>> Jordan
>>>>
>>>>
>>>>> On May 10, 2016, at 00:14, David Hart via swift-evolution >>>> evolut...@swift.org> wrote:
>>>>>
>>>>> But it’s reasonably implementable? I guess the answer is yes if
>>>>> you have already faced the same bridging concerns with
>>>>> NSArray/Array. I’de really like this going forward, but I don’t
>>>>> know how confident I am in writing a proposal.
>>>>>
>>>>>> On 10 May 2016, at 08:29, Douglas Gregor <dgre...@apple.com>
>>>>>> wrote:
>>>>>>
>>>>>>
>>>>>>> On May 9, 2016, at 11:23 PM, David Hart <da...@hartbit.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>> Why wouldn't it completely eliminate NSRange?
>>>>>>
>>>>>> Because NSRange has a different representation than Range
>>>>>> (start+length vs. start/end), a pointer-to-NSRange has to come in
>>>>>> as Unsafe(Mutable)Pointer rather than
>>>>>> Unsafe(Mutable)Pointer<Range>. It’s the same reason that
>>>>>> (e.g.), an NSArray** parameter comes in as
>>>>>> UnsafeMutablePointer rather than
>>>>>> UnsafeMutablePointer<[AnyObject]>.
>>>>>>
>>>>>>> Are you thinking of NSNotFound? Could we migrate those APIs to
>>>>>>> return an Optional Range?
>>>>>>
>>>>>> If you had annotations on the APIs to say that they use
>>>>>> NSNotFound as a sentinel, yes.
>>>>>>
>>>>>> - Doug
>>>>>>
>>>>>>>
>>>>>>>> On 10 May 2016, at 05:49, Douglas Gregor <dgre...@apple.com>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>>> On May 8, 2016, at 2:10 PM, David Hart via swift-evolution >>>>>>>> evolut...@swift.org> wrote:
>>>>>>>>>
>>>>>>>>> Hello Swift-Evolution,
>>>>>>>>>
>>>>>>>>> I spent some time coding on Linux with Swift 3 (latest
>>>>>>>>> developement snapshot) and corelibs-foundation a

Re: [swift-evolution] NSRange and Range

[Zach Waldowski via swift-evolution]

Would it be feasible to annotate those and have them appropriately
converted to Range upon crossing the bridge? Thinking
in particular of TextKit and friends — it'd away with quite a lot of the
pain of, e.g., not having a native struct-y AttributedString.
 
Cheers!
Zachary Waldowski
z...@waldowski.me
 
 
On Tue, May 10, 2016, at 12:37 PM, Jordan Rose via swift-evolution wrote:
> One particular concern we've had is that many NSRanges aren’t
> Range; they’re Range. I suppose things
> wouldn’t get any *worse* there, though.
>
> Jordan
>
>
>> On May 10, 2016, at 00:14, David Hart via swift-evolution > evolut...@swift.org> wrote:
>>
>> But it’s reasonably implementable? I guess the answer is yes if you
>> have already faced the same bridging concerns with NSArray/Array.
>> I’de really like this going forward, but I don’t know how confident I
>> am in writing a proposal.
>>
>>> On 10 May 2016, at 08:29, Douglas Gregor  wrote:
>>>
>>>
 On May 9, 2016, at 11:23 PM, David Hart  wrote:

 Why wouldn't it completely eliminate NSRange?
>>>
>>> Because NSRange has a different representation than Range
>>> (start+length vs. start/end), a pointer-to-NSRange has to come in as
>>> Unsafe(Mutable)Pointer rather than
>>> Unsafe(Mutable)Pointer. It’s the same reason that
>>> (e.g.), an NSArray** parameter comes in as
>>> UnsafeMutablePointer rather than
>>> UnsafeMutablePointer<[AnyObject]>.
>>>
 Are you thinking of NSNotFound? Could we migrate those APIs to
 return an Optional Range?
>>>
>>> If you had annotations on the APIs to say that they use NSNotFound
>>> as a sentinel, yes.
>>>
>>>  - Doug
>>>

> On 10 May 2016, at 05:49, Douglas Gregor 
> wrote:
>
>
>> On May 8, 2016, at 2:10 PM, David Hart via swift-evolution > evolut...@swift.org> wrote:
>>
>> Hello Swift-Evolution,
>>
>> I spent some time coding on Linux with Swift 3 (latest
>> developement snapshot) and corelibs-foundation and I’ve hit one
>> major hurdle: passing and converting NSRange and Range around
>> between the different stdlib and Foundation APIs - specifically
>> in regards to String.
>>
>> Is there a plan to simplify those pain points by converting all
>> corelibs-foundation APIs to accept/return Range on String instead
>> of NSRange? In that case, can’t we get rid of NSRange completely?
>
>
> One idea that had come up before was to bridge NSRange to
> Range, although it wouldn’t completely eliminate NSRange
> because the two types are not representationally identical.
>
>  - Doug
>

>>>
>>
>> ___
>> 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] [Accepted] SE-0072: Fully eliminate implicit bridging conversions from Swift

[Zach Waldowski via swift-evolution]

On Fri, May 6, 2016, at 11:20 PM, Charles Srstka via swift-evolution wrote:
> let int = num as? Int // 5
> let float = num as? Float // 5
> let int32 = num as? Int32 // nil!
That specific behavior with Int32 seems to be an oversight in the
stdlib. The specific integer types don't get an ObjectiveCBridgeable
implementation.
 
Sincerely,
Zachary Waldowski
z...@waldowski.me
 
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Review] SE-0070: Make Optional Requirements Objective-C only

[Zach Waldowski via swift-evolution]

Perhaps, with this thought in mind, we should consider making @objc into
something more resembling the @available syntax. Getter selector, setter
selector, copying, etc. could live there as well.

Sincerely,
  Zachary Waldowski
  z...@waldowski.me

On Tue, Apr 26, 2016, at 01:15 AM, Brent Royal-Gordon via
swift-evolution wrote:
> > * What is your evaluation of the proposal?
> 
> I think this proposed solution doesn't really address the problem. An
> @objcOptional keyword is intended to make it clear that the feature is
> fundamentally, intrinsically, for Objective-C compatibility. Separating
> the keywords doesn't do that; it still seems like an arbitrary and
> temporary limitation.
> 
> @objcOptional *does* make it clear that this is a compatibility feature.
> So would @objc(optional), although that would conflict with the
> @objc(selectorGoesHere) syntax.
> 
> > * Is the problem being addressed significant enough to warrant a change 
> > to Swift?
> 
> Yes.
> 
> > * Does this proposal fit well with the feel and direction of Swift?
> 
> I think it's neutral to the direction of Swift.
> 
> > * If you have you used other languages or libraries with a similar 
> > feature, how do you feel that this proposal compares to those?
> 
> N/A.
> 
> > * How much effort did you put into your review? A glance, a quick 
> > reading, or an in-depth study?
> 
> Participated in the previous discussion, read this one pretty quickly.
> 
> -- 
> Brent Royal-Gordon
> Architechies
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Idea] How to eliminate 'optional' protocol requirements

[Zach Waldowski via swift-evolution]

Table view semantics were discussed at length on a prior version of the
thread. That pattern is less than ideal; it essentially creates magic
behavior that's only described by documentation… or, worse, completely
forgotten about in documentation; something changing from version to
version of the framework; etc. I can not tell you how many times this
has tripped up members of my teams. Over in Cocoa proper, similar
behavior changes also arise (usually performance optimizations) from
whether or not you *override* a method, and it's even more confusing.
 
Such a practice should not be a cornerstone of a modern language; as
discussed in the prior thread, the different semantics of the measuring
methods (the current return values, as well as the implicit one from not
overriding) should be captured explicitly in an enum, with a clear
default return value. This is in line with the spirit of Swift. Your API
contract with the user is clear, and the introduction of default
implementations is versioned as a matter of public API.
 
It's interesting that you use the phrase "customization points". Our
text for teaching protocol extensions in Swift uses it heavily - that
*is* the behavior of protocols with default implementations in Swift
today. You delegate something out, but give it a default implementation
with logic you specify. That's a customization point, too.
 
Cheers!
Zachary Waldowski
z...@waldowski.me
 
 
On Fri, Apr 8, 2016, at 08:47 AM, Jonathan Hull via swift-evolution wrote:
> Interesting proposal, but I wanted to mention a couple of potential
> issues off the top of my head.  I know when I was using optional
> requirements in Objective C, I would often use the presence/lack of
> the method (not just whether it returned nil) in the logic of my
> program.  I used the presence of a method as a way for the implementor
> of a delegate to naturally communicate whether they wanted a more
> advanced feature.  The absence of the method itself is information
> which can be utilized, not just whether it returns nil, and I believe
> that is part of what people are asking for when they say they want
> optional methods in Swift.
>
>
> Let me try to give a simplified example which I am not sure how you
> would work around in this proposal:
>
> Let’s say there is a datasource protocol which optionally asks for an
> image associated with a particular piece of data (imagine a table or
> collection view type custom control).  If the method is not
> implemented in the data source, then a different view is shown for
> each data point that doesn’t have a place for images at all.  If the
> method is implemented, but returns nil, then a default image is used
> as a placeholder instead (in a view which has a place for images).
>
> tl;dr: Optional methods are often used as customization points,
> and the methods, if implemented, may also have another meaning/use
> for nil.
>
>
> Similarly, a different back-end implementation may be used in the case
> where an optional method is not implemented.  Let’s say you have
> something like a tableview with an optional method giving rowHeights.
> If that method is unimplemented, it is possible to have a much more
> efficient layout algorithm… and in some cases, you may check for the
> existence of the optional method when the delegate is set, and swap
> out a different layout object based on which customizations are needed
> (and again nil might mean that a height/etc... should be automatically
> calculated).  This is the ability I miss the most.
>
>
> Not saying the proposal is unworkable, just wanted to add some food
> for thought.  I know I really miss optional methods in Swift.  In some
> areas Swift is a lot more powerful, but there are lots of things I
> used to do in Obj C that I haven’t figured out how to do in Swift yet
> (if they are even possible).  I am kind of disturbed by the
> trend/desire to get rid of the smalltalk-ness, as opposed to finding
> new and safer ways to support that flexibility/expressiveness.  I
> would really like to see swift deliver on it’s promise of being a more
> modern alternative to ObjC (which it isn’t yet, IMHO) instead of just
> a more modern alternative to C++/Java.
>
> Thanks,
> Jon
>
>> Proposed Solution: Caller-side default implementations  Default
>> implementations and optional requirements differ most on the caller
>> side. For example, let’s use NSTableView delegate as it’s imported
>> today:  func useDelegate(delegate: NSTableViewDelegate) { if let
>> getView = delegate.tableView(_:viewFor:row:) { // since the
>> requirement is optional, a reference to the method produces a value
>> of optional function type // I can call getView here }  if let
>> getHeight = delegate.tableView(_:heightOfRow:) { // I can call
>> getHeight here } }  With my proposal, we’d have some compiler-
>> synthesized attribute (let’s call it
>> @__caller_default_implementation) that gets places on Objective-C
>> optional requirements when they get imported, e.g.,  

Re: [swift-evolution] A shortcut for weakly referencing functions

[Zach Waldowski via swift-evolution]

Responses inline!

Sincerely,
  Zachary Waldowski
  z...@waldowski.me

On Fri, Apr 1, 2016, at 11:09 AM, Radosław Pietruszewski via
swift-evolution wrote:
> Here’s a pattern I find myself doing quite often:
> 
>   1> class Child {
>   2. var onSomeEvent: () -> Void = { }
>   3. }
>   4> class Parent {
>   5. let child = Child()
>   6. init() {
>   7. child.onSomeEvent = doSomething
>   8. }
>   9. func doSomething() {
>  10. }
>  11. }
> 
> I have some ownership hierarchy of classes (often controllers — view
> controllers — views), where I pass information from children up to
> parents using closures set by the parent.
> 
> I like this pattern because children classes don’t have to be tied to
> knowledge about their parents, and I don’t have to define delegate
> protocols. It’s very clean, and also very easy to set up.
> 
> The only problem is that there’s a strong danger of introducing reference
> cycles.
> 
> With class properties, you can quite easily see the potential for a
> reference cycle and mark references to parents with weak/unowned. And
> with `self` captures in closures, you’re reminded of memory management by
> having to be explicit about `self`. But when passing references from
> parents to children, there’s no way to mark the closure property as
> `weak` (and there’s no reminder of the danger).

I will go ahead and note, at least in terms of writing the proposal, I
don't find this argument very strong. The proposed syntax still requires
you to know about the cycles involved.

> 
> * * *
> 
> Right now, every time I pass a closure down to children, I have to wrap
> my references like so:
> 
>   { [unowned self] self.doSomething($0) }
> 
> instead of a neat and simple function reference:
> 
>   doSomething
> 
> I think it would be useful to have a shortcut syntax for creating weak
> and unowned references to functions, like so:
> 
>   @unowned(doSomething)
> 
> or perhaps:
> 
>   #unowned(self.doSomething)
> 
> * * *

I really like the #unowned syntax! It's expressive and in line with
other pieces of Swift sugar. Would +1 if it came to a proposal!

The @ version doesn't make as much sense as it's not an attribute.

> 
> An alternative would be the ability to mark closure properties as weak or
> unowned. Then I could, at the *child* level, say:
> 
>   unowned let onSomeEvent: () -> Void

I don't particularly think it makes sense, because it is prescriptive.
If some other user in your codebase wanted the cycle, they couldn't get
it. Plus, what would it mean when the closure isn't capturing anything?

> 
> * * *
> 
> Does this make sense? What do you think?
> 
> — Radek
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Review] SE-0057: Importing Objective-C Lightweight Generics

[Zach Waldowski via swift-evolution]

Responses inline!

Sincerely,
  Zachary Waldowski
  z...@waldowski.me

On Thu, Mar 31, 2016, at 02:11 PM, Chris Lattner via swift-evolution
wrote:
>   * What is your evaluation of the proposal?

The strongest of +1's. It will allow much greater flexibility for the
bridge, both in our own code and Apple's frameworks.

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

Yes. Like SE-0055, it's mildly ironic that these new features can
occasionally be more expressive or compiler-checked by Clang than by
Swift.

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

At the high-level, absolutely. More generics = safer and smarter code.

At the lower-level, I'm somewhat concerned about the mismatch between
the Swift side of lightweight generics vs. honest-to-god Swift generics.
As an instructor, I worry that the limitations may make learning
generics even more hairy. Considering "Restrictions on uses of
Objective-C parameterized classes" (while all the restrictions
completely make sense), I wonder how difficult it'll be to explain why
in a given specific instance (i.e., pulling a value out of a [String:
AnyObject]) can't be casted.

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

I've used type-erased generics before in other languages. While not
preferable when you have something like Swift's implementation, this is
acceptable for a bridge.

>   * How much effort did you put into your review? A glance, a quick 
> reading, or an in-depth study?

I've been considering the effects of this feature since bridging came to
ObjC, really excited to see it. Quick glance at the proposal itself.

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

A couple of questions, since this proposal hasn't had the regular
Evolution run-through:

1. The section "Importing unspecialized types" makes reference to
defaulting to the unbound requirement when something isn't annotated in
Objective-C. This is notably something that isn't true in Swift at
present (i.e., a T: ErrorType can't be satisfied by ErrorType). Would
this be a change that comes generalized to Swift, or is just true of the
lightweight generics bridge.

2. How undefined is the undefined behavior in things coming from
Objective-C? If something is exposed into Swift as one type bounds, but
for legacy or bug reasons, another class is pushed across the bridge,
precisely what color will the resulting explosion be at runtime?

3. Re: "Opting in to type argument discovery", how would initialization
look for GKComponentSystem? Having to do
GKComponentSystem(componentClass: SomeType.self) would be
pretty onerous. Would this have to be treated in the overlay framework
too as well?

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