I missed that sorry.
I think it will find other uses and therefore should be ValueEnumerable.
-- Howard.
> On 11 Jan 2018, at 6:36 pm, Paul Cantrell wrote:
>
>> On Jan 11, 2018, at 7:28 PM, Howard Lovatt wrote:
>>
>> I am in favour of a protocol that you have to explicitly declare, it feels
Well if you are happy to say removal of a case isn’t allowed, why not be
symmetrical and say adding isn’t allowed and if an API would like to add cases
then it needs to do so via adding an extended enum, e.g.:
enum Old {
case old1, old2
}
enum New {
case old1 // Note
I am in favour of a protocol that you have to explicitly declare, it feels much
more like Swift to me. For example you have to say Equatable explicitly.
As a contra example in Java it feels natural that the compiler just provides
the functionality because that is consistent across the language,
an enum case that you're
> trying to add.
>
> Jordan
>
>
>> On Jan 10, 2018, at 16:34, Howard Lovatt via swift-evolution
>> wrote:
>>
>> If an enum isn’t final; then what’s the difference in deleting as opposed to
>> adding
If an enum isn’t final; then what’s the difference in deleting as opposed to
adding?
-- Howard.
> On 10 Jan 2018, at 4:13 pm, Jean-Daniel wrote:
>
>
>
>> Le 10 janv. 2018 à 23:58, Howard Lovatt via swift-evolution
>> a écrit :
>>
>> Two points:
&g
Great news.
Thanks for putting the effort in.
-- Howard.
> On 10 Jan 2018, at 1:27 pm, Charles Srstka via swift-evolution
> wrote:
>
> :thumbsup:
>
> Charles
>
>> On Jan 10, 2018, at 2:22 PM, Nicole Jacque via swift-users
>> wrote:
>>
>> Hi All-
>>
>> First of all, a big thank you to e
Two points:
1. I like Chris’s suggestion of #unknown and in particular that it is distinct
from default.
2. All the discussion is about a framework adding a case, what about when a
framework deletes a case?
-- Howard.
> On 10 Jan 2018, at 1:41 pm, Dave DeLong via swift-evolution
> wrote:
>
Despite having suggested the @version syntax I do agree with people that have
said any @annotation is both a burden on the programmer and severely reduces
readability.
Therefore a 4th option, carrying on from the numbering in my previous email is:
4. The compiler issues a description of the
I am not convinced by these arguments, they seem to be a ‘poor man’s’
versioning system. For example consider:
// In module.
public enum E {
case A, B, C
}
// In application.
switch e {
case A: a()
default: d()
unknown case: u()
}
When e == B or C i
I would say yes they are different for the example. Definitely something I miss
is nesting types to given a seperate namespace.
-- Howard.
> On 24 Dec 2017, at 9:56 pm, Slava Pestov via swift-evolution
> wrote:
>
> There was a proposal to allow protocols to be nested inside types at one
>
pm, Slava Pestov wrote:
>
>
>
>> On Dec 24, 2017, at 3:04 PM, Howard Lovatt via swift-evolution
>> wrote:
>>
>> Proposal link:
>> https://github.com/apple/swift-evolution/blob/https://github.com/apple/swift-evolution/blob/master/proposals/0193-cross-m
Proposal link:
https://github.com/apple/swift-evolution/blob/master/proposals/0193-cross-module-inlining-and-specialization.md
What is your evaluation of the proposal?
-1
The proposal puts all the emphasis on the programmer. It is better for the
compiler to decide if something is to be inclined
alternatives
section, and people are still raising the point; it is probably safe to assume
that the argument hasn’t carried the day and should be revisited.
-- Howard.
> On 19 Dec 2017, at 6:44 pm, Xiaodi Wu wrote:
>
>> On Tue, Dec 19, 2017 at 11:15 PM, Howard Lovatt via swi
As an aside: there seems to be increasingly comments about proposals that say:
1. This was discussed at the evaluation stage and rejected.
2. This is how it is implemented in the patch.
And other comments along those lines. Neither the pre-proposal discussions nor
the proposed implementatio
Howard.
>>
>>> On 16 Dec 2017, at 7:08 am, Tony Allevato wrote:
>>>
>>>
>>>
>>>> On Fri, Dec 15, 2017 at 11:39 AM Howard Lovatt via swift-evolution
>>>> wrote:
>>>> +1
>>>> I think the simple solution of if
ome.
>>
>> TJ
>>
>>> On Fri, Dec 15, 2017 at 12:08 PM, Tony Allevato via swift-evolution
>>> wrote:
>>>
>>>
>>>> On Fri, Dec 15, 2017 at 11:39 AM Howard Lovatt via swift-evolution
>>>> wrote:
>>>> +1
>>&
I think that is an advanced use, rather than a common use. I would prefer that
to be something you manually code.
-- Howard.
> On 16 Dec 2017, at 7:08 am, Tony Allevato wrote:
>
>
>
>> On Fri, Dec 15, 2017 at 11:39 AM Howard Lovatt via swift-evolution
>> wro
+1
I think the simple solution of if you provide either == or hashValue you have
to provide both is the best approach. Good catch of this bug.
-- Howard.
> On 16 Dec 2017, at 6:24 am, Daniel Duan via swift-evolution
> wrote:
>
> +1. The proposal wasn’t explicit enough to have either supporte
To me the short syntax should be a ‘macro’ expansion (syntax sugar only),
therefore option 1 in Nick’s example. I choose the syntax sugar option because
it is easy to explain.
-- Howard.
> On 12 Dec 2017, at 7:03 pm, Nick Keets via swift-evolution
> wrote:
>
>
>
>> On Tue, Dec 12, 2017 a
+1 for Thorsten’s `dynamic` and `dynamic?`.
-- Howard.
> On 6 Dec 2017, at 6:13 am, Thorsten Seitz via swift-evolution
> wrote:
>
>
>>> Am 03.12.2017 um 20:04 schrieb Magnus Ahltorp via swift-evolution
>>> :
>>>
>>> 4 Dec. 2017 02:40 Chris Lattner via swift-evolution
>>> wrote:
>>>
>>>
ote:
>
>> On Sat, Dec 2, 2017 at 2:30 PM, Howard Lovatt via swift-evolution
>> wrote:
>> Definitely in favour of doing something, I always define the associated
>> types since I have had so much trouble with the inference.
>>
>> Personally I would prefer just 1 a
Definitely in favour of doing something, I always define the associated types
since I have had so much trouble with the inference.
Personally I would prefer just 1 and 2 and forget 3. I know this would break a
lot of code, but I think we should do that because it is the lesser of the
evils.
You could even restrict to the same file, like extension access to private.
-- Howard.
> On 26 Nov 2017, at 9:44 am, Tony Allevato via swift-evolution
> wrote:
>
>> On Sat, Nov 25, 2017 at 2:35 PM Xiaodi Wu wrote:
>>> On Sat, Nov 25, 2017 at 4:25 PM, Tony Allevato
>>> wrote:
>>
On Sa
Really like Tony’s suggestion, much cleaner than yet another annotation rammed
into the signature. Also the idea of a static factory that could accept
previously initialized arguments would be very powerful.
-- Howard.
> On 26 Nov 2017, at 9:25 am, Tony Allevato via swift-evolution
> wrote:
You don't necessarily need variadic generics to enable tuples to be nominal
types. Though you do need some changes to the generic type system. One
possibility is:
struct Tuple_0_Int_1_Int: Collection /*where T0: T, T1: T*/
{ // Mangle name. Need covariant generics to enable constraint of T0 and T1
I would defend turning tuples into structs (change from structural type to
nominal type). This is a much better story for programmers, compare the two
stories:
1. Tuples are just syntax sugar for simple structs.
2. Tuples are sort of like structs but there is a list of things tuples
can d
In Scala they just define Tuple1, Tuple2, ... up to 22 (I think).
Eliminates the need for variadic generics and works fine in practice in Scala.
In Swift this approach is possibly unacceptable, since having to write:
extension Tuple1 ...
extension Tuple2 ...
...
extension Tuple2
t the name needs to be canonical.
> This would be similar to local functions at present and would be useful
> (though I am not sure how many local *generic* functions there are).
>
>
>
> -- Howard.
>
> On 17 November 2017 at 10:47, Slava Pestov wrote:
>
>>
>&g
Sorry I don't get the code. In particular:
// Compiler View - of a Constant Property on a Concurrent type
struct Person: Concurrent {
/* Variable Property */
// Constant Property
let birthday: Date {
get {
internalQueue.async { // Immediately returns on calling thr
out the name needs to be canonical.
This would be similar to local functions at present and would be useful
(though I am not sure how many local *generic* functions there are).
-- Howard.
On 17 November 2017 at 10:47, Slava Pestov wrote:
>
>
> On Nov 16, 2017, at 3:07 PM, Howard Lovat
t;
> swift-evolution@swift.org>のメール:
>
>
>
> Sent from my iPhone
>
> On Nov 14, 2017, at 6:56 PM, Howard Lovatt via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> Having read all the arguments for what to add to local functions it still
> strike
rently does for functions).
These are not show stoppers, it is what the compiler already does for
functions.
Will respond to generics comments in reply to Robert Widmann email.
-- Howard.
On 15 November 2017 at 17:01, Slava Pestov wrote:
>
>
> On Nov 14, 2017, at 6:56 PM, How
17 at 14:02, Matthew Johnson
wrote:
>
>
> Sent from my iPhone
>
> On Nov 14, 2017, at 6:56 PM, Howard Lovatt via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> Having read all the arguments for what to add to local functions it still
> strikes me as a p
The proposal is available here:
https://github.com/apple/swift-evolution/blob/master/
proposals/0189-restrict-cross-module-struct-initializers.md
-
What is your evaluation of the proposal?
+1, more an oversight in the original design rather than a change. Funny
how this problem was caug
Having read all the arguments for what to add to local functions it still
strikes me as a poor use of engineering resources to fix them (though I do
agree they have problems). A better use of resources would be:
1. Deprecate local functions.
2. Allow closures when assigned to a function type t
In Java you can have annotation processors, user supplied compiler extensions,
that are extensively used for making frameworks easier to use and for general
interfacing to ‘foreign stuff’.
Would a limited form of user supplied compiler extension be an alternative, an
import processor. Special i
Proposal link:
https://github.com/apple/swift-evolution/blob/master/
proposals/0188-stdlib-index-types-hashable.md
• What is your evaluation of the proposal?
+1 but would like it to further and require all index types to be Hashable.
• Is the problem being addressed significant enough to warrant
+1 it seems like a generic type just for the sake of it. Many languages do
without a specific type for distance and use Int and it is a better solution
because it is simpler.
-- Howard.
> On 9 Nov 2017, at 8:37 am, Ben Cohen via swift-evolution
> wrote:
>
>
> Hi Swift Evolution,
>
> A pit
Not a big deal either way, but I prefer the 2nd (nil) form and therefore
would like to see the 1st form go. It would make Swift more consistent,
consider:
let o: Int? // Looks like nil is assigned.
if someTest {
o = 1 // Why isn't this an error? (OK I know why - but it looks odd.)
} else {
The review of "SE-0187: Introduce Sequence.filterMap(_:)" begins now and
runs through November 14th, 2017. The proposal is available here:
https://github.com/apple/swift-evolution/blob/master/
proposals/0187-introduce-filtermap.md
• What is your evaluation of the proposal?
Worthwhile since ther
I should qualify that I am not proposing removing local functions without
replacing them with closures that have the same power. I don't believe
powerful closures are something the compiler couldn't do, in fact I believe
it is something that is relatively easy. I believe this because there isn't
mu
, and have a generic parameter list.
>
> Slava
>
>
> -- Howard.
>
> On 27 October 2017 at 12:26, Slava Pestov wrote:
>
>>
>>
>> On Oct 26, 2017, at 4:45 PM, Howard Lovatt via swift-evolution <
>> swift-evolution@swift.org> wrote:
>>
).
-- Howard.
On 27 October 2017 at 12:26, Slava Pestov wrote:
>
>
> On Oct 26, 2017, at 4:45 PM, Howard Lovatt via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> Rather than expand local function syntax why not deprecate local functions
> completely
>
&
e a lot of local @inline(__always) functions as a sort of weird macro
> so this change would be hugely source breaking. Also can you even annotate
> a function object as force-inlineable?
>
> On Oct 26, 2017, at 6:45 PM, Howard Lovatt via swift-evolution <
> swift-evolution@swif
The issues raised about local capture by local (inner) functions are valid,
likewise the discussion about the @nonescaping annotation are also valid.
Rather than expand local function syntax why not deprecate local functions
completely and add the @nonescaping annotation to local closures followin
To clarify. I meant the infrastructure for IDE integration with Xcode as one of
the IDEs that used that infrastructure.
-- Howard.
> On 24 Oct 2017, at 11:26 pm, David James via swift-evolution
> wrote:
>
> I would also +1000 Xcode integration, whoever does it. I’m tired of fighting
> with
+1 good idea.
Re. the naming I would suggest `mapFilterNil` since it says what it does
and filter, nil, and map are all understood already in Swift. (I have
sympathy for people wanting `mapFilteringNil`, but Swift chose `filter`.)
The problems I see with `filterMap` are that:
1. It sounds like
I would like Xcode integration 😀
-- Howard.
> On 24 Oct 2017, at 4:43 am, Adrian Zubarev via swift-evolution
> wrote:
>
> I’d be happy if we’d get iOS support and submodules :)
>
>
> Am 23. Oktober 2017 um 19:41:37, Jean-Christophe Pastant via swift-evolution
> (swift-evolution@swift.org)
My preferences in order would be:
1. Split out of Sequence Iterable/ForEachable (whatever the name) and
have Set and Dictionary conform to this new protocol instead of Sequence.
With further protocols splits made to other 'mixin' protocols to keep the
order of iteration undefined.
2. Rename e
I am very glad that this issue is getting some air time since the ‘loose’
definitions in `Sequence` are a pain.
I am in the camp that thinks the best solution is to split `Sequence`. I would
propose splitting into `Iterable` and `Sequence`, `Sequence` is ordered. `Set`
and `Dictionary` would i
Personally I would prefer all the modified to go on the right, so that the
declaration is sorted from most important to least left to right. EG:
Instead of:
@disguardableResult public async mutating func x() throws -> Bool
I would prefer something like:
func x() -> Bool @ throws disgua
You wouldn’t normally use Reactive Streams directly, think of them as the
Babel Fish (hitch hikers) of Streams/actors. If Swift actors talked
Reactive Stream and so did some other library, Akka, RxSwift, etc., then
the two could talk to each other. Which would be a big advantage on large
projects w
Nothing to stop you having Observables linked to a Reactive Stream library,
the RxJava 2 library has Observables and is built on top of Reactive
Streams.
On Mon, 25 Sep 2017 at 5:15 am, Marc Schlichte via swift-evolution <
swift-evolution@swift.org> wrote:
> I hope we come up with some genuine id
Comments in-line below.
On Sun, 24 Sep 2017 at 12:36 pm, Matt Gallagher via swift-evolution <
swift-evolution@swift.org> wrote:
> Some thoughts as a programmer who has written an atypical reactive
> programming library...
>
> You're providing protocols that strongly imply ReactiveX semantics.
Not quite understanding your concern, perhaps you could elaborate. In
particular:
1. The names I proposed were on(next:) and on(error:) so there is no
confusion since next and error are still part of the name. I just moved
them inside the brackets like commonly done in Swift.
2. Neither on(ne
like the `Flow` name (or even `Observable`). Don’t like
> `ReactiveStream` at all.
>
> -g.
>
> On 19 Sep 2017, at 3:59 AM, Howard Lovatt via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> http://www.reactive-streams.org/
>
>
> --
-- Howard.
_
> review of “SE-0186: Remove ownership keyword support in protocols”
> * What is your evaluation of the proposal?
+1, sensible to remove misleading definitions
>
> * Is the problem being addressed significant enough to warrant a change to
> Swift?
Yes, could easily lead to bugs.
>
> * Does t
In Java 9 they have added standard definitions for Reactive Streams, the
`Flow` class, so that third party libraries, like Akka, can interoperate.
Note they haven't added an implementation of Reactive Streams, just the
type definitions.
A starting point for adding similar to Swift could be:
http
Not really certain what async/await adds, using this library (note self
promotion) which is built on top of GCD:
https://github.com/hlovatt/Concurrency-Utilities
You can write:
func doit() {
AsynchronousFuture { // Executes in background and therefore does
not block main
I would argue that given:
foo()
await bar()
baz()
That foo and baz should run on the same queue (using queue in the GCD
sense) but bar should determine which queue it runs on. I say this because:
1. foo and baz are running synchronously with respect to each other
(though they c
e/streams
>
> In general, I would prefer an async story like this:
>
> - support coroutines / generators (yield)
> - use coroutines to implement Future and Stream/Observable
> - optionally provide async/await as syntax sugar for Future/Stream (or
> just reuse yield)
>
> -g.
>
>
I think you are raising very important concerns. As the proposal stood I was
concerned that it would lead people to write poor quality code, in particular
hard to debug deadlock prone code.
I see the proposal as it stands as exposing the equivalent of a pointer in
concurrent programming and ev
I use Mathematica, which under the covers is very Lisp like, though with names
outside the brackets, comma separators, and square brackets. EG `a + b` is
really:
Add[a, b]
The editor however supports all sorts of input formats including the above two
and renders in full mathematical glory,
gt;>>>>> the other way around). You can have the best of both worlds. We are not
>>>>>> losing anything by having this feature. It would be a huge improvement to
>>>>>> have this as an option.
>>>>>>
>>>>>> However, using
ed to all variants of the runtimes in the
> same way! async/await as language level works just as well with GCD as
> with pthreads or another API. And coordination is a compromise that we can
> make after that one.
>
> Em ter, 29 de ago de 2017 às 05:23, Howard Lovatt via swift-evoluti
wo are mixed. I very much prefer
>>>>> how it's done in C#, where you can freely mix the two models without
>>>>> having
>>>>> to resort to ad-hoc wrappers, and you can use async/await with any futures
>>>>> implementation you might already
>> version.
>> Coordination: This we can wait! And why? Because coordination, can be
>> made in different ways, maybe is more suitable to a standard library
>> class/function, not a language level resource.
>>
>> Also, coordination cant be applied to all variants
run in parallel. I have used this a lot to speed up
code and it would be another great addition.
-- Howard.
On 29 August 2017 at 16:14, Chris Lattner wrote:
>
> On Aug 28, 2017, at 6:56 PM, Howard Lovatt via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>
t;>> The async/await is very similar to the proposed Future (as I posed
>>>> earlier) with regard to completion-handler code, they both re-write the
>>>> imported completion-handler function using a closure, the relevant sentence
>>>> from th
Many of the currently popular server side frameworks are switching to
Reactive Streams:
http://en.wikipedia.org/wiki/Reactive_Streams#Adoption
for their underlying communication, including Akka. Reactive Streams are
also to become builtin to Java, as the Flow class, in version 9.
Would it be
I think this makes the proposed async/await coroutines more viable.
Building on this, if the proposed Cancelable became:
protocol ExecutionControl {
/// Causes the executing coroutine to throw
`TerminateCoroutine.cancelled` and also terminates all the sub-coroutines.
var isCanc
. They’re supposed to make it easy to
>>> avoid writing blocking code. This example just does the blocking call on
>>> some other thread.
>>>
>>> Doing it properly would show the benefits of async/await because it
>>> would require more nesting and more co
ous get method then
>> you’re not using futures properly. They’re supposed to make it easy to
>> avoid writing blocking code. This example just does the blocking call on
>> some other thread.
>>
>> Doing it properly would show the benefits of async/await because
gt;> require more nesting and more complex error handling. By simplifying the
>> code you’ve made a comparison between proper asynchronous code (with
>> async/await) and improper asynchronous code (your example).
>>
>> That tendency to want to just block a thread to m
is exactly
> why async/await is so valuable. You get simple code while still doing it
> correctly.
>
> --
> Adam Kemp
>
> On Aug 27, 2017, at 4:00 PM, Howard Lovatt via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> The running example used in the white
My experience with fire and forget without any control or error detection
is that it looks great in small examples but is inadequate in ‘real’
applications, it is highly deadlock prone! I think the minimum you need is
timeout to break deadlocks, control over the thread running the code,
cancel to e
To avoid or at least detect deadlocks you need: timeout (which will at
least generate an error), cancel (which will prevent zombie processes), and
status information (for debugging). It doesn’t make any difference if the
reference is strong or weak. There is an advantage in strong references
since
nverting to Promises seems magical for
> the simple case, but can quickly descend in hard to follow flows and hard
> to debug errors when you move to non trivial multi path scenarios. JS is
> now solving it with their implementation of async/await, but the point is
> that without the ful
My argument goes like this:
1. You don't need async/await to write a powerful future type; you can
use the underlying threads just as well, i.e. future with async/await is no
better than future without.
2. Since future is more powerful, thread control, cancel, and timeout,
people should be en
I think we would be better off with a future type rather than async/await
since they can offer timeout, cancel, and control over which thread
execution occurs on.
-- Howard.
On 26 August 2017 at 00:06, Cavelle Benjamin via swift-evolution <
swift-evolution@swift.org> wrote:
> Disclaimer: not a
I just don't see that async/await adds enough to warrant a language change.
You can write Future on top of GCD and a future type can do more, like
having a cancel, having a timeout, and giving control over what thread is
used.
-- Howard.
On 26 August 2017 at 10:57, Florent Vilmart via swift-evo
Using a Future library, see below, you can do what you want. In particular
a future that is cancellable is more powerful that the proposed
async/await. Here is an extended example of a typical UI task including
users cancelling tasks that is written using a future library (see below):
@IBOutle
t blocking the current thread. The control
> would return to the calling function before all the data was fetched.
>
> -BJ
>
> On Aug 23, 2017, at 7:35 PM, Howard Lovatt via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> Hi All,
>
> Really glad that
Hi All,
Really glad that concurrency is on the table for Swift 5.
I am not sure if async/await are worth adding, as is, to Swift because it
is just as easy to do with a library function - in the spirit of Swift 5,
see `Future` library code below that you can play with and run.
If a `Future` clas
>
> The review of SE-0185 - "Synthesizing Equatable and Hashable conformance".
> The proposal is available here:
> https://github.com/apple/swift-evolution/blob/master/
> proposals/0185-synthesize-equatable-hashable.md
>
> • What is your evaluation of the proposal?
>
Overall a worthwhile a
I am not against these changes, of requiring an implementation, but I am a
little nervous. Let me expand.
I was involved in the Java Coin initiative for community driven changes to
Java 7. In that process the implementation barrier was set very high and it
effectively meant that only changes from
>
> The revised version of the proposal can be found here:
> https://github.com/apple/swift-evolution/blob/master/
> proposals/0104-improved-integers.md
>
> • What is your evaluation of the proposal?
>
Overall +1. Two reservations:
1. Functions like `signum()` that return a property would read
>
> The review of "Substring performance affordances" begins now and runs
> through July 21, 2017. The proposal is available here:
>
> https://github.com/apple/swift-evolution/blob/master/proposals/0183-substring-affordances.md
>
> • What is your evaluation of the proposal?
Generally good
> The review of "String Newline Escaping" begins now and runs through July
> 17, 2017. The proposal is available here:
>
> https://github.com/apple/swift-evolution/blob/master/proposals/0182-newline-escape-in-strings.md
>
> • What is your evaluation of the proposal?
+1. Useful addition to
+1, useful addition. My guess is that it will be used more than build.
-- Howard.
On 16 May 2017 at 10:09, Daniel Dunbar wrote:
> Hello Swift community,
>
> The review of *SE-0179: Swift `run` Command* begins now and runs through *May
> 25th, 2017*.
>
> The proposal is available here:
>
> h
May 2017 at 11:52, Nicholas Maccharoli wrote:
> +1
>
> - Nick
> 2017年5月13日(土) 10:06 Howard Lovatt via swift-evolution <
> swift-evolution@swift.org>:
>
>> +1
>>
>> -- Howard.
>>
>> On 13 May 2017, at 6:41 am, Ted Kremenek wrote:
>>
+1, the benefits outweigh the extra restrictions. Particularly since it is
easy to add an escaping annotation if you think the compiler is wrong.
However this will require careful documentation and good error messages so
that people know why it fails to type check and how to overcome that.
-- Ho
+1
-- Howard.
> On 13 May 2017, at 6:41 am, Ted Kremenek wrote:
>
> Hello Swift community,
>
> The review of SE-0178: Add unicodeScalars property to Character begins now
> and runs through May 17, 2017.
>
> The proposal is available here:
>
> https://github.com/apple/swift-evolution/blob/m
Here is a proposal I put forwards last month on the same topic.
=
# Proposal: Split extension into implementing methods and adding methods
and protocols retrospectively
## Revision history
| Version | Date
nce works out better.
>>
>>
>> -- Howard.
>>
>> On 2 May 2017 at 09:53, Xiaodi Wu wrote:
>>
>>> Howard, take a look at the generics manifesto section on generic
>>> protocols:
>>>
>>> https://github.com/apple/swift/blob/master/do
@Brent,
What aspects of the current proposal do you have reservations about?
-- Howard.
On 3 May 2017 at 18:09, Brent Royal-Gordon wrote:
> On May 3, 2017, at 12:25 AM, Xiaodi Wu via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> I definitely agree that it's a feature that _can_ b
t;
>>> Everything I am suggesting is done in other languages and from my personal
>>> experience works out better.
>>>
>>>
>>> -- Howard.
>>>
>>>> On 2 May 2017 at 09:53, Xiaodi Wu wrote:
>>>> Howard, take a lo
nt area for future Swift
>>>>>>> growth onto the server side. This proposal actively encourages this
>>>>>>> transition to large formal server side code without loosing the free
>>>>>>> wheeling nature of app code.
>>>>>
> review of SE-0176: "Enforce Exclusive Access to Memory"
>
> What is your evaluation of the proposal?
+1, not only will the code be better optimised but also the code will be easier
to understand. It is also nice that there is formal clarity about what the
compiler should do. Proposal should p
required
>>> because m already has an implementation from the extension
>>> }
>>> let p: P = S() // Note typed as P
>>> p.m() // Now prints S.m as expected
>>>
>>> Extensions in the same file as the declaration can have any access, c
1 - 100 of 250 matches
Mail list logo
