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

I thought limiting the keywords to the ones explicitly defined for this purpose would solve the problem of overcomplicating the parser. Just to be clear: I do *not* propose replacing punctuation-based operators with identifier-based ones, the ideas was purely additive. But I do see the problem

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

> On Jul 31, 2017, at 11:29 PM, Félix Cloutier wrote: > No, this is a misunderstanding: I mean "you" as yourself, not "you" as the > compiler. As far as I know, given a type variable, as in `let foo: > NSObject.Type = NSArray.self`, you (the developer) can't use `foo` to >

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

No, this is a misunderstanding: I mean "you" as yourself, not "you" as the compiler. As far as I know, given a type variable, as in `let foo: NSObject.Type = NSArray.self`, you (the developer) can't use `foo` to instantiate a generic type. The question stands again: are there any specific

Re: [swift-evolution] [Idea] Creating an enums as a sum of multiple other enums

That solution seems way too verbose, and also not exactly type safe because you must handle optionals in addition to any new cases that arise, which are silently handled by the default case. To Xiaodi: is this really just value subtyping? Seems like it would also require multiple inheritance

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

> On Jul 31, 2017, at 7:23 PM, Daryle Walker via swift-evolution > wrote: > > 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

[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] [Idea] Creating an enums as a sum of multiple other enums

Not a response to the core of this, but to the motivating example: Sectioned (or multi-sorted in other cases) ASTs can also be represented by a singly-sorted AST and views over top enum UnaryOperatorView { case not } enum BinaryOperatorView { case and case or } enum BooleanLiteralView {

Re: [swift-evolution] [Idea] Creating an enums as a sum of multiple other enums

I think what you're asking for here is essentially some sort of (or special case of) value subtyping, a topic near and dear to many. On Mon, Jul 31, 2017 at 7:43 PM, Ahmad Alhashemi via swift-evolution < swift-evolution@swift.org> wrote: > I’ve been writing an interpreter in Swift and have been

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] [Idea] Custom keywords for operators.

> On Jul 31, 2017, at 2: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] TrigonometricFloatingPoint/MathFloatingPoint protocol?

So, this has been discussed before on the list many times in the past. The core team has stated that their preferred process for this is to have individuals write their own libraries, get real-world adoption, then (as consensus emerges) propose their inclusion as a core library. Keep in mind that

[swift-evolution] [Idea] Creating an enums as a sum of multiple other enums

I’ve been writing an interpreter in Swift and have been finding enums incredibly useful. One feature thought that I thought would make life easier is the ability to create a super-enum that contains as its cases all the cases of its constituent enums: > enum UnaryOperator { > case not > }

Re: [swift-evolution] Fast String Comparison From String Arrays

Hi Omar, Could you talk in a little more detail about your algorithm, including space/time complexity? It sounds interesting, but I am having trouble finding the relevant portions in the source code... Thanks, Jon > On Jul 31, 2017, at 1:26 AM, Omar Charif via swift-evolution >

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

> On Jul 31, 2017, at 4:08 PM, Daryle Walker wrote: > >> 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

Re: [swift-evolution] TrigonometricFloatingPoint/MathFloatingPoint protocol?

I’d be completely in favor of this. Structs for priority queues, skiplists, trees, binary search and more sorting functions would also be on my wishlist. I think Python made a very good choice in choosing to vend separate standard modules for stuff like that instead of bloating its builtin

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

PS, for what it’s worth, i am the maintainer of the language-swift-89 atom package. On Mon, Jul 31, 2017 at 8:29 PM, Taylor Swift wrote: > > > On Mon, Jul 31, 2017 at 7:20 PM, David Sweeris > wrote: > >> >>

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

On Mon, Jul 31, 2017 at 7:20 PM, David Sweeris wrote: > > > On Jul 31, 2017, at 3:59 PM, Taylor Swift via swift-evolution < > swift-evolution@swift.org> wrote: > > > > I’m gonna come out and say I’m not a fan of this at all. I’m already > pretty suspicious of operator

Re: [swift-evolution] TrigonometricFloatingPoint/MathFloatingPoint protocol?

+1000 to this. > On Jul 31, 2017, at 11:22 AM, Hooman Mehr via swift-evolution > wrote: > > Maybe we need more than one level of standard library: The core (which is > most of what we have now (but maybe not all of it) and multiple opt-in > standard modules for

Re: [swift-evolution] Extensions

> On Jul 31, 2017, at 4:19 PM, Omar Charif via swift-evolution > wrote: > > I am a big fan of extensions, but I wonder what would happen years from now > when we start to have lots of extensions created for the primitive classes. > The problem is that we can write

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] [Idea] Custom keywords for operators.

I’m gonna come out and say I’m not a fan of this at all. I’m already pretty suspicious of operator overloading, and I think supporting this would make Swift code much more difficult to read. Also, while for some reason everyone ignores this, this kind of syntax is almost impossible for text

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

> On Jul 31, 2017, at 1:49 PM, Robert Widmann wrote: > >> On Jul 31, 2017, at 10:34 AM, Daryle Walker via swift-evolution >> > wrote: >> >> Part of the response that closed [SR-5589] as “Won’t Do” was: >> >>>

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] [Planning][Request] "constexpr" for Swift 5

On Jul 31, 2017, at 12:15 AM, Gor Gyolchanyan via swift-evolution wrote: >> On Jul 31, 2017, at 7:10 AM, John McCall via swift-evolution >> wrote: >> >>> On Jul 30, 2017, at 11:43 PM, Daryle Walker wrote: >>> The

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

Sent from my iPad > On Jul 31, 2017, at 2: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

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

> On Jul 31, 2017, at 1:37 PM, Gor Gyolchanyan via swift-evolution > wrote: > > >>> On Jul 31, 2017, at 11:23 PM, John McCall wrote: >>> >>> On Jul 31, 2017, at 4:00 PM, Gor Gyolchanyan wrote:

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

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

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

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

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

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

> On Jul 31, 2017, at 4:00 PM, Gor Gyolchanyan > wrote: > > >> On Jul 31, 2017, at 10:09 PM, John McCall > > wrote: >> >>> On Jul 31, 2017, at 3:15 AM, Gor Gyolchanyan >>

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

> On Jul 31, 2017, at 10:09 PM, John McCall wrote: > >> On Jul 31, 2017, at 3:15 AM, Gor Gyolchanyan >> wrote: >>> On Jul 31, 2017, at 7:10 AM, John McCall via swift-evolution >>> wrote: >>> On Jul 30, 2017,

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

> On Jul 31, 2017, at 3:15 AM, Gor Gyolchanyan > wrote: >> On Jul 31, 2017, at 7:10 AM, John McCall via swift-evolution >> wrote: >> >>> On Jul 30, 2017, at 11:43 PM, Daryle Walker wrote: >>> The parameters for a

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

> On Jul 31, 2017, at 3:58 AM, Félix Cloutier wrote: > It seems to me that this applies just the same to type generic parameters. > Are there any reason that you can't instantiate a generic type at runtime, or > is it just because the need is not as evident as it would/could

Re: [swift-evolution] TrigonometricFloatingPoint/MathFloatingPoint protocol?

Maybe we need more than one level of standard library: The core (which is most of what we have now (but maybe not all of it) and multiple opt-in standard modules for hash functions, math, specialized data structures, etc. > On Jul 31, 2017, at 11:10 AM, Taylor Swift

Re: [swift-evolution] TrigonometricFloatingPoint/MathFloatingPoint protocol?

I know. I hear you. I have some special arrangmnents to keep such things manageable, and I am not happy about how things stand right now. What I am hoping to open up stdlib special compiler mode to other (low-level) libraries and also letting such libraries gain optimizations similar to stdlib

Re: [swift-evolution] TrigonometricFloatingPoint/MathFloatingPoint protocol?

Isn’t the point of standard inlineable library module to prevent the need to copy and paste code like this into every project? Currently I have a “math.swift” file I copy and paste into all of my projects, and since I occasionally update it, there exists about 15 different versions of it floating

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

> On Jul 31, 2017, at 10:34 AM, Daryle Walker via swift-evolution > wrote: > > >> On Jul 31, 2017, at 1:33 AM, Daryle Walker > > wrote: >> >>> On Jul 31, 2017, at 1:19 AM, Xiaodi Wu >>

Re: [swift-evolution] TrigonometricFloatingPoint/MathFloatingPoint protocol?

I prefer an approach that preserves how I am used to seeing math expressions. I use this myself: protocol FloatingPointMath: FloatingPoint { static func sqrt(_ value: Self) -> Self static func sin(_ value: Self) -> Self static func cos(_ value: Self) -> Self static func tan(_

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

(Excuse me, my last reply was sent prematurely) 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 automatic delegation of an interface is

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

I agree with the overall usefulness of newtype-style ( > On Jul 29, 2017, at 4:01 PM, Daryle Walker via swift-evolution > wrote: > > Proposal at >

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] TrigonometricFloatingPoint/MathFloatingPoint protocol?

> On Jul 31, 2017, at 1:29 PM, Taylor Swift via swift-evolution > wrote: > > Also squareRoot() should be moved to the Math module if it is ever created. No; square root is an IEEE-754 required basic operation, just like addition or multiplication. It is part of the

Re: [swift-evolution] TrigonometricFloatingPoint/MathFloatingPoint protocol?

On Mon, Jul 31, 2017 at 1:23 PM, Adrian Zubarev < adrian.zuba...@devandartist.com> wrote: > I’m not sure how I would feel about this. To be honest I’d avoid such > additional changes from the stdlib, because they really don’t belong there. > Instead some `Math` module/package would be a better

Re: [swift-evolution] TrigonometricFloatingPoint/MathFloatingPoint protocol?

On Mon, Jul 31, 2017 at 1:19 PM, Benjamin Spratling wrote: > 1) Why would cos, sin, ln, tan, asin, acos, atan and exp be functions and > not computed properties? > 2) For people who uses these features on paper and text books, writing > them as what we call global functions

Re: [swift-evolution] TrigonometricFloatingPoint/MathFloatingPoint protocol?

I’m not sure how I would feel about this. To be honest I’d avoid such additional changes from the stdlib, because they really don’t belong there. Instead some `Math` module/package would be a better fit than clustering everything into stdlib until we end up also adding UI stuff. Furthermore, I

Re: [swift-evolution] Recent change makes Swift 4 less safe.

I don’t agree with your assertions that this makes Swift “less safe” - if anything the bug that this fixed was anything but. When performing a pattern match, we expect the pattern to match the “shape” of the declaration itself. If ‘()’ was not part of that declaration, then you have no reason

[swift-evolution] TrigonometricFloatingPoint/MathFloatingPoint protocol?

How would people feel about adding a protocol protocol MathFloatingPoint:FloatingPoint { func sin() -> Self func cos() -> Self func tan() -> Self func asin() -> Self func acos() -> Self func atan() -> Self func ln() -> Self func log(base:Self) -> Self func

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

Indeed. I think something that is missing from the generics manifesto is that we need more type constraints. Value/reference semantics is one badly-needed distinction, but there are others, too (e.g. trivial types). There are lots of generic structures and algorithms which

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

On Mon, Jul 31, 2017 at 3:39 AM, Félix Cloutier wrote: > > Le 31 juil. 2017 à 00:40, Xiaodi Wu via swift-evolution < > swift-evolution@swift.org> a écrit : > > > On Mon, Jul 31, 2017 at 02:15 Gor Gyolchanyan via swift-evolution < > swift-evolution@swift.org> wrote: > >>

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

> On Jul 31, 2017, at 12:16 PM, Tino Heth <2...@gmx.de> wrote: > > >> OTOH, if the compiler can prove that a local array is never resized, why >> *shouldn't* it get all the benefits of a fixed-sized array without having to >> use a special syntax? Put another way, why shouldn't fixed-size be

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

> Le 31 juil. 2017 à 00:40, Xiaodi Wu via swift-evolution > a écrit : > > > On Mon, Jul 31, 2017 at 02:15 Gor Gyolchanyan via swift-evolution > > wrote: > > On Jul 31, 2017, at 7:10 AM, John McCall via

Re: [swift-evolution] Fast String Comparison From String Arrays

The main advantage I introduce is actually no just a substring search, my main goal is to achieve high performance repeated search on the same given array of strings. I have tested my algorithm against something like spotlight for example searching for files etc … Actually my code is a bit

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

> On Jul 31, 2017, at 11:09 AM, Xiaodi Wu wrote: > > > On Mon, Jul 31, 2017 at 02:51 Gor Gyolchanyan > wrote: >> On Jul 31, 2017, at 10:40 AM, Xiaodi Wu >

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

On Mon, Jul 31, 2017 at 02:51 Gor Gyolchanyan wrote: > On Jul 31, 2017, at 10:40 AM, Xiaodi Wu wrote: > > > On Mon, Jul 31, 2017 at 02:15 Gor Gyolchanyan via swift-evolution < > swift-evolution@swift.org> wrote: > >> > On Jul 31, 2017, at 7:10

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

On Mon, Jul 31, 2017 at 02:49 Goffredo Marocchi wrote: > > > Sent from my iPhone > > On 31 Jul 2017, at 08:40, Xiaodi Wu via swift-evolution < > swift-evolution@swift.org> wrote: > > > On Mon, Jul 31, 2017 at 02:15 Gor Gyolchanyan via swift-evolution < >

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

It seems to me that this applies just the same to type generic parameters. Are there any reason that you can't instantiate a generic type at runtime, or is it just because the need is not as evident as it would/could be with non-type generic parameters? > Le 30 juil. 2017 à 21:10, John McCall

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

> On Jul 31, 2017, at 10:40 AM, Xiaodi Wu wrote: > > > On Mon, Jul 31, 2017 at 02:15 Gor Gyolchanyan via swift-evolution > > wrote: > > On Jul 31, 2017, at 7:10 AM, John McCall via swift-evolution > >

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

Sent from my iPhone > On 31 Jul 2017, at 08:40, Xiaodi Wu via swift-evolution > wrote: > > >> On Mon, Jul 31, 2017 at 02:15 Gor Gyolchanyan via swift-evolution >> wrote: >> > On Jul 31, 2017, at 7:10 AM, John McCall via swift-evolution

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

On Mon, Jul 31, 2017 at 02:15 Gor Gyolchanyan via swift-evolution < swift-evolution@swift.org> wrote: > > On Jul 31, 2017, at 7:10 AM, John McCall via swift-evolution < > swift-evolution@swift.org> wrote: > > > >> On Jul 30, 2017, at 11:43 PM, Daryle Walker wrote: > >> The

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

> On Jul 31, 2017, at 7:10 AM, John McCall via swift-evolution > wrote: > >> On Jul 30, 2017, at 11:43 PM, Daryle Walker wrote: >> The parameters for a fixed-size array type determine the type's size/stride, >> so how could the bounds not be needed