[swift-evolution] Pure functions

Should we add support for recognition of pure functions? These functions don’t refer to any global state; their return values / outgoing in-out parameter states depend solely on the incoming argument values. I know at least the D programming language acknowledges them. - Should they be

[swift-evolution] No disjunctions in type constraints: why?

>From >. Maybe I’m not up on my Type Theory, but why should type constraint disjunctions be banned? — Daryle Walker Mac, Internet, and Video Game Junkie darylew AT mac DOT com

[swift-evolution] [Pre-Pitch] Another go at "strong typedef" / alternative types / reduced-state types

(Warning: rambling stream-of-conscious mode while slightly tired) The names of new keywords and identifiers are subject to bike-shedding. 1. Set-up Protocols protocol HardRawRepresentable: RawRepresentable { init(rawValue: RawValue) } Just like RawRepresentable, but the initializer has to

[swift-evolution] [Potential Idea] How to indicate a trivial strong-typedef?

Here’s a quick review of a strong-“typedef” idea I’ve mentioned here: typecopy MyNewType: OriginalValueType, AnyProtocolsIWant { // Direct member declarations // “publish MemberFromOriginalType” for all overloads (or the singular item for non-functions) // “publish

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

t for the reference. There was a lengthy discussion here in the mailing >> list back when the proposal was introduced: >> https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170109/thread.html#30191 >> >> Max >> >>> On Oct 31, 2017, at 5:15 PM,

[swift-evolution] “Integer” protocol?

Looking at Apple’s Swift (4) docs at their SDK site, shouldn’t there be an “Integer” protocol between Numeric and BinaryInteger? Without that, there’s no solution for Integer types that are either a non-binary radix or a non-radix system (besides being over-broad with Numeric). What would move

[swift-evolution] Standard error?

Been looking at the Swift standard library pages at Apple’s website. There’s “print” and “readLine” for I/O to/from standard output/input. Put there seems to be no function for standard error. The “print” function has an overload for custom streams, but there doesn’t seem to be an object that

[swift-evolution] Find/split on sub-string/sequence

There are sequence/collection/string methods to find an element/character or split a container on an element or one of a set of elements. But I haven't noticed methods that split on a sub-string, like wanting to split a string on exactly CR-LF and not on either individually. Shouldn't we add

Re: [swift-evolution] [Accepted] SE-0185 - Synthesizing Equatable and Hashable conformance

> On Aug 19, 2017, at 3:29 PM, Haravikk via swift-evolution > wrote: > >> On 19 Aug 2017, at 19:46, Daryle Walker > > wrote: >> >>> On Aug 19, 2017, at 7:06 AM, Haravikk via swift-evolution >>>

[swift-evolution] Preparing Swift compiler stage reentrancy in preparation for "constexpr"

[I’m not sure which list should cover this.] I once thought of having a “#protocols(SomeTypeOrProtocol)” that was a type alias to a composition of all protocols the given type/protocol conforms to (or “Any” if none). It seems simple, but all current uses of protocols requires explicit mentions

Re: [swift-evolution] [Accepted] SE-0185 - Synthesizing Equatable and Hashable conformance

> On Aug 19, 2017, at 7:06 AM, Haravikk via swift-evolution > wrote: > >> On 19 Aug 2017, at 11:44, Tino Heth <2...@gmx.de > wrote: >>> Am 17.08.2017 um 20:11 schrieb Haravikk via swift-evolution >>>

Re: [swift-evolution] [Pitch] Improve `init(repeating:count)`

> On Aug 17, 2017, at 1:06 PM, Erica Sadun via swift-evolution > wrote: > > Also, for those of you here who haven't heard my previous rant on the > subject, I dislike using map for generating values that don't depend on > transforming a domain to a range. (It has

[swift-evolution] What would public/open mean for a subtype? (was: Enums and Source Compatibility)

> On Aug 9, 2017, at 3:57 PM, Adrian Zubarev via swift-evolution > wrote: > > I’d very much in favour of a consistent access modifiers across the whole > language and eliminate exclusive `open`. `open/public` protocols are more > than welcome. Plus it’s already has

Re: [swift-evolution] How does "Sequence.joined" work?

> On Aug 9, 2017, at 12:19 PM, Taylor Swift <kelvin1...@gmail.com> wrote: > > On Wed, Aug 9, 2017 at 10:43 AM, Daryle Walker via swift-evolution > <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: > >> On Aug 8, 2017, at 6:45 PM, Geordi

Re: [swift-evolution] How does "Sequence.joined" work?

and other standard library types have secret references/pointers that work even for “let”-mode objects, and the Sequence variants the various forms of “joined” need use a Sequence/Collection of those secret references? >> Le 7 août 2017 à 21:12, Daryle Walker via swift-evolution >&

[swift-evolution] [Pitch][Swift 5?] #dup "macro", i.e. Entity Duplication

I posted a revision (2) of the entity duplication . I added the ability to use the index placeholder as a closure anonymous argument, i.e. parameterize “$0,” “$1,” etc. with “$($$0).” I thought a direct triple-dollar-sign

[swift-evolution] How does "Sequence.joined" work?

I was looking at random items at SwiftDoc.org , and noticed the “FlattenBidirectionalCollection” structure. It helps implement some versions of “joined” from Sequence (probably when the Sequence is also a BidirectionalCollection). The directions for the type state that

Re: [swift-evolution] [Pitch] #dup -- a duplication "macro"(?)

> On Aug 3, 2017, at 12:39 AM, Daryle Walker wrote: > > After a few hours, I figured out what was bugging me. Variadic generic > parameters, and the existing variadic function parameters, CONSUME > arbitrarily long comma-separated lists. The #dup facility PRODUCES those >

Re: [swift-evolution] [Planning][Request] "constexpr" for Swift 5

> On Aug 3, 2017, at 8:20 PM, Karl Wagner via swift-evolution > wrote: > >>> The root cause, of course, is that the VLAs require new stack allocations >>> each time, and the stack is only deallocated as one lump when the frame >>> ends. >> >> That is true of

Re: [swift-evolution] [Pitch] New Version of Array Proposal

> On Aug 3, 2017, at 7:20 AM, Tino Heth <2...@gmx.de> wrote: > > Hi Daryle, > > I think we agree a lot on the importance of fixed-size arrays, but have a > different opinion on which aspect is the most valuable… (so we now only have > to agree that mine is better ;-) ;-) > My motivation for

Re: [swift-evolution] [Pitch] New Version of Array Proposal

> On Aug 2, 2017, at 4:44 PM, Karl Wagner via swift-evolution > wrote: > > I’m -1 on adding a fixed-sized Array type. > > It goes back to something which I remember reading from John McCall earlier > this week but can’t find any more: about tuple indices being

Re: [swift-evolution] [Pitch] #dup -- a duplication "macro"(?)

> On Aug 1, 2017, at 9:56 AM, Daryle Walker <dary...@mac.com> wrote: > >> On Jul 31, 2017, at 10:38 PM, David Sweeris <daveswee...@mac.com >> <mailto:daveswee...@mac.com>> wrote: >> >>> On Jul 31, 2017, at 7:23 PM, Daryle Walker via swift-evol

Re: [swift-evolution] [Pitch] New Version of Array Proposal

> On Aug 1, 2017, at 7:21 PM, John McCall <rjmcc...@apple.com> wrote: > >> On Aug 1, 2017, at 5:49 PM, David Sweeris via swift-evolution >> <swift-evolution@swift.org> wrote: >>> On Aug 1, 2017, at 10:54 AM, Daryle Walker via swift-evolution

Re: [swift-evolution] [Pitch] New Version of Array Proposal

> On Aug 1, 2017, at 1:03 PM, Tino Heth <2...@gmx.de> wrote: > >> Sequence/Collection have other problems fitting with fixed-size arrays. >> There needs to be a new set of more basic protocols that both arrays and >> Sequence or Collection can conform to. > What exactly is the problem with

Re: [swift-evolution] [Pitch] New Version of Array Proposal

> On Aug 1, 2017, at 3:21 AM, Tino Heth <2...@gmx.de> wrote: > >> FSAs intentionally don’t conform to Collection, because multi-dimensional >> arrays shouldn’t have to conform to a linear (by nature, hence the name >> “Sequence”) standard, at least by default. > I strongly oppose and think it

Re: [swift-evolution] [Pitch] #dup -- a duplication "macro"(?)

> On Jul 31, 2017, at 10:23 PM, Daryle Walker via swift-evolution > <swift-evolution@swift.org> wrote: > > Could we do better than simple repetition? What if we define a “$$n” unit, > where “n” is a nonnegative integer. For each comma-separated item, the unit > will b

Re: [swift-evolution] [Pitch] #dup -- a duplication "macro"(?)

> On Jul 31, 2017, at 10:38 PM, David Sweeris <daveswee...@mac.com> wrote: > >> On Jul 31, 2017, at 7:23 PM, Daryle Walker via swift-evolution >> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >> >> The tuple will be

Re: [swift-evolution] [Planning][Request] "constexpr" for Swift 5

> On Jul 31, 2017, at 4:37 PM, Gor Gyolchanyan > wrote: > >> >> On Jul 31, 2017, at 11:23 PM, John McCall > > wrote: >> >>> >>> On Jul 31, 2017, at 4:00 PM, Gor Gyolchanyan >>

[swift-evolution] [Pitch] #dup -- a duplication "macro"(?)

When coming up with new array interfaces, I had some array to/from tuple conversion functions: func array(from: (T, …U)) -> [1 + #countOf(U) ; T] allwhere U == T The problem is going the other way: func tuple(from: [N; T]) -> ??? The tuple will be a bunch of “T,” but the

Re: [swift-evolution] [Pitch] Update to Alternative Types (i.e. strong typedef) Proposal

> On Jul 31, 2017, at 8:38 PM, Robert Widmann wrote: > >> On Jul 31, 2017, at 4:08 PM, Daryle Walker > > wrote: >> >>> On Jul 31, 2017, at 1:45 PM, Robert Widmann >> > wrote: >>> >>>

Re: [swift-evolution] [Pitch] Update to Alternative Types (i.e. strong typedef) Proposal

> On Jul 31, 2017, at 1:45 PM, Robert Widmann wrote: > > As I was saying, I agree with the overall usefulness of newtype-style > declarations, but I don’t understand why we need so much syntax for what > should just be a pattern in Swift. Specifically, the idea of

Re: [swift-evolution] [Pitch][Bug?] Test for Anti-Conformance During Generics

> On Jul 31, 2017, at 1:49 PM, Robert Widmann <rwidm...@apple.com> wrote: > >> On Jul 31, 2017, at 10:34 AM, Daryle Walker via swift-evolution >> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >> >> Part of

Re: [swift-evolution] [Idea] Custom keywords for operators.

> On Jul 31, 2017, at 5:09 PM, Gor Gyolchanyan via swift-evolution > wrote: > > So I was thinking the other day (and by "the other day" I mean "It just > occurred to me") that Swift's custom operator declaration mechanism is pretty > sweet (it's become even sweeter

Re: [swift-evolution] [Pitch][Bug?] Test for Anti-Conformance During Generics

> On Jul 31, 2017, at 1:33 AM, Daryle Walker wrote: > >> On Jul 31, 2017, at 1:19 AM, Xiaodi Wu > > wrote: >> >> Daryle, this discussion has indeed taken place before. One good place to >> start is the Google result for

Re: [swift-evolution] [Pitch][Bug?] Test for Anti-Conformance During Generics

AnyObject. > On Sun, Jul 30, 2017 at 5:30 PM, Daryle Walker via swift-evolution > <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: > > > On Jul 30, 2017, at 5:03 PM, Tino Heth <2...@gmx.de <mailto:2...@gmx.de>> > > wrote: > >

Re: [swift-evolution] [Planning][Request] "constexpr" for Swift 5

my iPhone On Jul 30, 2017, at 8:51 PM, John McCall <rjmcc...@apple.com> wrote: >> On Jul 29, 2017, at 7:01 PM, Daryle Walker via swift-evolution >> <swift-evolution@swift.org> wrote: >> The “constexpr” facility from C++ allows users to define constants and &g

Re: [swift-evolution] [Pitch] New Version of Array Proposal

> On Jul 30, 2017, at 4:54 PM, Félix Cloutier wrote: > >> Le 29 juil. 2017 à 16:01, Daryle Walker a écrit : >> >>> On Jul 25, 2017, at 2:14 AM, Félix Cloutier via swift-evolution >>> wrote: >>> >>> It seems to me that I'm the

Re: [swift-evolution] [Pitch][Bug?] Test for Anti-Conformance During Generics

> On Jul 30, 2017, at 5:03 PM, Tino Heth <2...@gmx.de> wrote: > >> [Apologies if this is in Swift 4 already.] >> >> We can have generic parameters match a protocol. But I have an idea in my >> head that involves the type NOT conforming to a protocol. I don’t think we >> have a way currently

Re: [swift-evolution] [Planning][Request] "constexpr" for Swift 5

> On Jul 30, 2017, at 5:34 PM, Tino Heth <2...@gmx.de> wrote: > >> If you read my reply to Daniel Vollmer, you’ll find that we’re thinking >> about the exact same thing. > Good to hear — read that post later, but I guess repeating doesn't hurt here: > People still talk about macros... ;-) >

[swift-evolution] [Pitch][Bug?] Test for Anti-Conformance During Generics

[Apologies if this is in Swift 4 already.] We can have generic parameters match a protocol. But I have an idea in my head that involves the type NOT conforming to a protocol. I don’t think we have a way currently to work with this. In C++, templates can be specialized or partially specialized.

Re: [swift-evolution] Change 'for in' expression to for [] { (item) in ... }

> On Jul 28, 2017, at 12:19 PM, Kwanghoon Choi via swift-evolution > wrote: > > Hello > > I found someone easy mistake using for in loop statement. > > Ex) > var i = 0 > for i in 0..<10 { } > print(i) > > And this user expected print(i) is “10” > > Many

Re: [swift-evolution] [Pitch] New Version of Array Proposal

> On Jul 25, 2017, at 2:14 AM, Félix Cloutier via swift-evolution > wrote: > > It seems to me that I'm the one advocating for fewer language changes, and > the majority of sub-features that are being requested here don't feel > particularly more general to me. > >

Re: [swift-evolution] [Pitch] New Version of Array Proposal

> On Jul 24, 2017, at 7:29 AM, Tino Heth <2...@gmx.de> wrote: > > Also, I might have a different focus for the feature: > Performance and C interoperability are important, but I just want type safety > and to avoid creating stupid things like Vector3, Vector4… which can't share > code because

Re: [swift-evolution] [Pitch] New Version of Array Proposal

> On Jul 23, 2017, at 11:20 PM, Taylor Swift wrote: > > On Sun, Jul 23, 2017 at 11:05 PM, Daryle Walker > wrote: > >> On Jul 23, 2017, at 12:04 PM, Taylor Swift > > wrote: >

Re: [swift-evolution] [Pitch] New Version of Array Proposal

> On Jul 24, 2017, at 1:22 AM, Charles Srstka via swift-evolution > wrote: > > Do FSAs really need special sugar, though? They won’t be an extremely > heavily-used construct, but rather they’ll be occasionally used either for > performance reasons or to interact

[swift-evolution] [Planning][Request] "constexpr" for Swift 5

The “constexpr” facility from C++ allows users to define constants and functions that are determined and usable at compile-time, for compile-time constructs but still usable at run-time. The facility is a key step for value-based generic parameters (and fixed-size arrays if you don’t want to be

[swift-evolution] [Pitch] Update to Alternative Types (i.e. strong typedef) Proposal

Proposal at , uploaded revision 4. Changes: Since the original setup was a poor copy of how raw-style enumerations use RawRepresentable, changed the model to actually use RawRepresentable. Actually, it uses a sub-protocol,

[swift-evolution] Why couldn't a class call any of its superclass' initializers?

[Sorry if this's been discussed before.] As long as the superclass sub-object gets initialized, it shouldn't matter if the initializer was designated or convenience. Is there some subtle step on the two-phase initialization I'm missing? Or is this a point to extend in a future version of

Re: [swift-evolution] [Pitch] New Version of Array Proposal

> On Jul 23, 2017, at 3:18 PM, Taylor Swift via swift-evolution > wrote: > > > If we’re actually going to try and establish a relationship between the FSA > asterisk and the multiplication asterisk, this is even more problematic. How > does the asterisk work in

Re: [swift-evolution] [Pitch] New Version of Array Proposal

> On Jul 23, 2017, at 12:04 PM, Taylor Swift wrote: > > > > On Sun, Jul 23, 2017 at 3:08 AM, Daryle Walker > wrote: > >> 9. I don’t see the value in having both nested FSAs and multi-dimensional >> FSAs. Aren’t they the same

Re: [swift-evolution] [Pitch] New Version of Array Proposal

> On Jul 23, 2017, at 2:07 PM, Nevin Brackett-Rozinsky via swift-evolution > wrote: > > I think fixed-size arrays should be a nominal type like any other. They > should be able to have methods, conform to protocols, be extended with new > behavior, and generally

Re: [swift-evolution] [RFC] Definitive Initialization and Incompatibilities with Fixed-size Arrays

> On Jul 23, 2017, at 7:27 PM, Félix Cloutier wrote: > > I think I've already said that, but I agree that an incremental approach to > this would be better. > >> Le 23 juil. 2017 à 15:57, Chris Lattner a écrit : >> >> On Jul 22, 2017, at 3:03 PM,

Re: [swift-evolution] [Pitch] New Version of Array Proposal

> On Jul 23, 2017, at 5:49 PM, David Sweeris via swift-evolution > wrote: > > > On Jul 23, 2017, at 12:18, Taylor Swift > wrote: > >> I don’t think tuples are a suitable replacement for FSAs. A tuple should be

Re: [swift-evolution] [Pitch] New Version of Array Proposal

nality” is the number of co-equal coordinates. But that second name probably needs some work, although it can be synthesized from the length of “dimensions.” The “cardinality” and “elementCount” properties work around us not having (integer) compile-time constants yet; otherwise we can derive them

[swift-evolution] [Pre-pitch] "common" fields for union-style enumerations?

Way back in the macOS pre-X days, I remember some APIs had types like: struct Sample1 { int a; int b; float c; }; struct Sample2 { int a; int b; double d; }; The types are supposed to be related, and it was supposed to be guaranteed that if you type-punned Sample1 to or from Sample2, the

Re: [swift-evolution] [RFC] Definitive Initialization and Incompatibilities with Fixed-size Arrays

> On Jul 22, 2017, at 3:02 PM, Chris Lattner <clatt...@nondot.org> wrote: > > On Jul 18, 2017, at 1:00 PM, Daryle Walker via swift-evolution > <swift-evolution@swift.org> wrote: >>> On Jul 17, 2017, at 3:26 AM, Félix Cloutier <felix...@yahoo.ca> wrote: >

[swift-evolution] [Pitch] New Version of Array Proposal

It’s at >. * Try to clarify that fixed-size arrays are a new kind of compound type, not a (ridiculously magical) library generic type. * Change the separator

Re: [swift-evolution] [RFC] Definitive Initialization and Incompatibilities with Fixed-size Arrays

> On Jul 17, 2017, at 3:26 AM, Félix Cloutier wrote: > > I think that you're getting ahead of yourself. Fixed-size arrays are still > useful even if they have to have been demonstrably initialized before you can > use dynamic indices with them. A ton of people have already

Re: [swift-evolution] [Pitch] Array full proposal

> On Jul 13, 2017, at 7:32 PM, Daryle Walker wrote: > 3) Default initialization semantics for arrays including a DI exception for fixed-length arrays that aren’t fully initialized >>> >>> My first thought was full initialization, like other objects, but someone

Re: [swift-evolution] [RFC] Definitive Initialization and Incompatibilities with Fixed-size Arrays

> On Jul 13, 2017, at 1:41 PM, Daryle Walker via swift-evolution > <swift-evolution@swift.org> wrote: > > As I understand it, Definitive Initialization means the Swift compiler will > make sure an instance is fully initialized before the first attempt to read >

Re: [swift-evolution] [Pitch] Array full proposal

> On Jul 13, 2017, at 1:28 PM, Robert Widmann wrote: > >> On Jul 12, 2017, at 9:09 PM, Daryle Walker > > wrote: >> >>> On Jul 12, 2017, at 4:05 PM, Robert Widmann >> > wrote: >>>

[swift-evolution] [RFC] Definitive Initialization and Incompatibilities with Fixed-size Arrays

As I understand it, Definitive Initialization means the Swift compiler will make sure an instance is fully initialized before the first attempt to read it. It does not require mandatory assignment at declaration; an instance can be declared with no initializer and receive an assignment at a

Re: [swift-evolution] [Pitch] Array full proposal

> On Jul 13, 2017, at 7:09 AM, Gor Gyolchanyan wrote: > > Yes, by nominal tuples I did mean a struct definition somewhere in swift’s > standard library. > > Seems like there are some quirks to tuples in Swift that I’m not aware of. I > always assumed that they are

Re: [swift-evolution] [Pitch] Array full proposal

— Daryle Walker Mac, Internet, and Video Game Junkie darylew AT mac DOT com > On Jul 12, 2017, at 4:30 PM, Gor Gyolchanyan wrote: > > I agree, given the current state of Swift, fixed-sized arrays are way too > magical. Any more “magical” than the existing primitive

Re: [swift-evolution] [Pitch] Array full proposal

> On Jul 12, 2017, at 4:05 PM, Robert Widmann wrote: > > I think this proposal is trying to do too much at once. Correct me if I’m > wrong, but you’re proposing > > 1) New sugar for fixed-length arrays without a corresponding stdlib > declaration IIUC, “sugar” means an

[swift-evolution] [Pitch] Strong typedef, version 0.2

I’ve updated my strong type-alias proposal at . There’s 3 revisions instead of 2 because I missed a big error. * I removed all the state-restriction stuff (but still noted as a possible future direction). Besides removing a

[swift-evolution] [Pitch] Array full proposal

Spent the past week coming up with a full proposal for fixed-size arrays. I wrote it mainly from the bottom upwards. There may be some inconsistencies. And I'm not entirely sure what "structural sub-typing" means, or if it's appropriate for arrays.

[swift-evolution] [Pitch] Get all the protocols a type supports

I mentioned this in another thread recently. Here’s a more formal pitch. Query a Type on Its Protocols Proposal: SE- Authors: Daryle Walker , Author 2 Review Manager: TBD Status: Awaiting review Introduction This proposal adds a

[swift-evolution] [Pitch] strong typedef

I uploaded my proposal for strong type-aliases at >. My brain is somewhat fried from working for several days writing and rewriting this, so new sets of eyes

Re: [swift-evolution] Would having "MyType.Protocol" to indicate a type's protocols mess anything up?

> On Jul 2, 2017, at 10:15 PM, Christopher Kornher wrote: > > A full-fledged introspection system should provide this information, which I > suppose could be useful for creating proxies through code generation or > dynamic Objective-C like features, should they ever be added

Re: [swift-evolution] Would having "MyType.Protocol" to indicate a type's protocols mess anything up?

> On Jul 1, 2017, at 2:07 AM, Brent Royal-Gordon <br...@architechies.com> wrote: > >> On Jun 30, 2017, at 6:17 PM, Daryle Walker via swift-evolution >> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >> >> Given a type

[swift-evolution] How many kinds of declarations can a named type hold?

I think I got most of this, but it’s hard to completely figure out because the information is scattered across the grammar. So, I’m coming up with a statement to copy over a member from one type to another: publish MEMBER-FROM-OTHER-TYPE and I’m trying to encapsulate this into a grammar. This

Re: [swift-evolution] Would having "MyType.Protocol" to indicate a type's protocols mess anything up?

> On Jun 30, 2017, at 9:26 PM, Robert Bennett wrote: > > I’m not at a computer to test this, but would this work: > > typealias T = P1 & P2 > extension C: T {} > > Now T is C.Protocol Is C supposed to be a type or a protocol? I’m guessing a protocol since I don’t

Re: [swift-evolution] Would having "MyType.Protocol" to indicate a type's protocols mess anything up?

> On Jun 30, 2017, at 8:49 PM, Adrian Zubarev > wrote: > > What are you proposing here, I don’t get it?! What role should .Protocol > play? .Protocol is an ugly hack in Swift which should be removed anyway. It > does more harm than good. > I’m not proposing

[swift-evolution] Would having "MyType.Protocol" to indicate a type's protocols mess anything up?

We have MyType.Type to indicate the meta-type of a type. And MyProtocol.Protocol to indicate the meta-type of a protocol. Would it be OK to add MyType.Protocol to identify all the protocols MyType follows? The result would be like if each protocol was connected by

Re: [swift-evolution] [Pitch] Object aliases

> On Jun 30, 2017, at 1:11 AM, John McCall <rjmcc...@apple.com> wrote: > >> >> On Jun 23, 2017, at 3:28 AM, Daryle Walker via swift-evolution >> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >> >> S

Re: [swift-evolution] [Pitch] Object aliases

> On Jun 29, 2017, at 6:45 PM, Beta wrote: > > So, what’s the difference between this and teaching Key Paths to look through > tuple indices - that was the only part of your example I couldn’t directly > express. You’re talking about Apple’s Cocoa’s KVC/KVO, right? The

[swift-evolution] Invariant checks on strong typedefs?

In my retype idea, you can bring back symbols from the implementation type with an "export" command. There's an "export default" command to bring back all the numbered fields of a tuple or all the cases of an enum. But what would it mean to NOT include all enum cases? One option is to ban

Re: [swift-evolution] [Pitch] Object aliases

I put this proposal, with an addendum about lenses, at . — Daryle Walker Mac, Internet, and Video Game Junkie darylew AT mac DOT com ___ swift-evolution mailing list

[swift-evolution] Trying to grok the ABI documents, w.r.t. strong typedefs

I’m trying to understand two of the ABI documents, and , with respect to a strong type-alias idea I just posted: retype IDENTIFIER: IMPLEMENTATION-TYPE (“,”

Re: [swift-evolution] [Pitch] Object aliases

> On Jun 23, 2017, at 9:29 AM, Nevin Brackett-Rozinsky > wrote: > > This sounds similar to lenses. Have you looked at previous lens discussions > on-list? I had no idea what a lens is. Nor was is easy to figure out since I can’t read Scala, JavaScript, or

Re: [swift-evolution] Revisiting SE-0110

> On Jun 24, 2017, at 12:25 PM, Djura Retired Hunter > wrote: > > I didn't understand your example at all. Care to elaborate? > > Elviro > >> Il giorno 24 giu 2017, alle ore 18:05, Daryle Walker > > ha scritto: >> >>

Re: [swift-evolution] Revisiting SE-0110

> On Jun 23, 2017, at 7:46 AM, Elviro Rocca via swift-evolution > wrote: > > It's probably late to just casually add a couple of cents to a discussion > that has been going for so long, but it seems to me that from a user > standpoint, that uses types to structure

[swift-evolution] [Pitch] Object aliases

I started a thread earlier this week about strong type-aliases and object aliases. Here’s a fuller proposal on object aliases. Feature name Proposal: SE- Authors: Daryle Walker , Author 2 Review Manager: TBD Status: Awaiting

Re: [swift-evolution] [early Pitch] retype (or newtype): strong type-alias (typedef) for redoing an interface; also: object aliases

I didn’t add a SuperReallyPeachyKeenProtocol example. It assumes we eventually add variadic generics: retype TupleCollection: (T, …U), RandomAccessCollection allwhere U == T { export default // Without this, instances of “self” below would be “super” instead. var head: T { get { return

[swift-evolution] [early Pitch] retype (or newtype): strong type-alias (typedef) for redoing an interface; also: object aliases

In one of my earlier fixed-size array proposals, I had two kinds of array types: a compound type and a nominal type. I dropped the latter because there wasn’t too much of a value-add, especially once I copied its unique features to the compound type. It would be like a compound array property

Re: [swift-evolution] [Pitch] #error

> On Jun 12, 2017, at 3:57 PM, Daryle Walker via swift-evolution > <swift-evolution@swift.org> wrote: > > >> On Jun 12, 2017, at 8:03 AM, Ben Rimmington <m...@benrimmington.com >> <mailto:m...@benrimmington.com>> wrote: >> >> >>

Re: [swift-evolution] [Pitch] #error

> On Jun 12, 2017, at 8:03 AM, Ben Rimmington wrote: > > >> On 11 Jun 2017, at 19:15, Beta wrote: >> >> A proposal and implementation of #warning exist. It has been judged out of >> scope for Swift 3 and Swift 4 phase 2. >> >>

[swift-evolution] [Pitch] constexpr (i.e. compile-time constant expressions)

I’m not a language/library designer, just a wannabe designer; I’m hitting the limits of my expertise. So unless I lucked out, one of the main designers will have to pick up this ball and clean it up. I’ll be here if you need clarification on stuff. The seed of this idea was coming up with a

[swift-evolution] Swift phases and mis-timed proposals

I’ve read about the Swift developers taking certain kinds of proposals during certain phases (Swift 3, Swift 4 stage 1, Swift 4 stage 2, etc.). So if someone writes a proposal that isn’t of the type of the current phase, it’s auto-rejected. Is it possible to set some kind of proposal queue so

Re: [swift-evolution] [Pitch] #error

> On Jun 10, 2017, at 2:00 PM, Xiaodi Wu wrote: > > Daryle, there have been several pitches in the past with respect to #error, > and very enlightening arguments both for and against the idea have been > eloquently written. > > Since you’re resurrecting this idea, could

[swift-evolution] [Pitch] #error

Unconditional Error Messages Proposal: SE- Authors: Daryle Walker , Author 2 Review Manager: TBD Status: Awaiting review During the review process, add the following fields as needed: Decision Notes: Rationale

Re: [swift-evolution] Pitch: Limit typealias extensions to the typealias

> On Jun 9, 2017, at 12:14 AM, Yvo van Beek via swift-evolution > wrote: > > Typealiases can greatly reduce the complexity of code. But I think one change > in how the compiler handles them could make them even more powerful. [SNIP] > Perhaps it would be better if

[swift-evolution] Fortran arrays and my recent proposal

My array proposals included some form of specifying storage ranks for each extent. By default, the ranks would follow row-major order, like C. The first dimension would have the widest span between elements that differ by 1 in the first index and are the same for other indexes. The last

Re: [swift-evolution] Proposal: Always flatten the single element tuple

> On Jun 7, 2017, at 11:12 PM, Stephen Celis via swift-evolution > wrote: > >> On Jun 7, 2017, at 10:33 PM, Xiaodi Wu via swift-evolution >> wrote: >> >> However, what I don’t get is why you’d have a mismatch here. Your method >>

[swift-evolution] Indexing (static-size) arrays: offsets or tables?

I looked up a history of programming languages on Wikipedia, and looked up a bunch of them that I heard of to see how they handle array indexing. 1. A lot of them do it the way C does it: you specify a positive integer at the spot where you give a dimension. Then at dereference-time, you insert

Re: [swift-evolution] Yet another fixed-size array spitball session

> On Jun 2, 2017, at 10:26 AM, Dave Abrahams via swift-evolution > <swift-evolution@swift.org> wrote: > > > on Fri Jun 02 2017, Brent Royal-Gordon <swift-evolution@swift.org > <mailto:swift-evolution@swift.org>> wrote: > >>> On May 28, 2017

[swift-evolution] Can functions/methods be overloaded on mutability of parameters?

Can I make two overloads such that one can take an argument from a “let”-mode object or a regular function parameter and return an UnsafePointer and then have the other take a “var”-mode object or inout function parameter and return an UnsafeMutablePointer? I think this can be done in C++. —

Re: [swift-evolution] Sparse (fixed-size) array literal syntax

> On Jun 2, 2017, at 4:06 AM, Jaden Geller wrote: > > I don’t know if you’re aware, but you can extend arbitrary nominal types with > literal syntax. > > ``` > extension FixedSizedArray: ExpressibleAsDictionaryLiteral { … } > ``` > > Nothing special needs to be done

Re: [swift-evolution] Yet another fixed-size array spitball session

New Spitball But first: C has one of the worst array presentation models. It has traumatized so many that those among them that grew up to be language designers themselves threw out fixed-sized arrays entirely (from Java to even current Swift!). But we’re getting through to everyone that the

  1   2   >