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

Based on the feedback from this list, I’ve submitted a revised proposal as PR #353. https://github.com/apple/swift-evolution/pull/353 Thanks, Harlan > On Jun 1, 2016, at 9:25 PM, Ben Langmuir via swift-evolution > wrote: > >> >> On Jun 1, 2016, at 10:54 AM,

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

> On Jun 1, 2016, at 10:54 AM, Jordan Rose via swift-evolution > wrote: > >> >> On May 29, 2016, at 13:20, Chris Lattner via swift-evolution >> > wrote: >> >>> On May 29, 2016, at 12:58 PM, Erica Sadun

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

On Jun 1, 2016, at 3:56 AM, Jeremy Pereira via swift-evolution wrote: >> One may argue that the comment-based markings can be handled by the IDE, but >> IMO transferring language features onto IDE is wrong. These comments do not >> appear anywhere within the log when

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

> On May 29, 2016, at 13:20, Chris Lattner via swift-evolution > wrote: > >> On May 29, 2016, at 12:58 PM, Erica Sadun wrote: >> One could make a weak argument that #warning/#error/#message make a nice >> family of flexible alerts >> just

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

> On 31 May 2016, at 18:53, Charlie Monroe via swift-evolution > wrote: > > The way I see it and would use it: > > Directives: > > #error - fatal error, the binary shouldn't compile - e.g. unknown OS host and > the code depends on underlying OS features. > >

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

Thank you Charlie, just exactly what I think regarding all these #errors/#warnings/comments etc On 31.05.2016 19:53, Charlie Monroe via swift-evolution wrote: The way I see it and would use it: Directives: *#error* - fatal error, the binary shouldn't compile - e.g. unknown OS host and the

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

> Le 31 mai 2016 à 18:31, Leonardo Pessoa via swift-evolution > a écrit : > > In your alternatives considered, you mention "not all TODO or FIXME > comments should surface" but I think the opposite Well, use #warning TODO, then. The proposal works well with several

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

In your alternatives considered, you mention "not all TODO or FIXME comments should surface" but I think the opposite: if I want these types of comments to be seen as warnings by the compiler I cannot choose which will surface and which not. It would be the same as saying "hey, but I don't want

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

> On May 30, 2016, at 2:35 PM, Chris Lattner via swift-evolution > wrote: > > >> On May 29, 2016, at 10:36 PM, Charlie Monroe >> wrote: >> >>> As to #warning, Swift’s use of warnings are significant different than the >>> use in C. In

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

+1. This is definitely a useful feature to have and helps advance a clear and common pattern among programmers in general. > On May 28, 2016, at 4:58 PM, Harlan Haskins via swift-evolution > > wrote: > > Hey everyone, > > I’m

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

Btw, FWIW, regarding the state that some warning semantics can change later.. @warn_unused_result func TODO()->Bool {return true} Then in code: TODO(/*Make it faster*/) // any comment you want Will have: WARNING at line 12, col 3: result of call to 'TODO()' is unused TODO(/*Make it

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

> On May 29, 2016, at 10:36 PM, Charlie Monroe > wrote: > >> As to #warning, Swift’s use of warnings are significant different than the >> use in C. In C compilers, many of the warnings produced *should* be errors, >> but can’t be because that effects language

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

1. I don't think we'll lose 'unused value' warning in future, probably another warning could be found for this 'feature' that definitely will not be dropped. 2. The point was that currently we can 'emulate' user-defined warnings *if we really wants*. I believe we need special #warning or

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

Hmm... and like `#warning` : let TODO_WeNeedToMakeItFaster = "Current implementation is too slow, use " // some comments that you need to show and we have a warning(unused value)! from compiler! with WARNING at line 8, col 7: initialization of immutable value

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

Something similar to #error seems to be already implemented ;) #if os(iOS) import Error_sorryThisDoesntWorkOnIOSyet #endif I know it's a hack, but it works :) And the good thing is, there is no way to prevent these kind of hacks.. (but IMHO, #error would look nicer) -Michael > Am

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

I also think that we need standardized feature for todo/fixme in language, so when you got one's code you can have all needed warnings the creator wants to produce. I.e. probably not some directive, but some kind of.. special comment? So XCode/any 3rd party tools/IDE will know about this

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

On Sun, May 29, 2016 at 3:49 PM Leonardo Pessoa via swift-evolution < swift-evolution@swift.org> wrote: > Tools like SonarQube can raise a "warning" for comments started with > "TODO:" or "FIXME:". Wouldn't it be more interesting if those could be > presented as warnings instead of using

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

I've used custom warnings and errors in other languages and find them both useful. Forgive my ignorance, but does Swift have warning levels, warning IDs and pragmas/build settings to disable specific warnings? If so, it would be good to specify exactly how this feature interact with those. For

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

> As to #warning, Swift’s use of warnings are significant different than the > use in C. In C compilers, many of the warnings produced *should* be errors, > but can’t be because that effects language conformance and could break a > large body of code. The example I've mentioned with #error,

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

FWIW, I'm also in favor of adding #error to the language. It would be good to express invariants that the compiler can't know about, like mutually exclusive build config options that affect code downstream. I'm definitely seeing how #warning might conflict with the goals of Swift's warnings.

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

compilation. -Original Message- From: "Will Stanton via swift-evolution" <swift-evolution@swift.org> Sent: ‎29/‎05/‎2016 07:09 PM To: "Harlan Haskins" <har...@harlanhaskins.com> Cc: "swift-evolution" <swift-evolution@swift.org> Subject: Re

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

+1 to #warning or optionally(?) emitting something like TODO: more visibly! In past ObjC projects, I have used #warning to confirm the right macros were enabled. I often (1) work around differences between the iOS simulator and device with TARGET_IPHONE_SIMULATOR (+similar) and (2) change API

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

> On May 29, 2016, at 12:58 PM, Erica Sadun wrote: > One could make a weak argument that #warning/#error/#message make a nice > family of flexible alerts > just because they're kind of what we're used to already. Right: it isn’t a bad thing at all, but it is certainly the

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

> On May 29, 2016, at 1:44 PM, Chris Lattner via swift-evolution > wrote: > > >> On May 28, 2016, at 8:26 PM, Jon Shier via swift-evolution >> wrote: >> >> I appreciate the sentiment, but I think we should reserve warnings for >>

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

> On May 28, 2016, at 8:26 PM, Jon Shier via swift-evolution > wrote: > > I appreciate the sentiment, but I think we should reserve warnings for > actual compiler diagnostics. +1. The IDE should just pick up "// FIXME: “ comments and summarize them as

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

#warning isn't exclusively used for FIXMEs. Languages that include these kinds of features do things like flag old modules or unsupported OSes and older Swift versions by combining it with #if - a feature Swift implements far richer conditionals for than other languages I might add. The kinds

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

I can see where you're coming from, but I don't necessarily see this as "warnings which can then be ignored." In my vision, this enables developers to increase visibility of known issues, instead of letting them sit. Developers who would normally use this feature to add their own warnings are

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

I appreciate the sentiment, but I think we should reserve warnings for actual compiler diagnostics. If you wish to add another, user definable diagnostic type, like official compiler support for a #todo or #fixme flag, then go ahead. But adding #warning because the IDE (read Xcode)

[swift-evolution] [Pitch] #warning

Hey everyone, I’m working on a draft for #warning in Swift. I’ve implemented the draft as it stands, and it’s pretty nice to work with. I’ve pasted it below, and I’d love some feedback! Thanks! — Harlan Haskins #warning Proposal: SE-