I'd also say that one or two keywords are superior than the protocol naming
approach in terms of implementation simplicity (for the core team).
My suggestions:
Either "conform" or "implement" should be a required keyword for all
properties/functions which implement a protocol (also in protocol
On 23.09.2016 11:05, Maximilian Hünenberger wrote:
I'd also say that one or two keywords are superior than the protocol naming
approach in terms of implementation simplicity (for the core team).
My suggestions:
Either "conform" or "implement" should be a required keyword for all
properties/func
Note: Second attempt, first mail was rejected ?
That is correct Vladimir, at the point of writing an API you never know who
will end up using it in which way.
Hence the decision which flavour (of a function) to call should not be made by
the coder writing the API but by the coder using the API.
Hello :)
Am 2016-09-23 08:50, schrieb Rien:
> -- module A --
> class A {
> func foo() {}
> }
>
> -- module B --
> protocol Foo {
> func foo()
> }
> extension A: Foo {}
let c = A()
I’d say that you have two functions here:
A.foo() and A.Foo.foo()
No. Now (i.e. within module B) A conforms
On 23.09.2016 15:10, Rien wrote:
Note: Second attempt, first mail was rejected ?
That is correct Vladimir, at the point of writing an API you never know who
will end up using it in which way.
Hence the decision which flavour (of a function) to call should not be made by
the coder writing the A
Hello Martin,
Adding protocol conformance via existing functions can be had in different
ways, first it could be done via mapping rules.
I.e. if the API user requests a function A.Foo.foo() and there is only a
function A.foo() present, the language rules could allow this to be accepted as
the d
Hello Vladimir,
Going back to the original suggestion:
4.1 Different implementation for different protocols
class Foo : ProtocolA, ProtocolB {
implement(ProtocolA) func foo() {...}
implement(ProtocolB) func foo() {...}
}
class Foo : ProtocolA, ProtocolB {
implement ProtocolA {
fu
Hey all!
I picked up SR-2627 (https://bugs.swift.org/browse/SR-2627) from the Swift
JIRA project. The ticket states:
> UnicodeScalar.utf16 does not have access modifier and therefore is internal
but should be public, as well as UnicodeScalar.UTF16View.
The ticket is written in a way
Do you care about the order in which your queue is filled?
Do you have multiple queues - I’m asking because your serial queue is not part
of Queue?!
You could add your DispatchQueue right into Queue. It depends on your
situation and your goal but sometime you could optimise your code with
someth
+1. This is a bug fix in my mind, evolution is merely a formality.
Ship it
~Robert Widmann
2016/09/22 18:59、Eli Perkins via swift-evolution
のメッセージ:
> Hey all!
>
> I picked up SR-2627 (https://bugs.swift.org/browse/SR-2627) from the Swift
> JIRA project. The ticket states:
>
> > UnicodeSca
On 23.09.2016 17:41, Rien wrote:
Hello Vladimir,
Going back to the original suggestion:
/4.1 Different implementation for different protocols/
/class Foo : ProtocolA, ProtocolB {/
/ implement(ProtocolA) func foo() {...}/
/ implement(ProtocolB) func foo() {...}/
/}/
/class Foo : ProtocolA, P
> On 23 Sep 2016, at 18:25, Vladimir.S wrote:
>
> On 23.09.2016 17:41, Rien wrote:
>> Hello Vladimir,
>>
>> Going back to the original suggestion:
>>
>> /4.1 Different implementation for different protocols/
>> /class Foo : ProtocolA, ProtocolB {/
>> / implement(ProtocolA) func foo() {...}/
It would probably make sense to define the supported characters based on their
category, rather than abstract ranges of character sets. For example, using the
Letter and Number categories might be sufficient for defining identifiers.
https://en.wikipedia.org/wiki/Unicode_character_property#Gener
Sorry, I’m being a little slow on the uptake here. So in future optimised Swift
the
scope of a variable continuing an object doesn't determine it’s lifetime at all!
That seems quite a departure.
This means you have to be very careful with contained UnsafePointers indeed.
I got as far as needing t
Hello Swift community,
The review of SE-0141 "Availability by Swift version" begins now and runs
through September 28, 2016. The proposal is available here:
https://github.com/apple/swift-evolution/blob/master/proposals/0141-available-by-swift-version.md
Reviews are an important part of the Swif
Hello Swift community,
The review of SE-0142: "Permit where clauses to constrain associated types"
begins now and runs through September 30, 2016. The proposal is available here:
https://github.com/apple/swift-evolution/blob/master/proposals/0142-associated-types-constraints.md
Reviews are an im
* What is your evaluation of the proposal?
+1. I very much want to see this in Swift, and it seems like a logical
progression that has the potential to eliminate ugly workarounds.
* Is the problem being addressed significant enough to warrant a change to
Swift?
Yes. Right now the desired relatio
Strong +1. I really need this feature to improve and simplify my existing code.
> On Sep 23, 2016, at 5:50 PM, Austin Zheng via swift-evolution
> wrote:
>
> * What is your evaluation of the proposal?
>
> +1. I very much want to see this in Swift, and it seems like a logical
> progression tha
18 matches
Mail list logo
