Re: [swift-dev] Rationalizing FloatingPoint conformance to Equatable

> On Nov 2, 2017, at 4:22 PM, Xiaodi Wu via swift-dev > wrote: > > On Thu, Nov 2, 2017 at 5:22 PM, Matthew Johnson > wrote: > >> On Nov 2, 2017, at 5:20 PM, Jonathan Hull via swift-dev > > wrote: >> >> It looks like we have a good so

Re: [swift-dev] SR-3423 Starter questions

> On Nov 13, 2017, at 6:00 AM, Brent Royal-Gordon via swift-dev > wrote: > >> On Nov 11, 2017, at 2:59 PM, Mohammed Ennabah via swift-dev >> mailto:swift-dev@swift.org>> wrote: >> >> I dug into the codebase as stated in the steps you mentioned, and tried to >> change one of the errors to see

[swift-dev] Todo cleanups & such

In "SILFunction.h", line 171, it says, /// The function's set of semantics attributes. /// /// TODO: Why is this using a std::string? Why don't we use uniqued /// StringRefs? llvm::SmallVector SemanticsAttrSet; As an outside contributor, seeing as how I have no idea why a std::string was

Re: [swift-dev] Rationalizing FloatingPoint conformance to Equatable

> On Nov 1, 2017, at 10:21 AM, Xiaodi Wu wrote: > > > On Tue, Oct 31, 2017 at 23:43 David Sweeris > wrote: > > On Oct 31, 2017, at 20:58, Xiaodi Wu > wrote: > >> On Tue, Oct 31, 2017 at 10:50 PM, Xiaodi Wu >

Re: [swift-dev] Rationalizing FloatingPoint conformance to Equatable

> On Oct 31, 2017, at 20:58, Xiaodi Wu wrote: > >> On Tue, Oct 31, 2017 at 10:50 PM, Xiaodi Wu wrote: >>> On Tue, Oct 31, 2017 at 10:23 PM, David Sweeris wrote: >>> On Oct 31, 2017, at 7:26 PM, Xiaodi Wu wrote: > On Tue, Oct 31, 2017 at 5:56 PM, David Sweeris > wrote: >>

Re: [swift-dev] Rationalizing FloatingPoint conformance to Equatable

> On Oct 31, 2017, at 7:26 PM, Xiaodi Wu wrote: > > On Tue, Oct 31, 2017 at 5:56 PM, David Sweeris > wrote: > > On Oct 31, 2017, at 09:07, Stephen Canon via swift-dev > wrote: > >> [Replying to the thread as a whole] >> >> There have b

Re: [swift-dev] Rationalizing FloatingPoint conformance to Equatable

> On Oct 31, 2017, at 09:07, Stephen Canon via swift-dev > wrote: > > [Replying to the thread as a whole] > > There have been a bunch of suggestions for variants of `==` that either trap > on NaN or return `Bool?`. I think that these suggestions result from people > getting tunnel-vision on

Re: [swift-dev] Rationalizing FloatingPoint conformance to Equatable

> On Oct 31, 2017, at 9:07 AM, Stephen Canon via swift-dev > wrote: > > [Replying to the thread as a whole] > > There have been a bunch of suggestions for variants of `==` that either trap > on NaN or return `Bool?`. I think that these suggestions result from people > getting tunnel-vision o

Re: [swift-dev] Rationalizing FloatingPoint conformance to Equatable

> On Oct 27, 2017, at 3:06 AM, Jonathan Hull via swift-dev > wrote: > >> >> On Oct 26, 2017, at 11:44 PM, Xiaodi Wu > > wrote: >> >> On Fri, Oct 27, 2017 at 1:30 AM, Jonathan Hull > > wrote: >> One completely different idea, which I brought u

Re: [swift-dev] Rationalizing FloatingPoint conformance to Equatable

> On Oct 26, 2017, at 3:16 PM, Matthew Johnson wrote: > >> >> On Oct 26, 2017, at 5:12 PM, David Sweeris via swift-dev >> mailto:swift-dev@swift.org>> wrote: >> >> >>> On Oct 26, 2017, at 2:57 PM, Greg Parker via swift-dev >> <m

Re: [swift-dev] Rationalizing FloatingPoint conformance to Equatable

> On Oct 26, 2017, at 2:57 PM, Greg Parker via swift-dev > wrote: > >> >> On Oct 26, 2017, at 11:47 AM, Xiaodi Wu via swift-dev > > wrote: >> >> On Thu, Oct 26, 2017 at 1:30 PM, Jonathan Hull > > wrote: >> Now you are just being rude. We all

Re: [swift-dev] Rationalizing FloatingPoint conformance to Equatable

> On Oct 26, 2017, at 9:40 AM, Xiaodi Wu wrote: > > On Thu, Oct 26, 2017 at 11:38 AM, Jonathan Hull > wrote: > >> On Oct 26, 2017, at 9:34 AM, Xiaodi Wu > > wrote: >> >> On Thu, Oct 26, 2017 at 10:57 AM, Jonathan Hull >

Re: [swift-dev] Rationalizing FloatingPoint conformance to Equatable

> On Oct 25, 2017, at 5:29 AM, David Zarzycki via swift-dev > wrote: > > > >> On Oct 25, 2017, at 02:34, Xiaodi Wu via swift-dev > > wrote: >> >> Please see earlier replies summarizing core team members' persuasive >> arguments as to why not multiple protocol hie

Re: [swift-dev] Rationalizing FloatingPoint conformance to Equatable

> On Oct 24, 2017, at 9:06 PM, Xiaodi Wu via swift-dev > wrote: > > On Tue, Oct 24, 2017 at 10:08 PM, Ben Cohen > wrote: > > > On Oct 24, 2017, at 6:48 PM, Xiaodi Wu > wrote: > >> On Tue, Oct 24, 2017 at 1:55 PM, Ben Cohen >

Re: [swift-dev] What can you change in a non-exhaustive enum?

> On Sep 29, 2017, at 18:21, Jordan Rose via swift-dev > wrote: > > Hello again, swift-dev! This is a sort of follow-up to "What can you change > in a fixed-contents struct" from a few weeks ago, but this time concerning > enums. Worryingly, this seems to be an important consideration even fo

Re: [swift-dev] Value-type bound protocols?

> On Sep 13, 2017, at 09:54, David Zarzycki via swift-dev > wrote: > > Hello, > > As a part of a research project that I’m working on, I’ve started bumping > into the need for value-type bound protocols (as opposed to the existing > class bound protocols). Is this something that would be wor

Re: [swift-dev] Advice for implementing "literal values as generic types"

> On Aug 30, 2017, at 8:01 AM, Robert Widmann wrote: > >> >> On Aug 29, 2017, at 5:22 PM, David Sweeris via swift-dev >> mailto:swift-dev@swift.org>> wrote: >> >> >>> On Aug 29, 2017, at 1:49 PM, Slava Pestov >> <mailto:spes...@ap

Re: [swift-dev] Advice for implementing "literal values as generic types"

> On Aug 30, 2017, at 8:15 AM, Tino Heth <2...@gmx.de> wrote: > > That's a great choice ;-) — if I had the time, this would be the > Swift-feature I'd spend it for… Yeah, I remember your enthusiasm for it back when the topic first came up :-) > I hope you have the stamina to finish that lol

Re: [swift-dev] Advice for implementing "literal values as generic types"

> On Aug 29, 2017, at 15:47, David Zarzycki wrote: > > Hi David, > > To add to what I wrote earlier, the design of the Swift is such that adding > new features isn’t “hard”, but it does require time and patience because most > new features have ripple effects on other parts of the compiler tha

Re: [swift-dev] Advice for implementing "literal values as generic types"

> On Aug 29, 2017, at 14:31, Slava Pestov wrote: > > >>> On Aug 29, 2017, at 2:21 PM, David Sweeris wrote: >>> >>> >>>> On Aug 29, 2017, at 1:49 PM, Slava Pestov wrote: >>>> >>>> >>>> On Aug 29, 2017

Re: [swift-dev] Advice for implementing "literal values as generic types"

; custom RTTI logic (which is partly why these “.defs” files exist), and > therefore language features like multiple inheritance don’t “just work” like > you might expect. > > Dave > > >> On Aug 29, 2017, at 14:04, David Sweeris via swift-dev > <mailto:swift-dev@swift.o

Re: [swift-dev] Advice for implementing "literal values as generic types"

> On Aug 29, 2017, at 1:49 PM, Slava Pestov wrote: > > >> On Aug 29, 2017, at 11:03 AM, David Sweeris via swift-dev >> wrote: >> >> Hi everyone! I'm trying to implement literal values as generic types. > > Can you briefly explain what you

[swift-dev] Advice for implementing "literal values as generic types"

Hi everyone! I'm trying to implement literal values as generic types. So far, I've made `LiteralExpr` inherit from both `Expr` and `GenericTypeDecl` (instead of just `Expr`), and did whatever other changes were necessary to get that compiling (mostly putting several "using Expr::setImplicit;" ki

Re: [swift-dev] Build Failure with Xcode 9.0 beta 5

I missed the 4th beta release, and couldn't find it on Apple's site (I could find the command line tools for Xcode 9 beta 4 in the "other downloads" section, but not Xcode 9 beta 4 itself). For anyone else who needs it and is having trouble finding it, the URL is the same as Xcode 9 beta 5's, bu

[swift-dev] Possible Typo in the Swift 4 snapshot's implementation of FixedWidthInteger

> Proposal link: > https://github.com/apple/swift-evolution/blob/master/proposals/0104-improved-integers.md > > Is this correct? The “*" function has the “by” argument label and the “/“ function doesn’t

Re: [swift-dev] How to create my first pull request

> On Mar 27, 2017, at 1:10 PM, Pavol Vaskovic via swift-dev > wrote: > > Hi! > > I’d like to create my first full request (as requested by Jordan Rose in > SR-4373 ), but I didn’t find enough > information about how to proceed on the Swift’s Contributin

Re: [swift-dev] Anyone else having trouble getting swift to build?

> On Mar 5, 2017, at 3:23 PM, David Sweeris via swift-dev > wrote: > > >> On Mar 5, 2017, at 15:15, Jacob Bandes-Storch wrote: >> >> No, just having the command-line tools set to the beta should be fine. Also, >> moving this to swift-dev. > > K,

[swift-dev] Anyone else having trouble getting swift to build?

> On Mar 5, 2017, at 15:15, Jacob Bandes-Storch wrote: > > No, just having the command-line tools set to the beta should be fine. Also, > moving this to swift-dev. K, I'll double-check that when I get back in front of my computer. - Dave Sweeris __

Re: [swift-dev] [Pitch] Remove "Default will never be executed" Warning?

> On Nov 26, 2016, at 5:25 PM, Robert Widmann via swift-dev > wrote: > > Hello all, > > I’ve seen and been a part of a number of conversations recently where talk of > planning for “resilient enums”, or even just authors that ship frameworks > that will eventually offer a binary option that

Re: [swift-dev] Set of "no less than one" member enforced by the compiler

I've been thinking about this, too. At one point I had a reason to want an Array that couldn't be empty (though I can't recall what the reason was now). Anyway, I think I'd do something like this: struct NonEmptyCollection : CollectionType { private var _head: T.Generator.Element? //optional

Re: [swift-dev] Delaying the enforcement of ".self" out of Swift 3?

> On Jun 2, 2016, at 3:24 PM, Erica Sadun via swift-dev > wrote: > > 3. If it can be fixed, fix it. (It is a bug.) And THEN change the language > using the normal SE evolution process. I thought “Deferred out of Swift 3” meant that it was accepted, but there isn’t enough time to get it done.

Re: [swift-dev] Potential Bug in SE-0029 (Remove implicit tuple splat behavior from function applications)

t themselves. You can always > release the ticket if you decide you can't or don't want to work on it > anymore. > > Austin > >> On Apr 18, 2016, at 3:53 PM, David Sweeris via swift-dev >> mailto:swift-dev@swift.org>> wrote: >> >> Done

Re: [swift-dev] Potential Bug in SE-0029 (Remove implicit tuple splat behavior from function applications)

Done. https://bugs.swift.org/browse/SR-1261 Out of curiosity, what happens if I click “Assign to me”? I think it’d be kinda fun to try to fix the glitch, but I don’t have the faintest idea where to start. - Dave Sweeris > On Apr 18, 2016, at 5:31 PM, David Sweeris via swift-dev >

Re: [swift-dev] Potential Bug in SE-0029 (Remove implicit tuple splat behavior from function applications)

Sure > On Apr 18, 2016, at 4:25 PM, Jordan Rose wrote: > > Good catch. Seems like an issue with the diagnostic. Can you file a bug at > bugs.swift.org <http://bugs.swift.org/>? > > Jordan > >> On Apr 18, 2016, at 13:45, David Sweeris via swift-dev >

[swift-dev] Potential Bug in SE-0029 (Remove implicit tuple splat behavior from function applications)

I was updating some old code to Swift 2.2, and came across an unexpected tuple splat warning. This code is all you need to generate the deprecation warning: public class Value { public typealias Element = T public typealias Ret = T } public class Expression : Value { public typealias A