Here's something that I ran into while writing dfix`s implicit string concatenation cleanup code:

```
// accepted
deprecated("This function is dumb and you shouldn't use it)
void deleteT3hH4rdDisk();

// accepted
deprecated("This function is dumb and" " you shouldn't use it)
void deleteT3hH4rdDisk();

// parse error
deprecated("This function is dumb and" ~ " you shouldn't use it)
void deleteT3hH4rdDisk();
```

According to this[1] the behavior is correct, however it is not intuitive that a programmer cannot split up the string for "deprecated" over multiple lines without depending on D's bug-prone behavior of implicitly joining adjacent string literals.

There are two solutions to this that I see, one is to allow a combination of string literals and "~" operators, and the other is to allow arbitrary expressions that evaluate to a string.

Right now I favor allowing string literals and "~" because it's a smaller change. I can write up a DIP for this if there's a decent chance of this getting approved.

[1] http://dlang.org/grammar.html#DeprecatedAttribute

On 5/31/15 11:33 PM, Brian Schott wrote:
> Here's something that I ran into while writing dfix`s implicit string
> concatenation cleanup code:
>
> ```
> // accepted
> deprecated("This function is dumb and you shouldn't use it)
> void deleteT3hH4rdDisk();
>
> // accepted
> deprecated("This function is dumb and" " you shouldn't use it)
> void deleteT3hH4rdDisk();
>
> // parse error
> deprecated("This function is dumb and" ~ " you shouldn't use it)
> void deleteT3hH4rdDisk();
> ```
>

Am I missing something, or is the trailing quote not required? (missing in all 3 examples).

-Steve

On Monday, 1 June 2015 at 15:24:37 UTC, Steven Schveighoffer wrote:
> Am I missing something, or is the trailing quote not required? (missing in all 3 examples).

Either that or I made a typo and copied/pasted it.

Is there any reason to not allow argument to be any expression and reject non-string ones at semantic phase?

On Tuesday, 2 June 2015 at 18:44:30 UTC, Dicebot wrote:
> Is there any reason to not allow argument to be any expression and reject non-string ones at semantic phase?

Probably just simplicity and the fact that it really doesn't make sense to use anything other than a string literal in a deprecated message. It's just that not allowing ~ in it makes it difficult when the string gets long (which you usually should avoid, but sometimes, it's unavoidable).

Personally, I don't really care with any string argument is permitted so long as its value is known at compile time, but the only way that it would even vaguely make sense was if someone were doing something to automatically generate deprecation messages, which seems rather odd to me. Maybe so they can put a date in them, and they only want to put that date in one place? Certainly, I have to stretch to think of a reason why you'd ever do anything more than "msg" or "msg" ~ "msg".

- Jonathan M Davis

"Dicebot"  wrote in message news:odfsgqcftykjkztsgqmc@forum.dlang.org...

> Is there any reason to not allow argument to be any expression and reject non-string ones at semantic phase?

The original reason is that trying to reference manifest constants etc from that context resulted in forward reference errors, so allowing only string literals was easier.  I'm guessing those problems have since been fixed, so allowing any ct expression that resolves to a string should be fine now.