Re: [swift-evolution] [Review] SE-0182 - String Newline Escaping

[David Hart via swift-evolution]

I can, but it felt more odd to me than a blank line. But that's debatable.

> On 20 Jul 2017, at 01:40, Chris Lattner  wrote:
> 
> 
>> On Jul 17, 2017, at 4:43 AM, David Hart via swift-evolution 
>>  wrote:
>> 
>> To add a data point, I migrated the Swift Package Manager to use Swift 4’s 
>> multi-line strings this weekend. Nearly all of the resulting multi-line 
>> strings required an ending new-line, forcing me to write the following 
>> pattern everywhere:
>> 
>> let text = ""”
>> lorem ipsum dolor sit amet
>> consectetur adipiscing elit
>> sed do eiusmod
>> 
>> “”"
> 
> Can’t you use ... eiusmod\n instead of a blank line?
> 
> -Chris
> 
> 
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Revision] Fixing SE-0177: Add clamp(to:) to the stdlib

[Xiaodi Wu via swift-evolution]

Sorry, it's been a while but I don't understand your reply. As far as I can
tell, nothing has changed since June: the revised proposal continues to
propose an API that is not protocol-based, and the alternative continues to
propose additions to RangeExpression that do not make sense, as partial
ranges do not have both upper and lower bounds.

As I wrote in June, _even if clamping is determined to be a suitable
addition to the standard library_, your revision appears not to address the
core team feedback. I suggested one way in which you could revise your
proposal to address that issue--namely, a `clamping` requirement on
RangeExpression. However, I do not see where you have addressed this
feedback. What am I missing?
On Wed, Jul 19, 2017 at 22:48 Nicholas Maccharoli 
wrote:

> Xiaodi,
>
> Sorry for the delay and thanks for replying!
>
> Well, as to if this meets the standard thats something more subjective
> than objective so
> after hearing a few opinions (hopefully differing) the community could
> piece together
> a cleaner image of if this is a good idea or not.
>
> From the previous feedback on the mailing list there were people in favor
> and Ben from the
> core swift team gave some feedback here saying:
>
> https://github.com/apple/swift-evolution/pull/718
>
> The core team reviewed this proposal and are returning the proposal for
>> revision. This is a welcome proposal in principal, but should be revised to
>> account for the recent addition of the RangeExpression protocol, in
>> order to allow for clamping over different kinds of range expression.
>
>
>
> So since the proposal is being "Returned for revisions" I wanted to
> propose those revisions here:
>
> https://github.com/apple/swift-evolution/pull/723
>
> - Nick
>
>
>
>
> On Wed, Jun 28, 2017 at 1:13 PM, Xiaodi Wu  wrote:
>
>> RangeExpression is a protocol for all ranges, including partial and
>> unbounded ranges. It would not make sense for such a protocol to have an
>> upper bound or a lower bound.
>>
>> The way in which your proposal could dovetail with RangeExpression is for
>> it to add a requirement to that protocol named `clamping(_:)`. Each type of
>> range (_, closed, countable, countable closed, partial from, partial up to,
>> etc.) would then implement that requirement. Then, implementations of
>> `clamped(to:)` could call `clamping(_:)`. Although, at that point, it would
>> be an open question whether having both clamped(to:) and clamping(_:) would
>> be useful. I would be inclined to think that at most one of these is
>> necessary, and only the latter is compatible with a protocol-based approach.
>>
>> I remain unconvinced, however, that this API meets the very high bar for
>> standard library inclusion.
>>
>>
>> On Tue, Jun 27, 2017 at 20:57 Nicholas Maccharoli via swift-evolution <
>> swift-evolution@swift.org> wrote:
>>
>>> Swift Evolution,
>>>
>>> I want to thank the community for the previous feedback for SE-0177
>>> and also address the issue of the proposal being sent back for
>>> revisions.
>>>
>>> The current status being "Returned for revisions" reflects the detailed
>>> design section being incomplete and not working against the latest Swift
>>> 4
>>> snapshot.
>>>
>>> Another reason mentioned by Ben Cohen was that the proposal did not take
>>> advantage of `RangeExpression` and take advantage of a generic
>>> implementation.
>>>
>>> This has been added in the "Alternatives Considered" section in the pull
>>> request that
>>> is open now but I personally favor the generic approach despite the
>>> added cost of extending `RangeExpression` enough to make the implementation
>>> possible.
>>>
>>> In short, at this time `RangeExpression` is lacking functionality to
>>> implement `clamp(to:)`
>>> in a generic fashion so if the community is in favor of extending
>>> `RangeExpression` I am
>>> more than happy to go with a generic implementation rather than the
>>> current concrete
>>> implementation that is in the proposal pull request now.
>>>
>>> I have tried to address these issues and expand the proposal in this
>>> pull request here:
>>>
>>> https://github.com/apple/swift-evolution/pull/723
>>>
>>> Thank you all so much for the feedback and support, I look forward to
>>> exploring where
>>> we can go with this proposal and making Swift 4 the best release yet.
>>>
>>> Forever your Swift Evolution buddy,
>>>
>>>- Nick
>>>
>>>
>>> ___
>>> 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] [Revision] Fixing SE-0177: Add clamp(to:) to the stdlib

[Nicholas Maccharoli via swift-evolution]

Xiaodi,

Sorry for the delay and thanks for replying!

Well, as to if this meets the standard thats something more subjective than
objective so
after hearing a few opinions (hopefully differing) the community could
piece together
a cleaner image of if this is a good idea or not.

>From the previous feedback on the mailing list there were people in favor
and Ben from the
core swift team gave some feedback here saying:

https://github.com/apple/swift-evolution/pull/718

The core team reviewed this proposal and are returning the proposal for
> revision. This is a welcome proposal in principal, but should be revised to
> account for the recent addition of the RangeExpression protocol, in order
> to allow for clamping over different kinds of range expression.



So since the proposal is being "Returned for revisions" I wanted to propose
those revisions here:

https://github.com/apple/swift-evolution/pull/723

- Nick




On Wed, Jun 28, 2017 at 1:13 PM, Xiaodi Wu  wrote:

> RangeExpression is a protocol for all ranges, including partial and
> unbounded ranges. It would not make sense for such a protocol to have an
> upper bound or a lower bound.
>
> The way in which your proposal could dovetail with RangeExpression is for
> it to add a requirement to that protocol named `clamping(_:)`. Each type of
> range (_, closed, countable, countable closed, partial from, partial up to,
> etc.) would then implement that requirement. Then, implementations of
> `clamped(to:)` could call `clamping(_:)`. Although, at that point, it would
> be an open question whether having both clamped(to:) and clamping(_:) would
> be useful. I would be inclined to think that at most one of these is
> necessary, and only the latter is compatible with a protocol-based approach.
>
> I remain unconvinced, however, that this API meets the very high bar for
> standard library inclusion.
>
>
> On Tue, Jun 27, 2017 at 20:57 Nicholas Maccharoli via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>> Swift Evolution,
>>
>> I want to thank the community for the previous feedback for SE-0177
>> and also address the issue of the proposal being sent back for revisions.
>>
>> The current status being "Returned for revisions" reflects the detailed
>> design section being incomplete and not working against the latest Swift
>> 4
>> snapshot.
>>
>> Another reason mentioned by Ben Cohen was that the proposal did not take
>> advantage of `RangeExpression` and take advantage of a generic
>> implementation.
>>
>> This has been added in the "Alternatives Considered" section in the pull
>> request that
>> is open now but I personally favor the generic approach despite the added
>> cost of extending `RangeExpression` enough to make the implementation
>> possible.
>>
>> In short, at this time `RangeExpression` is lacking functionality to
>> implement `clamp(to:)`
>> in a generic fashion so if the community is in favor of extending
>> `RangeExpression` I am
>> more than happy to go with a generic implementation rather than the
>> current concrete
>> implementation that is in the proposal pull request now.
>>
>> I have tried to address these issues and expand the proposal in this pull
>> request here:
>>
>> https://github.com/apple/swift-evolution/pull/723
>>
>> Thank you all so much for the feedback and support, I look forward to
>> exploring where
>> we can go with this proposal and making Swift 4 the best release yet.
>>
>> Forever your Swift Evolution buddy,
>>
>>- Nick
>>
>>
>> ___
>> 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-0182 - String Newline Escaping

[Chris Lattner via swift-evolution]

> On Jul 17, 2017, at 4:43 AM, David Hart via swift-evolution 
>  wrote:
> 
> To add a data point, I migrated the Swift Package Manager to use Swift 4’s 
> multi-line strings this weekend. Nearly all of the resulting multi-line 
> strings required an ending new-line, forcing me to write the following 
> pattern everywhere:
> 
> let text = ""”
> lorem ipsum dolor sit amet
> consectetur adipiscing elit
> sed do eiusmod
> 
> “”"

Can’t you use ... eiusmod\n instead of a blank line?

-Chris


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

Re: [swift-evolution] [swift-evolution-announce] SE-0183 - Substring performance affordances

[Howard Lovatt via swift-evolution]

>
> 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 reservation I have is there are an increasing number of
‘small’ proposals that paper over the limitations of protocols. If
protocols could be used as a type then the methods in `StringProtocol`
would return `StringProtocol` and methods would accept `StringProtocol`.
Whether `String` or `StringSlice` is actually returned by a method would be
irrelevant. Is it better to spend the engineering effort on improving
protocols and `Self` rather than continuously ‘papering over the cracks’.

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


It depends upon the long term view, if protocols are to be improved then
no. If protocols are to remain as is then yes.

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


Other languages that have more powerful equivalent to protocols program to
the protocol and use them for argument and return types. This works better
than the proposal because it is much more generally applicable and doesn’t
hard code implementation details.

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


Read the proposal only, but have had problems with protocols in general and
have tried various ad-hoc solutions including solutions similar to those
proposed for `String`.

>
>
> More information about the Swift evolution process is available at:
> https://github.com/apple/swift-evolution/blob/master/process.md
>
>
> Thank you,
>
> Chris Lattner
> Review Manager
>
>
> ___
> swift-evolution-announce mailing list
> swift-evolution-annou...@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution-announce
>
-- 
-- Howard.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Pitch: Improved Swift pointers

[Andrew Trick via swift-evolution]

> On Jul 19, 2017, at 11:13 AM, Taylor Swift  wrote:
> 
> What about `value:`?
> 
> `ptr.initialize(value: value)`
> `ptr.initialize(value: value, count: 13)`
> `ptr.initialize(as: UInt16.self, at: 0, value: value, count: 13)`

Works for me if it’s reasonably consistent with the rest of the stdlib. I don’t 
know why `value` was avoided in the first place.
-Andy

> On Wed, Jul 19, 2017 at 12:01 PM, Andrew Trick  > wrote:
> 
>> On Jul 18, 2017, at 9:42 PM, Taylor Swift > > wrote:
>> 
>> How do we feel about changing the label to `repeated:`, even in cases where 
>> `count:` is 1?
>> 
>> This would mean that calls would read like this: `ptr.initialize(repeated: 
>> value)`
> 
> Right. Given the default `count` of 1, it’s probably best to stick with `to: 
> value`.
> -Andy
> 
>> 
>> A grep through the stdlib shows that this is by far the most common use case:
>> 
>> swift-source/swift$ grep initialize\(to: . -r
>> ./stdlib/private/SwiftPrivatePthreadExtras/SwiftPrivatePthreadExtras.swift:  
>>   result.initialize(to: block(arg))
>> ./stdlib/private/StdlibUnittest/OpaqueIdentityFunctions.swift:  
>> ptr.initialize(to: x)
>> ./stdlib/private/SwiftReflectionTest/SwiftReflectionTest.swift:  
>> anyPointer.initialize(to: any)
>> ./stdlib/private/SwiftReflectionTest/SwiftReflectionTest.swift:  
>> fn.initialize(to: ThickFunction0(function: function))
>> ./stdlib/private/SwiftReflectionTest/SwiftReflectionTest.swift:  
>> fn.initialize(to: ThickFunction1(function: function))
>> ./stdlib/private/SwiftReflectionTest/SwiftReflectionTest.swift:  
>> fn.initialize(to: ThickFunction2(function: function))
>> ./stdlib/private/SwiftReflectionTest/SwiftReflectionTest.swift:  
>> fn.initialize(to: ThickFunction3(function: function))
>> ./stdlib/private/SwiftPrivate/ShardedAtomicCounter.swift:  (shards + 
>> i).initialize(to: 0)
>> ./stdlib/public/SDK/Foundation/NSError.swift:out.initialize(to: bridged)
>> ./stdlib/public/core/UnsafeRawPointer.swift.gyb://   
>> (self.assumingMemoryBound(to: T.self) + i).initialize(to: source[i])
>> ./stdlib/public/core/UnsafeRawPointer.swift.gyb:  //   .initialize(to: 
>> (source + i).move())
>> ./stdlib/public/core/UnsafeRawPointer.swift.gyb:  //   
>> (--dst).initialize(to: (--src).move())
>> ./stdlib/public/core/Arrays.swift.gyb:  p.initialize(to: repeatedValue)
>> ./stdlib/public/core/Arrays.swift.gyb:(_buffer.firstElementAddress + 
>> oldCount).initialize(to: newElement)
>> ./stdlib/public/core/Arrays.swift.gyb:p.initialize(to: x)
>> ./stdlib/public/core/Arrays.swift.gyb:  p.initialize(to: newValues[q])
>> ./stdlib/public/core/Arrays.swift.gyb:(base + 
>> newCount).initialize(to: next)
>> ./stdlib/public/core/AnyHashable.swift:result.initialize(to: value)
>> ./stdlib/public/core/AnyHashable.swift:result.initialize(to: value)
>> ./stdlib/public/core/AnyHashable.swift:  target.initialize(to: 
>> AnyHashable(value))
>> ./stdlib/public/core/ArrayCast.swift:  target.initialize(to: 
>> _arrayForceCast(source.pointee))
>> ./stdlib/public/core/ArrayCast.swift:target.initialize(to: result)
>> ./stdlib/public/core/ContiguousArrayBuffer.swift:  (resultPtr + 
>> i).initialize(to: _bridgeAnythingToObjectiveC(p[i]))
>> ./stdlib/public/core/ContiguousArrayBuffer.swift:p.initialize(to: 
>> source[i])
>> ./stdlib/public/core/ContiguousArrayBuffer.swift:p.initialize(to: 
>> element)
>> ./stdlib/public/core/ArrayBuffer.swift:  result.initialize(to: 
>> result.pointee)
>> ./stdlib/public/core/HashedCollections.swift.gyb:  target.initialize(to: 
>> _setDownCast(source.pointee))
>> ./stdlib/public/core/HashedCollections.swift.gyb:target.initialize(to: 
>> result)
>> ./stdlib/public/core/HashedCollections.swift.gyb:  target.initialize(to: 
>> _dictionaryDownCast(source.pointee))
>> ./stdlib/public/core/HashedCollections.swift.gyb:target.initialize(to: 
>> result)
>> ./stdlib/public/core/HashedCollections.swift.gyb:(keys + 
>> i).initialize(to: k)
>> ./stdlib/public/core/HashedCollections.swift.gyb:(keys + 
>> toEntryAt).initialize(to: (from.keys + at).move())
>> ./stdlib/public/core/HashedCollections.swift.gyb:(keys + 
>> i).initialize(to: k)
>> ./stdlib/public/core/HashedCollections.swift.gyb:(values + 
>> i).initialize(to: v)
>> ./stdlib/public/core/HashedCollections.swift.gyb:(keys + 
>> toEntryAt).initialize(to: (from.keys + at).move())
>> ./stdlib/public/core/HashedCollections.swift.gyb:(values + 
>> toEntryAt).initialize(to: (from.values + at).move())
>> ./stdlib/public/core/ReflectionLegacy.swift:  out.initialize(to: 
>> String(reflecting: x))
>> 
>> ./stdlib/public/core/ManagedBuffer.swift:p.headerAddress.initialize(to: 
>> initHeaderVal)
>> ./stdlib/public/core/ManagedBuffer.swift:  $0.initialize(to: 
>> ./stdlib/public/core/ArrayBufferProtocol.swift:

[swift-evolution] [Accepted with Revision] SE-0181: Package Manager C/C++ Language Standard Support

[Daniel Dunbar via swift-evolution]

The review of SE-0181: Package Manager C/C++ Language Standard Support ran from 
July 11...14, 2017. The proposal has been accepted for Swift 4.

There was support for the general feature, with some discussion of the 
spelling. We chose to accept the proposal mostly unmodified:
1. While we agreed the enum cases could have simpler spellings, we felt this 
would require substantial design with little practical benefit (at this time, 
we will consider this for our future build setting proposal).
2. We agreed with feedback that using `cLanguageStandard`, etc in place of 
`cStandard` was more consistent, and will adopt that revision.

Thank you to everyone who participated!

Daniel Dunbar
Review Manager

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

Re: [swift-evolution] Pitch: Improved Swift pointers

[Taylor Swift via swift-evolution]

What about `value:`?

`ptr.initialize(value: value)`
`ptr.initialize(value: value, count: 13)`
`ptr.initialize(as: UInt16.self, at: 0, value: value, count: 13)`

On Wed, Jul 19, 2017 at 12:01 PM, Andrew Trick  wrote:

>
> On Jul 18, 2017, at 9:42 PM, Taylor Swift  wrote:
>
> How do we feel about changing the label to `repeated:`, even in cases
> where `count:` is 1?
>
> This would mean that calls would read like this: `ptr.initialize(repeated:
> value)`
>
>
> Right. Given the default `count` of 1, it’s probably best to stick with
> `to: value`.
> -Andy
>
>
> A grep through the stdlib shows that this is by far the most common use
> case:
>
> swift-source/swift$ grep initialize\(to: . -r
> ./stdlib/private/SwiftPrivatePthreadExtras/SwiftPrivatePthreadExtras.swift:
> result.initialize(to: block(arg))
> ./stdlib/private/StdlibUnittest/OpaqueIdentityFunctions.swift:
> ptr.initialize(to: x)
> ./stdlib/private/SwiftReflectionTest/SwiftReflectionTest.swift:
> anyPointer.initialize(to: any)
> ./stdlib/private/SwiftReflectionTest/SwiftReflectionTest.swift:
> fn.initialize(to: ThickFunction0(function: function))
> ./stdlib/private/SwiftReflectionTest/SwiftReflectionTest.swift:
> fn.initialize(to: ThickFunction1(function: function))
> ./stdlib/private/SwiftReflectionTest/SwiftReflectionTest.swift:
> fn.initialize(to: ThickFunction2(function: function))
> ./stdlib/private/SwiftReflectionTest/SwiftReflectionTest.swift:
> fn.initialize(to: ThickFunction3(function: function))
> ./stdlib/private/SwiftPrivate/ShardedAtomicCounter.swift:  (shards +
> i).initialize(to: 0)
> ./stdlib/public/SDK/Foundation/NSError.swift:out.initialize(to:
> bridged)
> ./stdlib/public/core/UnsafeRawPointer.swift.gyb://
> (self.assumingMemoryBound(to: T.self) + i).initialize(to: source[i])
> ./stdlib/public/core/UnsafeRawPointer.swift.gyb:  //
> .initialize(to: (source + i).move())
> ./stdlib/public/core/UnsafeRawPointer.swift.gyb:  //
> (--dst).initialize(to: (--src).move())
> ./stdlib/public/core/Arrays.swift.gyb:  p.initialize(to:
> repeatedValue)
> ./stdlib/public/core/Arrays.swift.gyb:(_buffer.firstElementAddress +
> oldCount).initialize(to: newElement)
> ./stdlib/public/core/Arrays.swift.gyb:p.initialize(to: x)
> ./stdlib/public/core/Arrays.swift.gyb:  p.initialize(to: newValues[q])
> ./stdlib/public/core/Arrays.swift.gyb:(base +
> newCount).initialize(to: next)
> ./stdlib/public/core/AnyHashable.swift:result.initialize(to: value)
> ./stdlib/public/core/AnyHashable.swift:result.initialize(to:
> value)
> ./stdlib/public/core/AnyHashable.swift:  target.initialize(to:
> AnyHashable(value))
> ./stdlib/public/core/ArrayCast.swift:  target.initialize(to:
> _arrayForceCast(source.pointee))
> ./stdlib/public/core/ArrayCast.swift:target.initialize(to: result)
> ./stdlib/public/core/ContiguousArrayBuffer.swift:  (resultPtr +
> i).initialize(to: _bridgeAnythingToObjectiveC(p[i]))
> ./stdlib/public/core/ContiguousArrayBuffer.swift:p.initialize(to:
> source[i])
> ./stdlib/public/core/ContiguousArrayBuffer.swift:p.initialize(to:
> element)
> ./stdlib/public/core/ArrayBuffer.swift:  result.initialize(to:
> result.pointee)
> ./stdlib/public/core/HashedCollections.swift.gyb:  target.initialize(to:
> _setDownCast(source.pointee))
> ./stdlib/public/core/HashedCollections.swift.gyb:
> target.initialize(to: result)
> ./stdlib/public/core/HashedCollections.swift.gyb:  target.initialize(to:
> _dictionaryDownCast(source.pointee))
> ./stdlib/public/core/HashedCollections.swift.gyb:
> target.initialize(to: result)
> ./stdlib/public/core/HashedCollections.swift.gyb:(keys +
> i).initialize(to: k)
> ./stdlib/public/core/HashedCollections.swift.gyb:(keys +
> toEntryAt).initialize(to: (from.keys + at).move())
> ./stdlib/public/core/HashedCollections.swift.gyb:(keys +
> i).initialize(to: k)
> ./stdlib/public/core/HashedCollections.swift.gyb:(values +
> i).initialize(to: v)
> ./stdlib/public/core/HashedCollections.swift.gyb:(keys +
> toEntryAt).initialize(to: (from.keys + at).move())
> ./stdlib/public/core/HashedCollections.swift.gyb:(values +
> toEntryAt).initialize(to: (from.values + at).move())
> ./stdlib/public/core/ReflectionLegacy.swift:  out.initialize(to:
> String(reflecting: x))
>
> ./stdlib/public/core/ManagedBuffer.swift:
> p.headerAddress.initialize(to: initHeaderVal)
> ./stdlib/public/core/ManagedBuffer.swift:  $0.initialize(to:
> ./stdlib/public/core/ArrayBufferProtocol.swift:(elements +
> j).initialize(to: newValues[i])
> ./stdlib/public/core/Sequence.swift:ptr.initialize(to: x)
> ./stdlib/public/core/HeapBuffer.swift:  $0.initialize(to:
> Header(initializer))
> ./stdlib/public/core/UnsafeBitMap.swift:values.initialize(to: 0,
> count: numberOfWords)
> ./stdlib/public/core/String.swift:resultStorage.initialize(to:
> ./test/api-digester/stdlib-stable.json:  "printedName":
> 

Re: [swift-evolution] Pitch: Improved Swift pointers

[Andrew Trick via swift-evolution]

> On Jul 18, 2017, at 9:42 PM, Taylor Swift  wrote:
> 
> How do we feel about changing the label to `repeated:`, even in cases where 
> `count:` is 1?
> 
> This would mean that calls would read like this: `ptr.initialize(repeated: 
> value)`

Right. Given the default `count` of 1, it’s probably best to stick with `to: 
value`.
-Andy
> 
> A grep through the stdlib shows that this is by far the most common use case:
> 
> swift-source/swift$ grep initialize\(to: . -r
> ./stdlib/private/SwiftPrivatePthreadExtras/SwiftPrivatePthreadExtras.swift:   
>  result.initialize(to: block(arg))
> ./stdlib/private/StdlibUnittest/OpaqueIdentityFunctions.swift:  
> ptr.initialize(to: x)
> ./stdlib/private/SwiftReflectionTest/SwiftReflectionTest.swift:  
> anyPointer.initialize(to: any)
> ./stdlib/private/SwiftReflectionTest/SwiftReflectionTest.swift:  
> fn.initialize(to: ThickFunction0(function: function))
> ./stdlib/private/SwiftReflectionTest/SwiftReflectionTest.swift:  
> fn.initialize(to: ThickFunction1(function: function))
> ./stdlib/private/SwiftReflectionTest/SwiftReflectionTest.swift:  
> fn.initialize(to: ThickFunction2(function: function))
> ./stdlib/private/SwiftReflectionTest/SwiftReflectionTest.swift:  
> fn.initialize(to: ThickFunction3(function: function))
> ./stdlib/private/SwiftPrivate/ShardedAtomicCounter.swift:  (shards + 
> i).initialize(to: 0)
> ./stdlib/public/SDK/Foundation/NSError.swift:out.initialize(to: bridged)
> ./stdlib/public/core/UnsafeRawPointer.swift.gyb://   
> (self.assumingMemoryBound(to: T.self) + i).initialize(to: source[i])
> ./stdlib/public/core/UnsafeRawPointer.swift.gyb:  //   .initialize(to: 
> (source + i).move())
> ./stdlib/public/core/UnsafeRawPointer.swift.gyb:  //   
> (--dst).initialize(to: (--src).move())
> ./stdlib/public/core/Arrays.swift.gyb:  p.initialize(to: repeatedValue)
> ./stdlib/public/core/Arrays.swift.gyb:(_buffer.firstElementAddress + 
> oldCount).initialize(to: newElement)
> ./stdlib/public/core/Arrays.swift.gyb:p.initialize(to: x)
> ./stdlib/public/core/Arrays.swift.gyb:  p.initialize(to: newValues[q])
> ./stdlib/public/core/Arrays.swift.gyb:(base + 
> newCount).initialize(to: next)
> ./stdlib/public/core/AnyHashable.swift:result.initialize(to: value)
> ./stdlib/public/core/AnyHashable.swift:result.initialize(to: value)
> ./stdlib/public/core/AnyHashable.swift:  target.initialize(to: 
> AnyHashable(value))
> ./stdlib/public/core/ArrayCast.swift:  target.initialize(to: 
> _arrayForceCast(source.pointee))
> ./stdlib/public/core/ArrayCast.swift:target.initialize(to: result)
> ./stdlib/public/core/ContiguousArrayBuffer.swift:  (resultPtr + 
> i).initialize(to: _bridgeAnythingToObjectiveC(p[i]))
> ./stdlib/public/core/ContiguousArrayBuffer.swift:p.initialize(to: 
> source[i])
> ./stdlib/public/core/ContiguousArrayBuffer.swift:p.initialize(to: element)
> ./stdlib/public/core/ArrayBuffer.swift:  result.initialize(to: 
> result.pointee)
> ./stdlib/public/core/HashedCollections.swift.gyb:  target.initialize(to: 
> _setDownCast(source.pointee))
> ./stdlib/public/core/HashedCollections.swift.gyb:target.initialize(to: 
> result)
> ./stdlib/public/core/HashedCollections.swift.gyb:  target.initialize(to: 
> _dictionaryDownCast(source.pointee))
> ./stdlib/public/core/HashedCollections.swift.gyb:target.initialize(to: 
> result)
> ./stdlib/public/core/HashedCollections.swift.gyb:(keys + 
> i).initialize(to: k)
> ./stdlib/public/core/HashedCollections.swift.gyb:(keys + 
> toEntryAt).initialize(to: (from.keys + at).move())
> ./stdlib/public/core/HashedCollections.swift.gyb:(keys + 
> i).initialize(to: k)
> ./stdlib/public/core/HashedCollections.swift.gyb:(values + 
> i).initialize(to: v)
> ./stdlib/public/core/HashedCollections.swift.gyb:(keys + 
> toEntryAt).initialize(to: (from.keys + at).move())
> ./stdlib/public/core/HashedCollections.swift.gyb:(values + 
> toEntryAt).initialize(to: (from.values + at).move())
> ./stdlib/public/core/ReflectionLegacy.swift:  out.initialize(to: 
> String(reflecting: x))
> 
> ./stdlib/public/core/ManagedBuffer.swift:p.headerAddress.initialize(to: 
> initHeaderVal)
> ./stdlib/public/core/ManagedBuffer.swift:  $0.initialize(to: 
> ./stdlib/public/core/ArrayBufferProtocol.swift:(elements + 
> j).initialize(to: newValues[i])
> ./stdlib/public/core/Sequence.swift:ptr.initialize(to: x)
> ./stdlib/public/core/HeapBuffer.swift:  $0.initialize(to: 
> Header(initializer))
> ./stdlib/public/core/UnsafeBitMap.swift:values.initialize(to: 0, count: 
> numberOfWords)
> ./stdlib/public/core/String.swift:resultStorage.initialize(to: 
> ./test/api-digester/stdlib-stable.json:  "printedName": 
> "initialize(to:count:)",
> ./test/Generics/slice_test.swift:(newbase + i).initialize(to: 
> (base+i).move())
> ./test/Generics/slice_test.swift:(base+length).initialize(to: elem)
> 

Re: [swift-evolution] Enforce non-nil assignment to an implicitly unwrapped optional property?

[Robert Bennett via swift-evolution]

Another valid reason to nullify implicitly unwrapped optional would be to free 
up some memory. I don’t think we want to disallow this behavior.

If you really need to be unable to assign nil to an implicitly unwrapped 
optional, you can fake it using this code. S.value acts like an implicitly 
unwrapped optional, except that the compiler won’t let you assign an optional 
to it.


struct S {
struct T {
var value: Int
}

private var t: T?
var value: Int {
get { return self.t!.value }
set { 
if self.t == nil {
self.t = T(value: newValue)
} else {
self.t!.value = newValue
}
}
}
}


> On Jul 19, 2017, at 8:07 AM, Rod Brown via swift-evolution 
>  wrote:
> 
> Implicitly unwrapped optionals are often used when the optional system is a 
> little complicated around one of your variables.
> 
> Some of those times are variables that are nil-resettable (where you set nil, 
> and it internally does something to use that as a reset case) or 
> initialisation issues where you can’t know a variable at prior to the 
> initialisation, but can get it out. But these are just two examples.
> 
> I think trying to work more on tying people’s hands with this attribute 
> specifically designed to handle edge cases seems a little… concerning.
> 
> It might make more sense to use a computed property covering the internal 
> property completely if you need this behaviour? 
> 
>> On 19 Jul 2017, at 3:31 pm, Glen Huang via swift-evolution 
>>  wrote:
>> 
>> Anyone has any thoughts on this?
>> 
>>> On 16 Jul 2017, at 3:46 PM, Glen Huang via swift-evolution 
>>>  wrote:
>>> 
>>> I want to define a property for a struct/class that is nil after 
>>> initialization, but later is guaranteed to have a value after I manually 
>>> assign to it. I think implicitly unwrapped optional property is designed 
>>> specifically for that.
>>> 
>>> However, the problem arises when it comes to how do I enforce that I never 
>>> mistakenly assign nil to this property?
>>> 
>>> struct Foo {
>>>  var name: String!
>>> }
>>> var foo = Foo()
>>> 
>>> I can do foo.name = nil and it will compile just fine.
>>> 
>>> I guess I could do a run-time check with something like:
>>> 
>>> struct Foo {
>>>  var name: String! {
>>>  willSet {
>>>  if newValue == nil {
>>>  fatalError("nil isn't allowed")
>>>  }
>>>  }
>>>  }
>>> }
>>> 
>>> But it feels ugly, and seems to be something checkable at compile time.
>>> 
>>> I could define a new setter method:
>>> 
>>> struct Foo {
>>>  private(set) var name: String!
>>>  mutating func setName(_ name: String) {
>>>  self.name = name
>>>  }
>>> }
>>> 
>>> But it feel tedious. Enforcing non-nil assignment probably fits 90% of the 
>>> use cases of IUOs, since that’s basically their definition. Having to 
>>> deviate from direct assignment syntax in usage and also define a new setter 
>>> method for the majority cases seems unfortunate.
>>> 
>>> I wonder if it’s desirable to define an attribute or something to ask the 
>>> compiler to only allow non-optionals to be assigned to IUO properties?
>>> ___
>>> 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] Enforce non-nil assignment to an implicitly unwrapped optional property?

[Rod Brown via swift-evolution]

Implicitly unwrapped optionals are often used when the optional system is a 
little complicated around one of your variables.

Some of those times are variables that are nil-resettable (where you set nil, 
and it internally does something to use that as a reset case) or initialisation 
issues where you can’t know a variable at prior to the initialisation, but can 
get it out. But these are just two examples.

I think trying to work more on tying people’s hands with this attribute 
specifically designed to handle edge cases seems a little… concerning.

It might make more sense to use a computed property covering the internal 
property completely if you need this behaviour? 

> On 19 Jul 2017, at 3:31 pm, Glen Huang via swift-evolution 
>  wrote:
> 
> Anyone has any thoughts on this?
> 
>> On 16 Jul 2017, at 3:46 PM, Glen Huang via swift-evolution 
>>  wrote:
>> 
>> I want to define a property for a struct/class that is nil after 
>> initialization, but later is guaranteed to have a value after I manually 
>> assign to it. I think implicitly unwrapped optional property is designed 
>> specifically for that.
>> 
>> However, the problem arises when it comes to how do I enforce that I never 
>> mistakenly assign nil to this property?
>> 
>> struct Foo {
>>   var name: String!
>> }
>> var foo = Foo()
>> 
>> I can do foo.name = nil and it will compile just fine.
>> 
>> I guess I could do a run-time check with something like:
>> 
>> struct Foo {
>>   var name: String! {
>>   willSet {
>>   if newValue == nil {
>>   fatalError("nil isn't allowed")
>>   }
>>   }
>>   }
>> }
>> 
>> But it feels ugly, and seems to be something checkable at compile time.
>> 
>> I could define a new setter method:
>> 
>> struct Foo {
>>   private(set) var name: String!
>>   mutating func setName(_ name: String) {
>>   self.name = name
>>   }
>> }
>> 
>> But it feel tedious. Enforcing non-nil assignment probably fits 90% of the 
>> use cases of IUOs, since that’s basically their definition. Having to 
>> deviate from direct assignment syntax in usage and also define a new setter 
>> method for the majority cases seems unfortunate.
>> 
>> I wonder if it’s desirable to define an attribute or something to ask the 
>> compiler to only allow non-optionals to be assigned to IUO properties?
>> ___
>> 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: Improved Swift pointers

[Xiaodi Wu via swift-evolution]

FWIW, the label should be "repeating".

On Tue, Jul 18, 2017 at 11:42 PM, Taylor Swift via swift-evolution <
swift-evolution@swift.org> wrote:

> How do we feel about changing the label to `repeated:`, even in cases
> where `count:` is 1?
>
> This would mean that calls would read like this: `ptr.initialize(repeated:
> value)`
>
> A grep through the stdlib shows that this is by far the most common use
> case:
>
> swift-source/swift$ grep initialize\(to: . -r
> ./stdlib/private/SwiftPrivatePthreadExtras/SwiftPrivatePthreadExtras.swift:
> result.initialize(to: block(arg))
> ./stdlib/private/StdlibUnittest/OpaqueIdentityFunctions.swift:
> ptr.initialize(to: x)
> ./stdlib/private/SwiftReflectionTest/SwiftReflectionTest.swift:
> anyPointer.initialize(to: any)
> ./stdlib/private/SwiftReflectionTest/SwiftReflectionTest.swift:
> fn.initialize(to: ThickFunction0(function: function))
> ./stdlib/private/SwiftReflectionTest/SwiftReflectionTest.swift:
> fn.initialize(to: ThickFunction1(function: function))
> ./stdlib/private/SwiftReflectionTest/SwiftReflectionTest.swift:
> fn.initialize(to: ThickFunction2(function: function))
> ./stdlib/private/SwiftReflectionTest/SwiftReflectionTest.swift:
> fn.initialize(to: ThickFunction3(function: function))
> ./stdlib/private/SwiftPrivate/ShardedAtomicCounter.swift:  (shards +
> i).initialize(to: 0)
> ./stdlib/public/SDK/Foundation/NSError.swift:out.initialize(to:
> bridged)
> ./stdlib/public/core/UnsafeRawPointer.swift.gyb://
> (self.assumingMemoryBound(to: T.self) + i).initialize(to: source[i])
> ./stdlib/public/core/UnsafeRawPointer.swift.gyb:  //
> .initialize(to: (source + i).move())
> ./stdlib/public/core/UnsafeRawPointer.swift.gyb:  //
> (--dst).initialize(to: (--src).move())
> ./stdlib/public/core/Arrays.swift.gyb:  p.initialize(to:
> repeatedValue)
> ./stdlib/public/core/Arrays.swift.gyb:(_buffer.firstElementAddress +
> oldCount).initialize(to: newElement)
> ./stdlib/public/core/Arrays.swift.gyb:p.initialize(to: x)
> ./stdlib/public/core/Arrays.swift.gyb:  p.initialize(to: newValues[q])
> ./stdlib/public/core/Arrays.swift.gyb:(base +
> newCount).initialize(to: next)
> ./stdlib/public/core/AnyHashable.swift:result.initialize(to: value)
> ./stdlib/public/core/AnyHashable.swift:result.initialize(to:
> value)
> ./stdlib/public/core/AnyHashable.swift:  target.initialize(to:
> AnyHashable(value))
> ./stdlib/public/core/ArrayCast.swift:  target.initialize(to:
> _arrayForceCast(source.pointee))
> ./stdlib/public/core/ArrayCast.swift:target.initialize(to: result)
> ./stdlib/public/core/ContiguousArrayBuffer.swift:  (resultPtr +
> i).initialize(to: _bridgeAnythingToObjectiveC(p[i]))
> ./stdlib/public/core/ContiguousArrayBuffer.swift:p.initialize(to:
> source[i])
> ./stdlib/public/core/ContiguousArrayBuffer.swift:p.initialize(to:
> element)
> ./stdlib/public/core/ArrayBuffer.swift:  result.initialize(to:
> result.pointee)
> ./stdlib/public/core/HashedCollections.swift.gyb:  target.initialize(to:
> _setDownCast(source.pointee))
> ./stdlib/public/core/HashedCollections.swift.gyb:
> target.initialize(to: result)
> ./stdlib/public/core/HashedCollections.swift.gyb:  target.initialize(to:
> _dictionaryDownCast(source.pointee))
> ./stdlib/public/core/HashedCollections.swift.gyb:
> target.initialize(to: result)
> ./stdlib/public/core/HashedCollections.swift.gyb:(keys +
> i).initialize(to: k)
> ./stdlib/public/core/HashedCollections.swift.gyb:(keys +
> toEntryAt).initialize(to: (from.keys + at).move())
> ./stdlib/public/core/HashedCollections.swift.gyb:(keys +
> i).initialize(to: k)
> ./stdlib/public/core/HashedCollections.swift.gyb:(values +
> i).initialize(to: v)
> ./stdlib/public/core/HashedCollections.swift.gyb:(keys +
> toEntryAt).initialize(to: (from.keys + at).move())
> ./stdlib/public/core/HashedCollections.swift.gyb:(values +
> toEntryAt).initialize(to: (from.values + at).move())
> ./stdlib/public/core/ReflectionLegacy.swift:  out.initialize(to:
> String(reflecting: x))
>
> ./stdlib/public/core/ManagedBuffer.swift:
> p.headerAddress.initialize(to: initHeaderVal)
> ./stdlib/public/core/ManagedBuffer.swift:  $0.initialize(to:
> ./stdlib/public/core/ArrayBufferProtocol.swift:(elements +
> j).initialize(to: newValues[i])
> ./stdlib/public/core/Sequence.swift:ptr.initialize(to: x)
> ./stdlib/public/core/HeapBuffer.swift:  $0.initialize(to:
> Header(initializer))
> ./stdlib/public/core/UnsafeBitMap.swift:values.initialize(to: 0,
> count: numberOfWords)
> ./stdlib/public/core/String.swift:resultStorage.initialize(to:
> ./test/api-digester/stdlib-stable.json:  "printedName":
> "initialize(to:count:)",
> ./test/Generics/slice_test.swift:(newbase + i).initialize(to:
> (base+i).move())
> ./test/Generics/slice_test.swift:(base+length).initialize(to: elem)
> ./test/Parse/pointer_conversion.swift.gyb:  p.initialize(to: t)
>
>