On Mon, Jan 8, 2018 at 4:29 PM, Ben Cohen via swift-evolution
wrote:
> There exists in the standard library a type `DictionaryLiteral` that deserves
> naming re-consideration before we declare ABI Stability, because it’s
> confusingly misnamed, being neither a Dictionary (it doesn’t provide
> k
On Wed, Aug 10, 2016 at 3:50 PM, David Sweeris via swift-evolution
wrote:
> For example, maybe you really do need to interpret a 64-bit chunk of data as
> an Int64, even though the compiler is convinced it’s a Double. We can do that
> in Swift through the various “unsafe” functions, which is whe
On Fri, Aug 5, 2016 at 7:35 PM, Boris Wang via swift-evolution
wrote:
> codes in swift REPL:
>
> protocol P {
> var x:Int {get}
> }
> MemoryLayout.size
> //r0 : Int = 40
>
> struct S1 {
> var v1:Int = 0
> }
> MemoryLayout.size
> //r1: Int =8
>
> struct S2: P {
> var v2: Int
> var x:Int
> }
> Memor
On Wed, Aug 3, 2016 at 7:28 PM, Xiaodi Wu via swift-evolution
wrote:
> Could I suggest an alternative? It's conservative in that it mimics the
> relationships we had before the proposal was implemented and also maintains
> the simplicity of the caseless enum:
>
> ```
> extension MemoryLayout {
>
On Thu, Jul 28, 2016 at 11:01 AM, Karl Wagner wrote:
> I didn't know that normally-copying initialiser was non-copying for
> ContiguousArray. That's the kind of thing we should really document
> somewhere
We would welcome a patch for the docs!
> (or it should be it's own function because it guar
On Wed, Jul 27, 2016 at 11:08 PM, Karl via swift-evolution
wrote:
> It seems like a reasonably large hole with a simple fix. Going from
> ContiguousArray to Array is a kind-of upcasting conversion and should be
> allowed -- it seems like that's almost the whole point of the type.
Hi Karl,
Conver
On Mon, Jul 25, 2016 at 1:12 PM, Nate Cook via swift-evolution
wrote:
>>
>> https://github.com/apple/swift-evolution/blob/master/proposals/0131-anyhashable.md
>
> +1!
>
> This proposal looks great to me. I only have one nitpick: it looks like
> there's a '_Hashable' protocol used in the Di
On Mon, Jul 25, 2016 at 1:34 PM, Pyry Jahkola via swift-evolution
wrote:
>
> On 24 Jul 2016, at 01:26, Chris Lattner via swift-evolution
> wrote:
>
> Hello Swift community,
>
> The review of "SE-0131: Add AnyHashable to the standard library" begins now
> and runs through July 25. This proposal i
You can view the full proposal here:
https://github.com/apple/swift-evolution/pull/458/files
Dmitri
--
main(i,j){for(i=2;;i++){for(j=2;j*/
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evoluti
Hi,
The implementation of SE-0116 "Import Objective-C id as Swift Any type"
requires a type-erased container for hashable values.
We are proposing to add such a type-erased container under the name
AnyHashable to the standard library.
This proposal is additive, source-breaking changes are discus
On Fri, Jul 22, 2016 at 11:16 AM, Bob Wilson via swift-evolution
wrote:
> I have been looking at the parts of this proposal related to
> withUnsafe[Mutable]Pointer:
>
[...]
I agree with everything that Bob said, and I would like to comment on this part:
> unsafeAddressOf is removed, in favor of
On Fri, Jul 22, 2016 at 8:38 AM, Nevin Brackett-Rozinsky
wrote:
> Excellent point Karl.
>
> In my view, floating point NaN values are really quite similar to `.none`.
>
> I would be interested in exploring a move *away* from the IEEE 754 handling
> of NaN. In particular, we could model Float and D
On Fri, Jul 22, 2016 at 8:23 AM, Félix Cloutier
wrote:
> I agree on principle for moving it out of stdlib, but what's the Objective-C
> overlay?
It is the overlay for the 'ObjectiveC' module where NSObject is defined.
Dmitri
--
main(i,j){for(i=2;;i++){for(j=2;j*/
__
On Fri, Jul 22, 2016 at 2:13 AM, Pyry Jahkola via swift-evolution
wrote:
> 5. Will it be considered "ok" to define a type for which `T.areSame(a, b) ==
> true` but `a != b`? An obvious example would be Double.nan, so I assume the
> answer is a resounding yes.
Yes, because `==` is not a protocol
On Fri, Jul 22, 2016 at 12:29 AM, David Hart wrote:
> Just trying to summarize to make sure I understand. So, on most Equatable
> types, == and areSame will have the same semantics (return the same result
> for all operations), but some types will want different semantics, and
> that's why areSame
On Thu, Jul 21, 2016 at 11:09 PM, Brent Royal-Gordon via
swift-evolution wrote:
>> On Jul 21, 2016, at 6:11 PM, Robert Widmann via swift-evolution
>> wrote:
>>
>> Hello Swift Community,
>>
>> Harlan Haskins, Jaden Geller, and I have been working on a proposal to clean
>> up the semantics of ord
On Thu, Jul 21, 2016 at 10:17 PM, Xiaodi Wu wrote:
> Robert, the gist is notably vague on this point, so I'm hoping you will
> clarify. Are you proposing that FloatingPoint will break with IEEE754
> semantics? What will be the result of `Float.nan == Float.nan`?
>
> (My guess at the sanest outcome
Hi,
On Thu, Jul 21, 2016 at 6:11 PM, Robert Widmann via swift-evolution
wrote:
> Hello Swift Community,
>
> Harlan Haskins, Jaden Geller, and I have been working on a proposal to clean
> up the semantics of ordering relations in the standard library.
Great work!
As a part of your implementation
On Thu, Jul 21, 2016 at 4:49 PM, Anton Zhilin wrote:
> 2016-07-22 2:39 GMT+03:00 Dmitri Gribenko :
>>
>> On Thu, Jul 21, 2016 at 4:06 PM, Anton Zhilin
>> wrote:
>> > Moreover, types can completely customize contents of their
>> > 'Mirror's. This is incompatible with laziness and with how reflecti
On Thu, Jul 21, 2016 at 4:06 PM, Anton Zhilin wrote:
> 2016-07-22 1:34 GMT+03:00 Dmitri Gribenko :
>>
>> > Mirror.DisplayStyle contains optional and set as special cases, but does
>> > not
>> > contain function
>> > Mirror collects all information possible at initialization, while for
>> > true
>>
On Thu, Jul 21, 2016 at 3:25 PM, Anton Zhilin via swift-evolution
wrote:
> https://github.com/Anton3/swift-evolution/blob/master/proposals/-rename-mirror.md
>
> Rename Mirror
>
> Proposal: SE-
> Author: Anton Zhilin, Adrian Zubarev
> Status: Awaiting review
> Review manager: TBD
>
> Introd
On Thu, Jul 21, 2016 at 10:02 AM, Michael Gottesman via
swift-evolution wrote:
> Hello everyone.
>
> This is a proposal to move AutoreleasingUnsafeMutablePointer from StdlibCore
> to the Objective C overlay.
+1.
Dmitri
--
main(i,j){for(i=2;;i++){for(j=2;j*/
___
On Mon, Jul 18, 2016 at 3:29 PM, Dave Abrahams via swift-evolution
wrote:
>
> on Mon Jul 18 2016, Kevin Nattinger wrote:
>
>> I agree, true is definitely the expected behavior. In particular, it
>> seems absurd to me that `a.hasPrefix(b)` and `a.hasSuffix(b)` could be
>> false when `a == b` is tr
On Tue, Jul 19, 2016 at 10:50 PM, Chris Lattner via swift-evolution
wrote:
> Hello Swift community,
>
> The review of "SE-0122: Use colons for subscript declarations " begins now
> and runs through July 24. The proposal is available here:
>
>
> https://github.com/apple/swift-evolution/bl
On Tue, Jul 19, 2016 at 10:51 PM, Chris Lattner wrote:
> The review of "SE-0125: Remove NonObjectiveCBase and isUniquelyReferenced"
> begins now and runs through July 22. The proposal is available here:
>
>
> https://github.com/apple/swift-evolution/blob/master/proposals/0125-remove-nono
On Tue, Jul 19, 2016 at 10:14 AM, Xin Tong via swift-evolution
wrote:
> Hi,
>
> I would like to propose changing unicodescalar initializer to failable.
>
> Currently, when you pass an invalid value to the UnicodeScalar initializer
> the swift stdlib crashes the program by calling _precondition. Th
On Sun, Jul 17, 2016 at 2:00 AM, 张国晔 via swift-evolution
wrote:
> I'm building an document-based app, and I'm having a problem regarding to Set.
>
> What I hope to achieve is to have a Set of unique objects by their references.
Try this:
public final class ReferenceEqualityBox : Hashable {
pub
On Sat, Jul 16, 2016 at 12:47 PM, Arnold Schwaighofer via
swift-evolution wrote:
> ## Proposed solution
>
> Replace `isUniquelyReferenced` by
> `isUniquelyReferencedUnsafe` and remove the `NonObjectiveCBase`
> class from the standard library.
Thank you for this proposal!
For presentation and cla
On Fri, Jul 15, 2016 at 11:44 AM, Ted kremenek via swift-dev
wrote:
> Good question.
>
> Dave/Dmitri: do you have a recommendation here? I can see either the JIRA
> issues referencing the proposal (if one exists) or updating the gist. I
> prefer the former.
Updating the JIRA sounds good to me,
On Wed, Jul 13, 2016 at 4:39 PM, Arnold Schwaighofer via
swift-evolution wrote:
> Int.init(ObjectIdentifier) and UInt.init(ObjectIdentifier) should have a
> 'bitPattern:’ label to make it clear at the use site that we interpret the
> value as a bit pattern.
+1!
Dmitri
--
main(i,j){for(i=2;;i
Hi,
I'd like to continue the discussion of the issue raised by David Waite
inhttp://thread.gmane.org/gmane.comp.lang.swift.evolution/21295/:
> My main motivation for proposing this is the potential for developer
> confusion. As stated during one of the previous threads on the naming of map,
> f
On Thu, Jul 7, 2016 at 6:14 PM, Dave Abrahams via swift-evolution
wrote:
>
> on Wed Jul 06 2016, Tim Vermeulen wrote:
>
>> This is a follow up from this swift-users thread:
>> https://lists.swift.org/pipermail/swift-users/Week-of-Mon-20160704/002489.html
>>
>> As it stands, RangeReplaceableColle
On Thu, Jul 7, 2016 at 9:27 AM, John McCall wrote:
> On Jul 7, 2016, at 9:23 AM, Dmitri Gribenko via swift-evolution
> wrote:
>> Proposal link:
>>
>>
>> https://github.com/apple/swift-evolution/blob/master/proposals/0077-operator-precedence.md
>
> Dave, Max
> Proposal link:
>
>
https://github.com/apple/swift-evolution/blob/master/proposals/0077-operator-precedence.md
Dave, Max and I discussed SE-0077 and reviewed the names of precedence
groups.
Here's our recommendation.
In general, we think some names don't read well and have some ambiguities,
for
On Wed, Jul 6, 2016 at 9:57 PM, Charlie Monroe via swift-evolution
wrote:
>
> On Jul 7, 2016, at 12:46 AM, Jordan Rose via swift-evolution
> wrote:
>
>
> On Jul 6, 2016, at 11:03, Jacob Bandes-Storch via swift-evolution
> wrote:
>
>
>> * Remove unsafeAddressOf. "We are not aware of any real use
On Wed, Jul 6, 2016 at 6:15 PM, Karl wrote:
>
> On 7 Jul 2016, at 02:06, Dmitri Gribenko wrote:
>
> On Wed, Jul 6, 2016 at 4:21 AM, Karl wrote:
>
> I had a PR open for this which added a Collection specialisation, but you
> said this could be handled in a more general way which allows for more
>
On Wed, Jul 6, 2016 at 4:21 AM, Karl wrote:
> I had a PR open for this which added a Collection specialisation, but you
> said this could be handled in a more general way which allows for more
> optimised mutations. I’m curious how this would work; how does
> `RangeReplaceableCollection.replaceSub
On Wed, Jul 6, 2016 at 11:30 AM, Harlan Haskins
wrote:
> I’ve also seen unsafeAddressOf(_:) used when interfacing with C function
> pointers when the lifetime of an object is guaranteed. Many C APIs vend an
> API like:
>
> void perform_action(void (*callback)(void *data), void *initial_data);
>
>
On Tue, Jul 5, 2016 at 9:24 PM, Chris Lattner wrote:
> On Jul 5, 2016, at 6:57 PM, Dmitri Gribenko via swift-evolution
> wrote:
>>
>> Hi swift-evolution,
>>
>> Dave, Max and I have compiled a list of open issues in the standard
>> library for which the resol
Hi swift-evolution,
Dave, Max and I have compiled a list of open issues in the standard
library for which the resolutions could result non-additive API
changes. Having a resolution (and an implementation of the
resolution!) for these issues is blocking API stability.
https://gist.github.com/grib
On Sun, Jul 3, 2016 at 9:20 PM, Brent Royal-Gordon via swift-evolution
wrote:
> 2. Use a tuple/array of `Int`s/`UInts`
>
> Like `String`, this lends itself to becoming variable-width in a later
> version; unlike `String`, it's relatively compact. But also unlike `String`,
> it would be hard to g
On Fri, Jul 1, 2016 at 1:35 PM, Dave Abrahams via swift-evolution
wrote:
> I think if `Syntax.IntegerLiteral` is actually unclear then the best
> cure is `ExpressibleAsIntegerLiteral` (no namespace needed). None of
> the other suggestions I've seen describe what the protocol means as well
> as th
On Fri, Jul 1, 2016 at 12:48 PM, Vladimir.S wrote:
> On 01.07.2016 22:22, Dmitri Gribenko via swift-evolution wrote:
>>
>> On Fri, Jul 1, 2016 at 12:16 PM, Eric Habberstad via swift-evolution
>> wrote:
>>>
>>>
>>> To the Swift community,
>&
On Fri, Jul 1, 2016 at 12:16 PM, Eric Habberstad via swift-evolution
wrote:
>
> To the Swift community,
>
> May I put forth a couple of new names for the following protocol:
>
>
> - CustomStringConvertible — rename as ‘Descriptive’ or as ‘Revealable’
>
>
> Two goals for Swift is clarity and joy
On Wed, Jun 29, 2016 at 4:13 AM, Charles Srstka
wrote:
> On Jun 29, 2016, at 2:50 AM, Dmitri Gribenko via swift-evolution
> wrote:
>
>
> I'm not sure I really want '.url' and '.stringEncoding' on every
> Error. 'var underlying' is universal
On Mon, Jun 27, 2016 at 11:17 AM, Douglas Gregor via swift-evolution
wrote:
> extension ErrorProtocol {
> // Note: for exposition only. Not actual API.
> private var userInfo: [NSObject : AnyObject] {
> return (self as! NSError).userInfo
> }
>
> var localizedDescription: String {
>
On Tue, Jun 28, 2016 at 10:03 PM, David Waite
wrote:
>
> On Jun 28, 2016, at 10:15 PM, Dmitri Gribenko via swift-evolution
> wrote:
>
> On Tue, Jun 28, 2016 at 3:49 PM, David Hart via swift-evolution
> wrote:
>
>
> I am also for removing associated type inference,
On Tue, Jun 28, 2016 at 3:49 PM, David Hart via swift-evolution
wrote:
>
> On 28 Jun 2016, at 20:00, Douglas Gregor via swift-evolution
> wrote:
>
> Well, *I* want to remove associated type inference because I feel that we
> shouldn’t have global inference like this in Swift. I am, however, conce
On Tue, Jun 28, 2016 at 2:17 PM, Andrew Trick wrote:
>
>> On Jun 28, 2016, at 1:53 PM, Dmitri Gribenko wrote:
>>
>> Hi Andy,
>>
>> Everything is clear now, thank you!
>>
>> On Tue, Jun 28, 2016 at 1:02 PM, Andrew Trick wrote:
>>> Initializing via a typed pointer, in addition to changing the temp
Hi Andy,
Everything is clear now, thank you!
On Tue, Jun 28, 2016 at 1:02 PM, Andrew Trick wrote:
> Initializing via a typed pointer, in addition to changing the temporal memory
> state, also imposes a type on the allocated memory for the entire lifetime of
> the memory itself, from allocation
On Tue, Jun 28, 2016 at 9:46 AM, Loïc Lecrenier
wrote:
> I think String’s Views should
> 1. Follow Collection’s documentation by using the same indices for their
> subsequences
> 2. Provide safe, consistent behavior when using a subscript operation with a
> past-the-end index
Hi Loïc,
These ar
Hi Andy,
Thank you for the proposal! A few comments from me.
- In the "Custom memory allocation section" you write:
> Note: The same allocated raw memory cannot be used both for this custom
> memory allocation case and for the C buffer case above because the C buffer
> requries that the alloc
On Fri, Jun 24, 2016 at 10:50 PM, Austin Zheng via swift-evolution
wrote:
> Hello all,
>
> Per Chris Lattner's list of open Swift 3 design topics
> (http://article.gmane.org/gmane.comp.lang.swift.evolution/21369), I've put
> together a proposal for removing type inference for associated types.
Hi
On Fri, Jun 24, 2016 at 2:14 AM, Vladimir.S wrote:
> On 23.06.2016 19:26, Dmitri Gribenko via swift-evolution wrote:
>>
>> On Thu, Jun 23, 2016 at 9:25 AM, James Campbell via swift-evolution
>> wrote:
>>>
>>> So if the function I run inside of the map has a
On Thu, Jun 23, 2016 at 9:25 AM, James Campbell via swift-evolution
wrote:
> So if the function I run inside of the map has a return value of Void will
> that still compile ?
Yes.
Dmitri
--
main(i,j){for(i=2;;i++){for(j=2;j*/
___
swift-evolution mail
On Thu, Jun 23, 2016 at 8:36 AM, James Campbell via swift-evolution
wrote:
> I was wondering if people would be open to adding an unwrap method to the
> Optional type, I already have a method like this which shortens code for
> me.
>
> So this:
>
> let myReallyLongOptionalName: String? = "Hey"
>
On Thu, Jun 23, 2016 at 2:00 AM, Xiaodi Wu wrote:
> On Thu, Jun 23, 2016 at 1:26 AM, David Sweeris via swift-evolution
> wrote:
>>
>>
>> > On Jun 22, 2016, at 19:35, Dmitri Gribenko wrote:
>> >
>> >> On Wed, Jun 22, 2016 at 5:15 PM, David Sweeris
>> >> wrote:
>> >> That's a really interesting i
On Wed, Jun 22, 2016 at 7:42 PM, Matthew Johnson wrote:
>
> On Jun 22, 2016, at 1:55 PM, Dmitri Gribenko wrote:
>
> On Wed, Jun 22, 2016 at 11:04 AM, Erica Sadun via swift-evolution
> wrote:
>
> Proposal:
> https://github.com/apple/swift-evolution/blob/master/proposals/0041-conversion-protocol-c
On Wed, Jun 22, 2016 at 4:43 PM, Matthew Johnson wrote:
>
> On Jun 22, 2016, at 1:55 PM, Dmitri Gribenko wrote:
> protocol _IntegerLiteralSyntax {}
> enum Syntax {
> typealias IntegerLiteral = _IntegerLiteralSyntax
> }
>
> And used like this:
>
> struct Int : Syntax.IntegerLiteral {}
>
>
> Is an
On Wed, Jun 22, 2016 at 5:15 PM, David Sweeris wrote:
> That's a really interesting idea. Is "Syntax" a placeholder, or is that the
> intended name?
It is the best name we could come up with, we are open to better suggestions.
> Also, why an enum? Especially one without any cases...
It is not
On Wed, Jun 22, 2016 at 12:57 PM, David Sweeris wrote:
>
>> On Jun 22, 2016, at 1:55 PM, Dmitri Gribenko via swift-evolution
>> wrote:
>>
>> On Wed, Jun 22, 2016 at 11:04 AM, Erica Sadun via swift-evolution
>> wrote:
>>
>> Hi Erica,
>>
On Wed, Jun 22, 2016 at 11:04 AM, Erica Sadun via swift-evolution
wrote:
> Proposal:
> https://github.com/apple/swift-evolution/blob/master/proposals/0041-conversion-protocol-conventions.md
>
> Rejection: "The feedback on the proposal was generally positive about the
> idea of renaming these proto
On Wed, Jun 22, 2016 at 9:37 AM, Kenny Leung via swift-evolution
wrote:
> Hi All.
>
> In the spirit of Chris’ focus on Swift 3 message…
>
> I’ve been working on calling C code that takes “const char * const *”
> arguments, and it ain’t easy, but that can be left for a future proposal…
>
> What do
On Sat, Jun 18, 2016 at 10:59 PM, Karl wrote:
> What exactly are the guarantees for index safety across mutations? Both
> Collection and Indexable stop short of making any kind of guarantees about
> what happens to indexes after you mutate. For example, popFirst() has the
> potential to invalidate
On Sat, Jun 18, 2016 at 9:09 PM, Karl via swift-evolution
wrote:
> So like most good pitches, this one comes about because of a bug I recently
> fixed which seems common and subtle enough that I think it would be nice to
> include in the standard library.
>
> Removing a collection of elements at
On Sun, Jun 12, 2016 at 3:33 AM, Adrian Zubarev via swift-evolution
wrote:
> Just looked up the current implementation of this:
>
> extension String {
> /// The index type for subscripting a string.
> public typealias Index = CharacterView.Index
>
> /// A type used to represent the number of
On Wed, Jun 8, 2016 at 11:25 PM, Brent Royal-Gordon via
swift-evolution wrote:
> I actually think there *is* a sensible way to define the behavior of a
> throwing `sort(_:)`: you treat the comparison as though it returned `false`
> and continue sorting.
This can create inconsistent sorting pred
On Sun, May 29, 2016 at 11:23 PM, Brent Royal-Gordon via
swift-evolution wrote:
> There are *very* few conformances to Streamable in the standard library—just
> Character, String, and UnicodeScalar. I think that Streamable is for data
> that can be *directly* written to an output stream, whereas
On Wed, May 25, 2016 at 3:42 PM, Leonardo Pessoa wrote:
> On Wednesday, 25 May 2016, Dmitri Gribenko via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>> On Wed, May 25, 2016 at 2:52 PM, David Hart wrote:
>> >
>> >> On 25 May 2016, at 23:47,
On Wed, May 25, 2016 at 2:52 PM, David Hart wrote:
>
>> On 25 May 2016, at 23:47, Dmitri Gribenko wrote:
>>
>> On Wed, May 25, 2016 at 2:43 PM, David Hart via swift-evolution
>> wrote:
>>> Impact on Existing Code
>>>
>>> This is a breaking change that will require conforming types which relied o
On Wed, May 25, 2016 at 2:43 PM, David Hart via swift-evolution
wrote:
> Impact on Existing Code
>
> This is a breaking change that will require conforming types which relied on
> the inference, including in the Standard Library, to explicitly declare
> associated types. A Fix-It could be introduc
I like the direction about creating a unified syntax for current
implementation of existentials and future generalized existentials. I
am concerned about the chosen syntax though, I don't think it reads
right. I read Any as a union type.
var x1: Any // OK, 'x1' can have any dynamic type.
var x2:
On Thu, May 19, 2016 at 6:00 PM, Brent Royal-Gordon via
swift-evolution wrote:
>> I'm posting this on behalf of Dmitri Gribenko, and Max Moiseev, and
>> myself.
>>
>> We would like to accept the proposal with one modification: rather than
>> add an argument label, we'd like to drop the String init
On Sat, May 14, 2016 at 7:45 AM, Daniel Steinberg via swift-evolution
wrote:
> I appreciate your rework on this - I still don’t understand one thing and
> disagree with a second:
>
> (1) I don’t understand what the word “Custom” adds to
> CustomStringRepresentable and CustomDebugStringRepresentabl
On Wed, May 11, 2016 at 2:37 AM, Austin Zheng via swift-evolution
wrote:
> Hello swift-evolution,
>
> I've been thinking about a standard library 'Data' type for a while,
> analogous to NSData in the same way Swift's Arrays and Dictionaries are
> analogous to NSArrays and NSDictionaries. A first-c
On Fri, May 6, 2016 at 2:24 AM, Morten Bek Ditlevsen via
swift-evolution wrote:
> How does that sound? Is it completely irrational to allow the use of Strings
> as
> the intermediary representation of float literals?
> I think that it makes good sense, since it allows for arbitrary precision.
Hi
On Fri, May 6, 2016 at 12:53 AM, Nate Cook wrote:
> That brings up the question of which protocol to add the requirement to?
> Without a MutableBidirectionalProtocol (which we don't want, right?), we'd
> need to add it to MutableCollection. While a mutating reverse() is possible
> for a forward co
On Thu, May 5, 2016 at 5:11 PM, Nate Cook wrote:
> Thanks for the feedback, Dmitri &co, this all looks excellent! I'll work on
> updating the proposal.
>
>> On May 5, 2016, at 6:13 PM, Dmitri Gribenko wrote:
>>
>> On Tue, May 3, 2016 at 8:57 PM, Chris Lattner via swift-evolution
>> wrote:
>>> H
On Tue, May 3, 2016 at 8:57 PM, Chris Lattner via swift-evolution
wrote:
> Hello Swift community,
>
> The review of "SE-0078: Implement a rotate algorithm, equivalent to
> std::rotate() in C++" begins now and runs through May 9.
Hi,
I'm posting this feedback on behalf of Dave Abrahams, Max Mois
On Thu, May 5, 2016 at 3:27 AM, Gwendal Roué wrote:
>>> I quite expect being able to throw out of a @noescape(once) block. Maybe
>>> the sentence "it must not be executed on any path that throws" should be
>>> removed from the proposal, should it have the implications you describe.
>>>
>>> Here
On Wed, May 4, 2016 at 2:24 AM, Gwendal Roué wrote:
>
>> Le 4 mai 2016 à 08:28, Pyry Jahkola via swift-evolution
>> a écrit :
>>
>> Here's my review of "SE-0073: Marking closures as executing exactly once".
>>
>>> What is your evaluation of the proposal?
>>
>> +1. I think this is a good idea and
On Mon, May 2, 2016 at 3:08 PM, Karl via swift-evolution
wrote:
> So, just confirming that the following is going to change:
>
> —
> var string= "test"
> let origLen = 4
> let indexOne = string.startIndex
>
> string.appendContentsOf("ANOTHERTEST")
>
> let indexTwo = indexOne.advancedBy(
On Mon, May 2, 2016 at 9:44 AM, Tony Allevato via swift-evolution
wrote:
> I've written a proposal to formalize some of the discussion that was had
> over in the thread for the `FloatingPoint` protocol proposal regarding
> improvements to operator requirements in protocols that do not require name
On Fri, Apr 29, 2016 at 4:02 AM, David Hart wrote:
> But Collection has to have an extension which explicitly mentions
> IndexingIterator:
>
> extension Collection where Iterator == IndexingIterator {
> /// Returns an iterator over the elements of the collection.
> public func makeIterator
On Fri, Apr 29, 2016 at 1:50 AM, David Hart wrote:
> Hi Dimitri,
>
> Excuse me if I’m being dumb. I saw those example but I don’t understand
> their use.
>
> If I define a custom Collection, I still have the be explicit in the types I
> use where associated types are expected. Because I need to be
On Fri, Apr 29, 2016 at 12:25 AM, David Hart via swift-evolution
wrote:
> I’ve taken some time to digest the current feedback and I’ve changed my mind.
> The syntax for adding constraints to a sub-protocol in the protocol’s
> definition where clause is starting to grow on me. Before I modify the
On Mon, Apr 25, 2016 at 8:28 PM, Douglas Gregor via swift-evolution
wrote:
> Did you consider an alternate syntax that puts the where clause outside the
> braces, e.g.,
>
> protocol R : Q where AssocType : P {
> // …
> }
To me this reads like declaring a conditional conformance.
Dmitri
--
ma
On Sun, Apr 24, 2016 at 1:34 PM, David Hart via swift-evolution
wrote:
> Currently, associated type declarations can only express simple inheritance
> constraints and not the more sophisticated constraints available to generic
> types with the where expression. Some designs, including many in the
On Sun, Apr 17, 2016 at 11:10 AM, Matthew Johnson via swift-evolution
wrote:
> These extension points are effectively “optional protocol requirements”.
I'm sorry, but they are not optional requirements. They are
workarounds for a language issue -- inability to make
conditionally-available method
On Sun, Apr 17, 2016 at 11:14 PM, Thorsten Seitz wrote:
> Preventing indices of one collection being used by another collection can be
> done by using path dependent types like in Scala.
>
> Then 'i' would have type a.Index (where 'a' is the instance!) and therefore
> b[i] would not typecheck as
On Sat, Apr 16, 2016 at 11:50 PM, Taras Zakharko via swift-evolution
wrote:
> Hi Nate,
>
> I think this is a very useful addition! I also had a related proposal few
> days ago:
> https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160411/014665.html
>
> I feel like min/max extension
On Fri, Apr 15, 2016 at 1:30 PM, Stephan Tolksdorf wrote:
> On 2016-04-12 Dmitri Gribenko via swift-evolution wrote:
>>
>> Not even to mention that
>> indices are valid only in context of a particular collection instance,
>> so in this model you could validate an i
On Tue, Apr 12, 2016 at 8:46 PM, plx via swift-evolution
wrote:
>
> On Apr 12, 2016, at 6:11 PM, Haravikk wrote:
>
> I’m a +1 for the proposal (but as I’ve implemented a bunch of collections
> recently I’m not sure I’m looking forward to having to update my code to
> reflect the new pattern ;)
>
On Tue, Apr 12, 2016 at 4:27 AM, Brent Royal-Gordon
wrote:
>>> (On the other hand, it might be that I'm conceiving of the purpose of
>>> `limitedBy` differently from you—I think of it as a safety measure, but you
>>> may be thinking of it specifically as an automatic truncation mechanism.)
>>
>>
On Mon, Apr 11, 2016 at 9:56 PM, Brent Royal-Gordon via
swift-evolution wrote:
> (On the other hand, it might be that I'm conceiving of the purpose of
> `limitedBy` differently from you—I think of it as a safety measure, but you
> may be thinking of it specifically as an automatic truncation mec
On Mon, Apr 11, 2016 at 9:56 PM, Brent Royal-Gordon via
swift-evolution wrote:
> So, imagine that we have a type like this in the standard library:
>
> /// Represents a pre-validated index. A pre-validated index received
> from a given collection is
> /// guaranteed to refer to a
On Tue, Apr 12, 2016 at 1:55 AM, Yogev Sitton via swift-evolution
wrote:
> Map is great for transforming an array of objects - it is very useful and I
> use it a lot.
> I would love to use Map with Dictionaries and other collections as well.
>
> As an example - let’s say I have a dictionary [Stri
On Mon, Apr 11, 2016 at 9:20 AM, Dmitri Gribenko wrote:
> Hi,
>
> On Mon, Apr 11, 2016 at 9:16 AM, Gwendal Roué
> wrote:
>> Will it still be possible with the new protocol and types? Especially, how
>> to I generate "BETWEEN 0 AND 17" from 0..<18 without a supporting collection
>> that gives m
Hi,
On Mon, Apr 11, 2016 at 9:16 AM, Gwendal Roué wrote:
> Will it still be possible with the new protocol and types? Especially, how to
> I generate "BETWEEN 0 AND 17" from 0..<18 without a supporting collection
> that gives me the predecessor of 18?
You would either design your API to accept
On Sun, Apr 10, 2016 at 4:16 PM, Jacob Bandes-Storch via
swift-evolution wrote:
> Minor questions after initial read-through:
>
> - Should the comment on {index,formIndex}(_:stepsFrom:) say what happens if
> the resulting index would be out of bounds?
Yes, we should make that clear. The answer i
1 - 100 of 142 matches
Mail list logo
