In your example, when `Foo` is a class, then `A` does not see a mutation since
the storage is out-of-line. When `Foo` is a struct, it is stored in-line and a
mutation does mutate `A`.
In other words, when what’s stored in `A` is a reference, the reference itself
does not get mutated when you mu
> On Oct 14, 2017, at 10:29, Braden Scothern via swift-users
> wrote:
>
> There is a lot of value in these being mutating functions when working with C
> APIs that need a buffer for it to write to.
>
> If you have a collection and ensure it had allocated it's memory, you can
> then have the
It’s not a bug-fix and it is an API change, so it seems it would have to go
through evolution.
Guillaume Lessard
___
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users
A lot of the MutableCollection implementation is in protocol extensions
(swapAt, for example.)
Should an additional version be written just for the Unsafe*BufferPointer types?
Guillaume Lessard
___
swift-users mailing list
swift-users@swift.org
https:
> On Oct 10, 2017, at 01:50, Martin R via swift-users
> wrote:
>
> Thank you Howard for you response! However, I have a follow-up question:
>
> Why are UnsafeMutableBufferPointer methods which modify not the buffer
> pointer itself, but only the pointed-to memory, mutating at all?
Don’t forg
[re-sending to the list, and elaborating]
You are making the runtime use the first word of the referent as if it were the
reference.
The lowercase-c variable is a reference. rawPointer contains the same value,
and points to the beginning of the object data. Your typecasting is telling the
runt
% wget http://swift.org/atom.xml
URL transformed to HTTPS due to an HSTS policy
[snip]
HSTS -> https://tools.ietf.org/html/rfc6797
swift.org has simply become inaccessible to non-secure or misconfigured clients.
GL
___
swift-users mailing list
swift-u
> On Aug 8, 2017, at 09:10, Martin R wrote:
>
> In that example the tuple is a (stored) property of a class, not a global
> variable. And why does it crash for a global variable, but not for a local
> variable in a function?
In the case of a local variable in a function, the compiler can stat
> On Aug 8, 2017, at 01:11, Martin R via swift-users
> wrote:
>
> SE-0176 Enforce Exclusive Access to Memory
> (https://github.com/apple/swift-evolution/blob/master/proposals/0176-enforce-exclusive-access-to-memory.md)
> states that "Accesses to different stored properties of a struct or
> d
In your example, the compiler needs a parameter of type Position. Car is a type
of Position, but they are not interchangeable. See below:
> On May 26, 2017, at 00:33, Седых Александр via swift-users
> wrote:
>
> protocol Position {
> var x: Double { getset }
> }
>
> struct Car: Position
> On May 12, 2017, at 12:33, Daniel Dunbar via swift-users
> wrote:
>
> We don't have explicit support for api notes in SwiftPM.
>
It would also be useful for cases when the latest versions of clang can’t be
counted on for Linux deployments (3.6 is considered cutting-edge by some, heh)
Guil
It works now, but it's not correct. I wish there were a correct way available.
Guillaume Lessard
> On May 3, 2017, at 21:30, Colin Barrett via swift-users
> wrote:
>
> I haven't used this in production, but this repository looks pretty
> promising. It's more or less just wrapping up the clang
> On May 2, 2017, at 00:05, Rien wrote:
>
> Interesting: this is a kind-of symmetry break between optionals and weak
> references.
> I.e. most (inexperienced?) programmers will see a strong similarity between
> weak references and optionals.
> And for a lot of use cases they do indeed behave s
Hi Rien,
> On May 1, 2017, at 08:46, Rien via swift-users wrote:
>
> In my code I use a lot of queues. And (very often) I will use [weak self] to
> prevent doing things when ‘self’ is no longer available.
>
> Now I am wondering: how does the compiler know that [weak self] is referenced?
The o
> On Mar 9, 2017, at 12:46, Edward Connell via swift-users
> wrote:
>
> // Everything compiles fine until this
> someFunc(items: items)
This is a frequent pain point: protocol existentials cannot stand in for the
protocol they represent.
Your function wants a concrete type that conforms to It
> On Mar 6, 2017, at 12:28 AM, Kenny Leung via swift-users
> wrote:
>
> Follow-up on this:
>
> The StaticString solution doesn’t work:
>
> let separator: StaticString = “|”
> opt.fieldSep = UnsafeMutablePointer(mutating: separator.utf8start)
>
> … because utf8start returns UnsafePointer, and
> On Mar 1, 2017, at 3:21 PM, Edward Connell via swift-users
> wrote:
>
> The thread sanitizer on Linux is reporting that I have race conditions in
> libswiftcore. I eliminated enough code down to this trivial example. Is there
> really a race condition here or are these bogus errors?
>
>
This could come for almost free after SE-0143 is implemented: an Optional of a
Sequence could itself be made to conform to Sequence. It would cost no new
syntax.
extension Optional: Sequence where Wrapped: Sequence {
func makeIterator() -> AnyIterator {
switch self {
case .some(let seq
> On 7 févr. 2017, at 21:57, Slava Pestov wrote:
>
>>
>> On Feb 7, 2017, at 8:14 PM, Guillaume Lessard via swift-users
>> wrote:
>>
>> I keep running into weird things with Swift 3 Collections.
>>
>> A) Collection has its count property de
I keep running into weird things with Swift 3 Collections.
A) Collection has its count property defined as an Int via IndexDistance:
public protocol Collection : Indexable, Sequence {
associatedtype IndexDistance : SignedInteger = Int // line 182 in
Collection.swift
public var count: In
Hi Etan,
`withMemoryRebound` does not copy memory.
The proposal for UnsafeRawPointer contains information about the memory model
(as related to pointers):
https://github.com/apple/swift-evolution/blob/master/proposals/0107-unsaferawpointer.md
(also, the method is defined in the following file:
h
forEach is defined by the Sequence protocol, and is not a mutating function. By
definition, it must create a local iterator in order to perform its duty. As a
consequence, the variable `stream` is the same immediately before and after the
forEach call.
Cheers,
Guillaume Lessard
___
The function foo(x: A){} requires a type which conforms to protocol P.
An existential of protocol P does not actually conform to protocol P.
It’s always been a limitation in Swift: https://bugs.swift.org/browse/SR-55
If the function’s signature were foo(x: P){}, it would work.
Howard’s example
23 matches
Mail list logo
