vars cannot be type narrowed as soon as concurrency comes into play. That's why
Ceylon restricts type narrowing to immutables.
-Thorsten
> Am 03.11.2016 um 09:52 schrieb Martin Waitz via swift-evolution
> :
>
> Am 2016-11-03 09:17, schrieb Pyry Jahkola via swift-evolution:
>> As pleasing as i
Okay, I think I found an actual shortcoming that type narrowing might
address, namely mutating a property in place if it is a subtype. Here is a
small example setup:
protocol A { var x: Int {get} }
struct B: A { var x: Int }
struct C { var a: A }
var c = C(a: B(x: 4))
Note that “A” does not promi
> On 3 Nov 2016, at 19:23, Nevin Brackett-Rozinsky
> wrote:
> For the motivating examples, there is already a much cleaner solution:
> (foo as? B)?.someMethodSpecificToB()
Eh, kinda; you've taken an example showing branching and boiled it down into a
single line; what if my intention was to ca
> On 2016-11-03, at 19:39, Chris Eidhof via swift-evolution
> wrote:
> I was wondering if there's any interest in adding Swift-like sort descriptors
> to the language. Currently, we have `sort` and `sorted`, which take a
> function of type `(A, A) -> Bool`. Foundation has `NSSortDescriptor`, w
This proposal seems well-reasoned, but like Nevin I worry about the
interactions between type narrowing, reference types or capture of mutable
values, and concurrency or async. How will these things play together?
On Thu, Nov 3, 2016 at 14:23 Nevin Brackett-Rozinsky via swift-evolution <
swift-evo
This looks like a lot of complexity for very little gain.
Aside from any implementation concerns, this proposal substantially
increases the cognitive load on developers. To figure out what a piece of
code means, someone reading it will have to mentally keep track of a “type
stack” for every variab
Hey everyone,
I was wondering if there's any interest in adding Swift-like sort
descriptors to the language. Currently, we have `sort` and `sorted`, which
take a function of type `(A, A) -> Bool`. Foundation has
`NSSortDescriptor`, which corresponds more to `(A, A) -> ComparisonResult`.
NSSortDesc
Great. I'd like to see something like this. Couple of comments:
You don't explicitly address overload selection. Do you intend it to
be affected?
Impact on existing code section could be more descriptive.
On Thursday, November 3, 2016, Haravikk via swift-evolution <
swift-evolution@swift.org> wr
> On 3 Nov 2016, at 17:36, Daniel Duan via swift-evolution
> wrote:
>> I am not sure why in some cases we need to be unique over state of the art
>> like Cocoapods in some areas. What is the added value (not saying that there
>> is none)?
>
> You can combine mechanisms to get your desired pol
To avoid hijacking the guard let x = x thread entirely I've decided to try to
write up a proposal on type narrowing in Swift.
Please give your feedback on the functionality proposed, as well as the clarity
of the proposal/examples themselves; I've tried to keep it straightforward, but
I do tend
> On Nov 3, 2016, at 1:02 AM, Goffredo Marocchi wrote:
>
> Could you specify that in the tag of the dependency you need? >= 3.0.0 vs
> = 2.0.0 etc…
That’s missing the point of pinning though. You can already do this in
Package.swift. Pinning is, in a way, guarding against violation of s
> On Nov 2, 2016, at 4:39 PM, Martin Waitz via swift-evolution
> wrote:
>
> Hi,
>
>> The review of “Conditional Conformances” begins now and runs through October
>> 7.
>
> What’s the status here?
> My impression is that it’s quite uncontroversial and everybody can’t wait to
> see this imple
Has anybody thought about the semantic issues of out-of-module extensions with
stored properties apart from the implementation issues?
Such properties could potentially wreak havoc with the semantics of the type
being extended. How would these properties play nice with an existing
definition of
> On 3 Nov 2016, at 08:17, Pyry Jahkola wrote:
>
> As pleasing as it sounds*), the idea of type narrowing breaks down badly if:
>
> – the binding is implicit (without explicit extra syntax involved) and
> – what is bound happens to be mutable.
>
> An example being:
>
> // var message: Str
Hi John,
> [...]
>> 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
Am 2016-11-03 09:17, schrieb Pyry Jahkola via swift-evolution:
As pleasing as it sounds*), the idea of type narrowing breaks down
badly if:
– the binding is implicit (without explicit extra syntax involved)
and
– what is bound happens to be mutable.
An example being:
// VAR message: String?
> if x != nil {
> // x is definitely not nil inside this block (implicitly
> unwrapped)
Pyry already mentioned the problem that arise when x is a variable (is "x =
nil" forbidden inside the block?).
Properties add complications as well (especially, but not only, computed ones),
an
As pleasing as it sounds*), the idea of type narrowing breaks down badly if:
– the binding is implicit (without explicit extra syntax involved) and
– what is bound happens to be mutable.
An example being:
// var message: String?
if message != nil { // magic turns 'message' into a non-opt
Could you specify that in the tag of the dependency you need? >= 3.0.0 vs =
2.0.0 etc... I am not sure why in some cases we need to be unique over state
of the art like Cocoapods in some areas. What is the added value (not saying
that there is none)?
Sent from my iPhone
> On 3 Nov 2016, a
> Am 03.11.2016 um 03:22 schrieb Daniel Duan :
>
> On Nov 2, 2016, at 3:46 PM, Martin Waitz via swift-evolution
> wrote:
>
>>> What is your evaluation of the proposal?
>>
>> +1 for using reproducible versions of dependencies
>> -1 for the actual proposal
>>
>> My problem with this proposal i
20 matches
Mail list logo
