[Pitch] #warning

Evolution Pitches
41

I would prefer that warning/error/todo/fixme were provided as special functions that take StaticString, rather than #directives.

I find that TODOs are really often related to temporary values in cases when the data sources are not yet set up, something like:

// TODO: Hook up to weather data source
let outsideTemperature  = 123

So I wrote 2 really useful functions:

func TODO(_ message: StaticString? = nil) {
	if let s = message { print("TODO: \(s)") }
}

@discardableResult
func TODO<T>(_ message: StaticString? = nil, _ temporaryValue: T) -> T {
	if let s = message { print("TODO: \(s)") }
	return temporaryValue
}

They use print, but the compiler could implement to issue a warning at compile-time and to just forward the temporaryValue as the expression result, at runtime. So now when I write my temporary value, it's coupled to the fact that it's a TODO temporary, with an explanatory message.

 let outsideTemperature = TODO("Hook up to weather data source", 123)

and I can find all of my TODOs by pulling up the call hierarchy for these 2 functions.

I think this generic value pass-through would be really useful to have in warning, error, TODO and FIXME (the exact names could vary, i'm just following the comment convention).

1 Like
42

But doesn't this just defeat the purpose of the proposal? # is the sigil for compiler magic in Swift, and this feature is about having the compiler emit warnings that will allow tooling to hook-into. If you replace this with functions you're forgoing the established convention that # is for compiler magic, and instead we have these magic functions.

If anything it should be:

let somethingSuspect = #warning("This is really the wrong function to call, but I'm being lazy", suspectFunction())
43

Yep, this is something I hadn't considered. And yeah, #warning should absolutely work in both of those positions in your example.

I'll revise the proposal to use "directive" consistently throughout. These aren't 'statements' in the Stmt sense of the word. I also need to put some special handling in switch parsing the same way we handle #if.

I'd really prefer if these things didn't even show up in the AST, but IIRC canImport isn't resolved at parse time, and thus forces us to keep track of these as declarations.

44

I don't really like the notion of #warning in expression position, because it precludes usage in #if conditionals for older platforms, etc.

45

I guess a directive is fine, as long as it can have this quality of being an expression

46

I believe these are both doable as @Harlan_Haskins says.

My another concern is something like this:

/// Doc comments
/// foobar
#warning "Remove this func ASAP!"
func somethingDeprecated() {
}

In this case, the doc comments are attached to #warning declaration instead of func . I think it's not so critical, but it's certainly a limitation.

1 Like
47

It’s something we could work around in SourceKit, but not something we could easily paper over in libSyntax :sweat_smile:

48

How does Swift currently handle the analogous situation with #if?

/// Comment on how important this function is.
#if condition
func f() {
  // ...
}
#else
func f() {
  // ...
}
#endif
49

It currently attaches the comment to the #if, which gets dropped (at least in Xcode's Quick Help), but I'd wager that a #warning directly above a function is more common than a #if.

50

Why wouldn't you just put the #warning inside the function?

51

Good point. I’d say that’s probably most common, but losing the connection between the function and the doc comment if you put the warning above is an unfortunate concession to make.

52

Hi guys, please forward this mail to the administrator of this forum, because I don't have an account on your site and I don't want to receive these notifications to which I have never subscribed to. I didn't ever have a swift forums account, by the way.

I don't know why I am receiving email notifications for this particular thread. I was subscribed to the swift evolution mailing list a long time ago, and I unsubscribed from the swift evolution mailing list a long time ago. I didn't receive any swift discussion emails since then. Now, out of nowhere, I'm receiving these mails about this proposed Swift warning function. The email notifications, which come from swift AT discoursemail DOT com don't contain any unsubscribe information or context information: no "you are receiving these mails because..." or "to unsubscribe, click here..." or any of that type; also no link to an admin or something; and even no link to the thread which is being discussed.

Please unsubscribe me. This is also a bug report: auto-generated emails should always contain some context (like unsubscribe-link, etc.)

-Michael

53

I'll follow up with Michael. It appears that by default the staged accounts generated from previous mailing list activity will send an email notification if someone replies to a thread that they were on. I'm working on addressing it.

Michael, I'll get your account fixed so you'll stop getting email.

1 Like