Re: [swift-evolution] extending typealiases

+1 from me, it seems like a sensible improvement (albeit not a pressing one, as others have noted). ___ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Strings in Swift 4

> On Feb 5, 2017, at 2:57 PM, Ted F.A. van Gaalen wrote: > > However, that is not the case with UTF-32, because with UTF-32 encoding > each character has a fixed-width and always occupies exactly 4 bytes, 32 bit. > Ergo: the problem can be easily solved: The simple

Re: [swift-evolution] [Discussion] mailing list alternative

+1 Its really hard to keep track of mails and threads. Sent from my iPhone > On Jan 23, 2017, at 18:59, Joshua Alvarado via swift-evolution > wrote: > > It will be painted! ;) > > So far we have: > +2 Disclosure > +1 Slack > +1 Issue tracker > > Let's really get

Re: [swift-evolution] Removing enumerated?

> On Feb 5, 2017, at 16:47, Patrick Pijnappel > wrote: > > Note that zip(a.indices, a) requires advancing the index twice each > iteration, which for non-array collections is not necessarily super trivial. > Considering we're talking about such a low-level

Re: [swift-evolution] Compile-time generic specialization

Hi Robert, Exactly. The benefit being that you can figure out the correct function to dispatch entirely at compile time. My understanding is that Swift doesn’t do this because of the associated code bloat (and it’s usually not necessary). However, I think there is some important functionality

Re: [swift-evolution] define backslash '\' as a operator-head in the swift grammar

IIRC, where we left the discussion last time was that there was work not yet complete within Unicode on delineating identifier and operator characters. As there was broad agreement to align identifier characters with Unicode standards, and since the strict separation between identifiers and

Re: [swift-evolution] define backslash '\' as a operator-head in the swift grammar

+1 from me. I hope that operators get more work soon, especially with regard to math. On Sun, Feb 5, 2017 at 5:09 PM, Nevin Brackett-Rozinsky via swift-evolution wrote: > +1 as well. I also support adding these four symbols: ⅀ ؆ ؇ ⅋ as > operators. > > There was

Re: [swift-evolution] Removing enumerated?

Note that zip(a.indices, a) requires advancing the index twice each iteration, which for non-array collections is not necessarily super trivial. Considering we're talking about such a low-level operation as iterating through a collection this might be worth considering. Personally I'm in favor of

Re: [swift-evolution] Subclass Existentials

As they are heavily linked, should a change like this be included in the superclass + class proposal or separately? I'm heavily tending towards (1), and redefining: typealias Any = Any<> typealias AnyObject = Any Does that sound reasonable to you? Just checking before I rewrite this proposal

Re: [swift-evolution] define backslash '\' as a operator-head in the swift grammar

+1 as well. I also support adding these four symbols: ⅀ ؆ ؇ ⅋ as operators. There was substantial discussion last fall about revamping operators in Swift, with the primary goal of removing characters that should not be in the set. I went through the Unicode tables and compiled a list of 1,020

Re: [swift-evolution] Checking in; more thoughts on arrays and variadic generics

> On 29 Jan 2017, at 00:16, Slava Pestov wrote: > >> >> On Jan 27, 2017, at 4:55 PM, Karl Wagner > > wrote: >> >> >>> On 27 Jan 2017, at 22:25, Slava Pestov >> > wrote: >>> >>>

Re: [swift-evolution] Checking in; more thoughts on arrays and variadic generics

> On Jan 30, 2017, at 7:45 AM, Tino Heth <2...@gmx.de> wrote: > > > Arrays are one of the most basic concepts in programming, so I don't want to > mix them with tuples - especially as there is a clean alternative (there are > still some pieces missing, but "Vector" looks much > better than

Re: [swift-evolution] Checking in; more thoughts on arrays and variadic generics

> On Jan 27, 2017, at 4:25 PM, Slava Pestov wrote: > > >> On Jan 27, 2017, at 11:44 AM, Karl Wagner via swift-evolution >> > wrote: >> > > >> as would CollectionOfOne, to be replaced by a single-element tuple

Re: [swift-evolution] Checking in; more thoughts on arrays and variadic generics

> On Jan 27, 2017, at 11:55 AM, Robert Widmann wrote: > > > ~Robert Widmann > > 2017/01/26 13:37、Daryle Walker > > のメッセージ: > >> >> strideof( ArrayType ) == Element-Count * strideof( ElementType ) >> >> down to the

Re: [swift-evolution] Checking in; more thoughts on arrays and variadic generics

> On Jan 27, 2017, at 11:55 AM, Robert Widmann wrote: > > > > ~Robert Widmann > > 2017/01/26 13:37、Daryle Walker > > のメッセージ: > >> >>> On Jan 23, 2017, at 3:33 PM, Robert Widmann >>

Re: [swift-evolution] Shouldn't ".withUnsafeBufferPointer" and ".withUnsafeMutableBufferPointer" be parts of protocols?

> On Jan 27, 2017, at 7:36 PM, Zach Waldowski via swift-evolution > wrote: > > I like the sound of it so far, but my first major thought is that isn't it > modeling a "has-a" relationship instead of an "is-a"? The buffer methods > indicate that the data type *can*

Re: [swift-evolution] Compile-time generic specialization

Oh, I see. The constraint solver is picking an overload that better matches the caller rather than the callee's type, which differs from C++ because the template expansion process considers specific-type overloads more specific. We don't consider less-generic prototypes than the caller here

Re: [swift-evolution] Shouldn't ".withUnsafeBufferPointer" and ".withUnsafeMutableBufferPointer" be parts of protocols?

> On Jan 27, 2017, at 7:24 PM, Karl Wagner wrote: > > There is a bug tracking this: > > https://bugs.swift.org/browse/SR-3631 Saw it. Joined Swift-JIRA. Posted my comments. — Daryle Walker Mac, Internet, and Video Game Junkie

Re: [swift-evolution] Strings in Swift 4

> On Feb 5, 2017, at 02:22, Jonathan Hull via swift-evolution > wrote: > > Just out of curiosity, what are the use-cases for an infinite sequence > (as opposed to a sequence which is bounded to the type’s representable > values)? 1. The type

Re: [swift-evolution] Default Generic Arguments

The proposal has been refactored to include all the things we have discussed here. Thanks everyone for your feedback. If I've missed something, please shout. On Wed, Feb 1, 2017 at 7:35 AM, Srđan Rašić wrote: > Hah, did I really do that :( I completely missed the fact

Re: [swift-evolution] Compile-time generic specialization

I don't understand how this change would cause method dispatch to invoke a different prototype. Specialization in either language mentioned doesn't do that. ~Robert Widmann 2017/02/05 11:28、Abe Schneider via swift-evolution のメッセージ: > Hi all, > > The current

[swift-evolution] Compile-time generic specialization

Hi all, The current behavior of generics in Swift causes it lose type information at compile time due to the desire of maintaining a single version of the function. This runs counter to how c++ works, which creates a new copy of a function per type, but preserves information to be preserved.

Re: [swift-evolution] define backslash '\' as a operator-head in the swift grammar

Well you cannot define it because the \ character itself is not allowed outside of a string. If you try to declare it with infix operator \ you get an error "Invalid character in source file" in Xcode and where you define the function itself you have the same error. This would not happen if

Re: [swift-evolution] Removing enumerated?

On Feb 5, 2017, at 08:12, Ben Cohen wrote: >> On Feb 4, 2017, at 14:43, Dave Abrahams via swift-evolution >> wrote: >> >> >> on Fri Feb 03 2017, Ben Cohen wrote: >> On Feb 3, 2017, at 3:27 PM, Dave Abrahams via

Re: [swift-evolution] Removing enumerated?

> On Feb 4, 2017, at 14:43, Dave Abrahams via swift-evolution > wrote: > > > on Fri Feb 03 2017, Ben Cohen wrote: > >>> On Feb 3, 2017, at 3:27 PM, Dave Abrahams via swift-evolution >>> wrote: >>> >>> I don't

Re: [swift-evolution] define backslash '\' as a operator-head in the swift grammar

If the \ operator is not defined in swift, does it treat it as something that can be operator overloaded? On Sun, Feb 5, 2017 at 10:29 AM Nicolas Fezans via swift-evolution < swift-evolution@swift.org> wrote: > Dear all, > > This is a rather simple proposal to add '\' (backslash character) as a

[swift-evolution] define backslash '\' as a operator-head in the swift grammar

Dear all, This is a rather simple proposal to add '\' (backslash character) as a valid operator-head in the swift grammar. One argument for it, is that there exist a backslash operator in the MATLAB/Scilab/Octave languages. In this languages A\B solves the linear system A*X = B for X (or the

Re: [swift-evolution] Strings in Swift 4

Just out of curiosity, what are the use-cases for an infinite sequence (as opposed to a sequence which is bounded to the type’s representable values)? >>> >>> 1. The type may not have an inherent expressible bound (see BigInt, >>> UnsafePointer, and *many* real-life Index types).