Re: [swift-evolution] SE-184 Improved Pointers

actually never mind that, UnsafeMutablePointer should be the only type to not support at: arguments since offsetting them is easy with +. > On Aug 20, 2017, at 12:12 AM, Taylor Swift via swift-evolution > wrote: > > > >> On Sat, Aug 19, 2017 at 10:28 PM, Andrew

Re: [swift-evolution] Pitch: Cross-module inlining and specialization

Is this only a problem with fileprivate or does it extend to private members too? I feel like this would be a very valuable feature to support. On Mon, Oct 2, 2017 at 9:43 PM, Slava Pestov wrote: > It would be a trivial change to allow @_versioned on private and > fileprivate

Re: [swift-evolution] SE-1084 (B): buffer pointer partial initialization API

On Tue, Oct 10, 2017 at 1:00 AM, Xiaodi Wu <xiaodi...@gmail.com> wrote: > On Mon, Oct 9, 2017 at 19:47 Kelvin Ma via swift-evolution < > swift-evolution@swift.org> wrote: > >> Hi guys, after passing SE 184 (A) >> <https://github.com/apple/swift-evolution/blob/m

Re: [swift-evolution] SE-1084 (B): buffer pointer partial initialization API

Begemann <o...@oleb.net> wrote: > > On 12. Oct 2017, at 01:17, Kelvin Ma via swift-evolution < > swift-evolution@swift.org> wrote: > > On Wed, Oct 11, 2017 at 6:06 PM, Nevin Brackett-Rozinsky brackettrozin...@gmail.com> wrote: > >> On Wednesday, October

Re: [swift-evolution] commas optional

a semicolon is a purely syntactic delimiter, the comma on the other hand corresponds to physical elements in a collection. I think the two are more different than you suggest. On Thu, Oct 12, 2017 at 1:50 PM, Dave Yost via swift-evolution < swift-evolution@swift.org> wrote: > > Speaking as a

Re: [swift-evolution] commas optional

On Thu, Oct 12, 2017 at 6:20 PM, Xiaodi Wu wrote: > On Thu, Oct 12, 2017 at 2:47 PM, Jarod Long via swift-evolution < > swift-evolution@swift.org> wrote: > >> I don't really expect this sort of syntactic sugar to be popular enough >> to make it through swift-evolution, and I

Re: [swift-evolution] [Draft] Rename Sequence.elementsEqual

I’ve always hated the use of the word “lexicographically” in that method 1) because lexicographically is hard to spell, and 2) because it’s weird to say that an unordered collection has a lexicographical order. But this change is probably for the best. On Thu, Oct 12, 2017 at 6:24 PM, Xiaodi Wu

[swift-evolution] SE-1084 (B): buffer pointer partial initialization API

Hi guys, after passing SE 184 (A) , I want to get some community feedback on the next phase of our Swift pointer overhaul which is a partial initialization/deinitialization API for

Re: [swift-evolution] SE-1084 (B): buffer pointer partial initialization API

On Wed, Oct 11, 2017 at 6:06 PM, Nevin Brackett-Rozinsky < nevin.brackettrozin...@gmail.com> wrote: > On Wednesday, October 11, 2017, Kelvin Ma via swift-evolution < > swift-evolution@swift.org> wrote: > >> Yes, a 0-ary operator like that would have to be hard baked

Re: [swift-evolution] SE-1084 (B): buffer pointer partial initialization API

ted as part of 4.0. >>> >>> https://github.com/apple/swift-evolution/blob/master/proposa >>> ls/0172-one-sided-ranges.md >>> >>> >>> Regards >>> Anders >>> >>> > On 11 Oct 2017, at 4:43 AM, Kelvin Ma via swift-

Re: [swift-evolution] SE-1084 (B): buffer pointer partial initialization API

; >> https://github.com/apple/swift-evolution/blob/master/proposa >> ls/0172-one-sided-ranges.md >> >> >> Regards >> Anders >> >> > On 11 Oct 2017, at 4:43 AM, Kelvin Ma via swift-evolution < >> swift-evolution@swift.org> wrote: >> > &

Re: [swift-evolution] [SPM] Roadmap?

Since this list is dominated by iDevice developers, as a Linux support advocate I’d like to see better support for including and linking C libraries (please no more shim hacks), and a swift test command that can execute arbitrary testing code. Since library ABI is something that we’re trying to

Re: [swift-evolution] [swift-dev] Forums for swift.org workgroup: looking for volunteers

im willing to help! On Wed, Nov 15, 2017 at 6:01 PM, Wallacy via swift-evolution < swift-evolution@swift.org> wrote: > I will be on vacation after December 1, so I will have some time to help > if needed. > Em qua, 15 de nov de 2017 às 21:39, Nicole Jacque via swift-dev < > swift-...@swift.org>

Re: [swift-evolution] Synthesizing Equatable, Hashable, and Comparable for tuple types

On Tue, Nov 28, 2017 at 3:18 AM, Xiaodi Wu wrote: > > On Tue, Nov 28, 2017 at 00:32 Kelvin Ma wrote: > >> On Mon, Nov 27, 2017 at 9:43 PM, Xiaodi Wu wrote: >> >>> On Mon, Nov 27, 2017 at 5:56 PM, Kelvin Ma

Re: [swift-evolution] Synthesizing Equatable, Hashable, and Comparable for tuple types

; On Nov 20, 2017, at 5:43 PM, Chris Lattner via swift-evolution < > swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: > >>> > >>> > >>>> On Nov 20, 2017, at 5:39 PM, Kelvin Ma via swift-evolution < > swift-evolution@sw

Re: [swift-evolution] Synthesizing Equatable, Hashable, and Comparable for tuple types

On Mon, Nov 27, 2017 at 9:43 PM, Xiaodi Wu wrote: > On Mon, Nov 27, 2017 at 5:56 PM, Kelvin Ma wrote: > >> >> >> On Mon, Nov 27, 2017 at 4:21 PM, Xiaodi Wu wrote: >> >>> On Mon, Nov 27, 2017 at 15:46 Taylor Swift

Re: [swift-evolution] [Pitch] Raw mode string literals

On Thu, Nov 23, 2017 at 3:47 PM, Tony Allevato via swift-evolution < swift-evolution@swift.org> wrote: > > > On Thu, Nov 23, 2017 at 12:21 PM Xiaodi Wu via swift-evolution < > swift-evolution@swift.org> wrote: > >> On Thu, Nov 23, 2017 at 2:14 PM, John Holdsworth via swift-evolution < >>

Re: [swift-evolution] Synthesizing Equatable, Hashable, and Comparable for tuple types

On Thu, Nov 23, 2017 at 12:32 PM, Tino Heth <2...@gmx.de> wrote: > > a good idea on paper, a disastrous one in practice. What happens if every > geometry library declares their own Point type? > > That would be ugly („disastrous“ imho is a little bit to strong — C++ > had/has similar issues, and

Re: [swift-evolution] Synthesizing Equatable, Hashable, and Comparable for tuple types

On Thu, Nov 23, 2017 at 5:45 PM, Kelvin Ma wrote: > > > On Thu, Nov 23, 2017 at 12:32 PM, Tino Heth <2...@gmx.de> wrote: > >> >> a good idea on paper, a disastrous one in practice. What happens if every >> geometry library declares their own Point type? >> >> That would be

Re: [swift-evolution] [Pitch] Raw mode string literals

aren’t all literals evaluated at compile time? On Thu, Nov 23, 2017 at 6:07 PM, Tony Allevato wrote: > This could be solved by extending the existing string literal handling and > letting type inference do the rest. The real problem here is that > `UInt8(ascii: X)` is

Re: [swift-evolution] Synthesizing Equatable, Hashable, and Comparable for tuple types

On Thu, Nov 23, 2017 at 7:08 PM, Xiaodi Wu <xiaodi...@gmail.com> wrote: > > On Thu, Nov 23, 2017 at 16:45 Kelvin Ma via swift-evolution < > swift-evolution@swift.org> wrote: > >> >> >> On Thu, Nov 23, 2017 at 12:32 PM, Tino Heth <2...@gmx.de> wrot

Re: [swift-evolution] Synthesizing Equatable, Hashable, and Comparable for tuple types

upported case outweigh the additional language opacity. >> >> >> I understand your goal, but that compiler magic can’t exist until there >> is something to hook it into. Tuples can’t conform to protocols right now, >> so there is nothing that can be synthesized. >&

Re: [swift-evolution] Synthesizing Equatable, Hashable, and Comparable for tuple types

017, at 5:39 PM, Kelvin Ma via swift-evolution < > swift-evolution@swift.org> wrote: > > when SE-185 > <https://github.com/apple/swift-evolution/blob/master/proposals/0185-synthesize-equatable-hashable.md> > went through swift evolution, it was agreed that the next logic

[swift-evolution] Synthesizing Equatable, Hashable, and Comparable for tuple types

when SE-185 went through swift evolution, it was agreed that the next logical step is synthesizing these conformances for

Re: [swift-evolution] Synthesizing Equatable, Hashable, and Comparable for tuple types

a good idea on paper, a disastrous one in practice. What happens if every geometry library declares their own Point type? On Tue, Nov 21, 2017 at 1:15 AM, Thorsten Seitz <tseit...@icloud.com> wrote: > > > Am 21.11.2017 um 02:39 schrieb Kelvin Ma via swift-evolution < > swif

Re: [swift-evolution] “Integer” protocol?

On Wed, Nov 1, 2017 at 12:15 PM, Xiaodi Wu via swift-evolution < swift-evolution@swift.org> wrote: > On Wed, Nov 1, 2017 at 07:24 Daryle Walker wrote: > >> >> >> Sent from my iPad >> >> On Oct 31, 2017, at 10:55 PM, Xiaodi Wu wrote: >> >> Right, these

Re: [swift-evolution] f suffix for float32 literals, h suffix for float16 literals

On Fri, Nov 3, 2017 at 2:05 PM, Steve Canon via swift-evolution < swift-evolution@swift.org> wrote: > If/when 16b floats were added to the standard lib, you would just write: > > let vertexData: [Float16] = [ 1, 0, 0.5, 1 ] > > I should note that something like vertex coordinates is usually

Re: [swift-evolution] [SPM] Roadmap?

On Mon, Nov 6, 2017 at 1:00 PM, Rick Ballard via swift-evolution < swift-evolution@swift.org> wrote: > > On Oct 23, 2017, at 10:41 AM, Jean-Christophe Pastant via swift-evolution < > swift-evolution@swift.org> wrote: > > Hi, > > Is there any news about features that are willling to be integrated

Re: [swift-evolution] Pitch: Remove default initialization of optional bindings

hot take: i use the second one a lot but only because i always forget the first one exists. So I type the = nil just to “be sure”. On Mon, Nov 6, 2017 at 4:33 PM, Slava Pestov via swift-evolution < swift-evolution@swift.org> wrote: > Hi all, > > Right now, the following two declarations are

Re: [swift-evolution] Large Proposal: Non-Standard Libraries

inlining / specialization) > - A list of discussion (or a forum?) for people that maintain (or have an > interest in maintain) projects in this "official" list. > > I vote for empowering SwiftPM and Compatibility Suite instead a > "Non-Standard Libraries". > &

Re: [swift-evolution] Large Proposal: Non-Standard Libraries

On Tue, Nov 7, 2017 at 3:15 PM, Félix Fischer wrote: > On Tue, Nov 7, 2017 at 5:24 PM Wallacy wrote: > >> The Compatibility Suite is a good start, but I agree that something a >> bit more centralized has its benefits. >> >> To be perfect, Compatibility

Re: [swift-evolution] Large Proposal: Non-Standard Libraries

On Thu, Nov 9, 2017 at 12:11 AM, Ted Kremenek wrote: > > > On Nov 8, 2017, at 12:08 PM, Kelvin Ma wrote: > > > > On Wed, Nov 8, 2017 at 1:58 PM, Ted Kremenek via swift-evolution < > swift-evolution@swift.org> wrote: > >> >> >> On Nov 8, 2017, at 11:40

Re: [swift-evolution] Large Proposal: Non-Standard Libraries

i’m not one to applaud everything go does but its extended standard library seems nice On Thu, Nov 9, 2017 at 2:24 AM, Nick Keets via swift-evolution < swift-evolution@swift.org> wrote: > I think there are two ideas discussed in this thread at the same time. One > is for a more extended standard

Re: [swift-evolution] Large Proposal: Non-Standard Libraries

On Thu, Nov 9, 2017 at 1:49 AM, Chris Lattner via swift-evolution < swift-evolution@swift.org> wrote: > > > On Nov 7, 2017, at 5:54 PM, Dave DeLong via swift-evolution < > swift-evolution@swift.org> wrote: > > > > Hi Swift-Evolution, > > > > The Standard Library's goal is to be small and

Re: [swift-evolution] Large Proposal: Non-Standard Libraries

On Thu, Nov 9, 2017 at 12:37 PM, Wallacy via swift-evolution < swift-evolution@swift.org> wrote: > > > Em qui, 9 de nov de 2017 às 03:42, Ted Kremenek > escreveu: > >> These are some really interesting analogies. How would you imagine the >> community “governance” of these

Re: [swift-evolution] Large Proposal: Non-Standard Libraries

Glad to see people working on this! I already have a functioning almost-pure Swift PNG library , and a JPEG library is a month or two away. I’m glad someone is hacking away at some sort of rasterization engine (like cairo for

Re: [swift-evolution] Large Proposal: Non-Standard Libraries

On Wed, Nov 8, 2017 at 1:58 PM, Ted Kremenek via swift-evolution < swift-evolution@swift.org> wrote: > > > On Nov 8, 2017, at 11:40 AM, Ted Kremenek via swift-evolution < > swift-evolution@swift.org> wrote: > > > > On Nov 8, 2017, at 4:30 AM, Wallacy via swift-evolution < >

Re: [swift-evolution] Large Proposal: Non-Standard Libraries

This is something I have been pushing for for some time now and I am glad to see some more force behind it. There are multiple prior threads about this topic you should probably familiarize yourselves with for background: https://lists.swift.org/pipermail/swift-evolution/

Re: [swift-evolution] Large Proposal: Non-Standard Libraries

On Tue, Nov 7, 2017 at 12:18 PM, Félix Fischer via swift-evolution < swift-evolution@swift.org> wrote: > Hmm. I kind of like the idea, but not really. I think it has a fundamental > flaw: centralization. > > You see, the StdLib can be commanded by a central authority (the core > team) and hear

Re: [swift-evolution] Large Proposal: Non-Standard Libraries

On Tue, Nov 7, 2017 at 1:11 PM, Félix Fischer wrote: > > On Tue, Nov 7, 2017 at 4:01 PM Kelvin Ma wrote: > >> On Tue, Nov 7, 2017 at 12:18 PM, Félix Fischer via swift-evolution < >> swift-evolution@swift.org> wrote: >> >>> Hmm. I kind of like the idea,

Re: [swift-evolution] constant var

here’s the problem. if your type is an inline type (ie a struct or an enum), modifying a member of your object is really modifying part of the entire variable. so, declaring the variable as let makes no sense. if your type is an indirect type (a class), modifying a member of your object is really

Re: [swift-evolution] Proposal and Timeline for Discourse Transition

On Tue, Dec 12, 2017 at 5:31 AM, Alejandro Martinez via swift-evolution < swift-evolution@swift.org> wrote: > This sounds great! > Specially the new structure, it reminds me of the Rust forums. I just > have one question, is the Using Swift category expected to be the one > where the community

Re: [swift-evolution] Standard error?

This has been on my wishlist for a long time and I don’t think it’s in the Swift stdlib. You have to import Darwin/Glibc. On Wed, Oct 25, 2017 at 3:51 PM, Daryle Walker via swift-evolution < swift-evolution@swift.org> wrote: > Been looking at the Swift standard library pages at Apple’s website.

Re: [swift-evolution] Pitch: Member lookup on String should not find members of NSString

I don’t think anyone is really looking at that at the time but +1 to bringing NSString functionality to String. This is something that gets talked about a lot but no one has really sat down to outline what such an API would look like. On Wed, Oct 25, 2017 at 3:24 PM, David Hart via

Re: [swift-evolution] Making capturing semantics of local functions explicit

i support this™ On Wed, Oct 25, 2017 at 6:41 AM, David Hart via swift-evolution < swift-evolution@swift.org> wrote: > I got bit again by a sneaky memory leak concerning local functions and > would like to discuss a small language change. I vaguely remember this > being discussed in the past, but

Re: [swift-evolution] stack classes

I’m highly supportive of this, but this pitch is incomplete. Unless we restrict stack-classes to be non-escaping, and non copyable, at the minimum we need to force the user to implement a copy initializer as well as deinit. If we also want to support moves, this could make the compiler diagnostics

Re: [swift-evolution] [REVIEW] SE-0193 - Cross-module inlining and specialization

that’s why i keep saying we should separate human-facing encapsulation concepts from compiler-facing abi visibility concepts. i’ve always been advocating for something like internal(visible) fileprivate(visible) private(visible) in the same spelling we currently use for stuff like private(set).

Re: [swift-evolution] namespacing protocols to other types

2017, at 03:56, Slava Pestov via swift-evolution < > swift-evolution@swift.org> wrote: > > There was a proposal to allow protocols to be nested inside types at one > point but it didn’t move forward. > > Basically, if the outer type is a non-generic class,

Re: [swift-evolution] namespacing protocols to other types

ould be a > better approach than trying to name-space within a module? > > Regards, > Eneko Alonso > > On Dec 29, 2017, at 16:51, Kelvin Ma via swift-evolution < > swift-evolution@swift.org> wrote: > > …all i wanted to do was write Thing:Namespace.Protocol > >

Re: [swift-evolution] namespacing protocols to other types

makes modules > ineffective as a namespacing scheme. > > On Fri, Dec 29, 2017 at 8:35 PM, Eneko Alonso <eneko.alo...@gmail.com> > wrote: > >> …all i wanted to do was write Thing:Namespace.Protocol >> >> >> Have you thought of using Swift modules for tha

Re: [swift-evolution] [REVIEW] SE-0193 - Cross-module inlining and specialization

why can’t we just remove inlineable functions from ABI altogether? if the argument is that app code won’t be able to take advantage of improved implementations in future library versions i don’t think that makes sense at all i would assume client code gets recompiled much more often than library

Re: [swift-evolution] [REVIEW] SE-0193 - Cross-module inlining and specialization

than the library version. On Sun, Dec 24, 2017 at 9:59 PM, Slava Pestov <spes...@apple.com> wrote: > > > On Dec 24, 2017, at 4:00 PM, Kelvin Ma via swift-evolution < > swift-evolution@swift.org> wrote: > > why can’t we just remove inlineable functions from ABI

[swift-evolution] namespacing protocols to other types

is there a reason why it’s not allowed to nest a protocol declaration inside another type? ___ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] namespacing protocols to other types

c = Conforms() > > c is Generic.P // is this false? Ie, are Generic.P and > Generic.P different protocols? > > > > Slava > > > >> On Dec 24, 2017, at 6:53 PM, Kelvin Ma via swift-evolution < > swift-evolution@swift.org> wrote: > >> > &g

Re: [swift-evolution] [REVIEW] SE-0193 - Cross-module inlining and specialization

han the library version. > > On Sun, Dec 24, 2017 at 9:59 PM, Slava Pestov <spes...@apple.com> wrote: > >> >> >> On Dec 24, 2017, at 4:00 PM, Kelvin Ma via swift-evolution < >> swift-evolution@swift.org> wrote: >> >> why can’t we just re

Re: [swift-evolution] [REVIEW] SE-0193 - Cross-module inlining and specialization

t; device grow old though. > > Le 25 déc. 2017 à 05:46, Kelvin Ma via swift-evolution < > swift-evolution@swift.org> a écrit : > > in theory this could happen but if you ask me this is such an exceedingly > rare case that i don’t count much net benefit from it. most ithing users &

Re: [swift-evolution] [Pitch] Angle Type

This could work, but you’re also giving up all the nice Numeric and FloatingPoint conformances when you use this,, all of a sudden adding two angles together isn’t let γ = α + β, it’s γ = Angle.radians(α.radians + β.radians). just no. at the risk of blowing up the scope of this idea, dedicated

Re: [swift-evolution] [Proposal] Random Unification

On Tue, Jan 9, 2018 at 5:12 AM, Jonathan Hull via swift-evolution < swift-evolution@swift.org> wrote: > Some thoughts: > > - How do I randomly select an enum? > carefully, of course > > - I like that RandomNumberGenerator doesn’t have an associated type. I > agree that we should just spit out

Re: [swift-evolution] [swift-evolution-announce] [Review] SE 0192 - Non-Exhaustive Enums

On Tue, Jan 2, 2018 at 11:45 PM, Nevin Brackett-Rozinsky via swift-evolution wrote: > On Tue, Jan 2, 2018 at 9:07 PM, Jordan Rose via swift-evolution < > swift-evolution@swift.org> wrote: > >> [Proposal: https://github.com/apple/swift-evolution/blob/mas >>

Re: [swift-evolution] Should we incorporate bunches of new operators / micro-syntactic sugar?

possibly off-topic but what i would really find useful is some way of expressing guard/if assignment instead of initialization so that let geomSource:UnsafeMutableBufferPointer? if let geometryFile:String = geometryFile { guard let

Re: [swift-evolution] [REVIEW] SE-0193 - Cross-module inlining and specialization

On Thu, Dec 21, 2017 at 12:26 AM, Slava Pestov <spes...@apple.com> wrote: > Thanks for the review, Kelvin. > > On Dec 20, 2017, at 8:52 PM, Kelvin Ma via swift-evolution < > swift-evolution@swift.org> wrote: > > it makes sense to have @abiPublic on private and filepr

Re: [swift-evolution] [REVIEW] SE-0193 - Cross-module inlining and specialization

glad to see this finally moving forward! On Wed, Dec 20, 2017 at 6:19 PM, Ted Kremenek via swift-evolution < swift-evolution@swift.org> wrote: > The review of "SE-0193 - Cross-module inlining and specialization" begins > now and runs through *January 5, 2018*. > > The proposal is available here:

[swift-evolution] why cant you initialize BinaryFloatingPoint from BinaryInteger?

title says it all,, this is kind of annoying when writing some generic FloatingPoint code where both the integral and floating parameters are unfixed. ___ swift-evolution mailing list swift-evolution@swift.org

Re: [swift-evolution] [swift-users] Happy new year Swift community.

Happy new year from klossyland! On Mon, Jan 1, 2018 at 11:23 AM, Georgios Moschovitis via swift-users < swift-us...@swift.org> wrote: > Happy new year! Greetings from Cyprus :) > > George. > > On 1 Jan 2018, at 1:42 AM, Adrian Zubarev via swift-users < > swift-us...@swift.org> wrote: > > Well