parser: ensure @[deprecated_after] works without @[deprecated]

[dy-tea]

Fixes #25471.

@[deprecated: 'use d() instead']
fn d1() {
}

@[deprecated_after: '2025-10-10']
fn d2() {
}

@[deprecated: 'use d() instead']
@[deprecated_after: '2025-10-10']
fn d3() {
}

fn main() {
	d1()
	d2()
	d3()
}

Used to print:

❯ v run test.v
test.v:15:2: warning: function `d1` has been deprecated; use d() instead
   13 |
   14 | fn main() {
   15 |     d1()
      |     ~~~~
   16 |     d2()
   17 |     d3()
test.v:17:2: warning: function `d3` has been deprecated since 2025-10-10, it will be an error after 2026-04-08; use d() instead
   15 |     d1()
   16 |     d2()
   17 |     d3()
      |     ~~~~
   18 | }

Didn't add a test as this would change depending on the date which would be tricky.

[huly-for-github]

Connected to Huly®: V_0.6-26162

[JalonSolov]

I think I'm against this. Since there is no message parameter for deprecated_after, all you get is the deprecation dates... there is no possibility to let someone know an alternative for the deprecated item, other than them digging through docs.

That means allowing deprecated_after without deprecated give less functionality than forcing them to be used together.

The other alternative, of course, would be to support all the functionality in a single attribute.

[dy-tea]

Yeah I don't disagree but in the current state we don't get any deprecation warning at all when using @[deprecated_after] by itself.
As @spytheman said we could instead require @[deprecated] if @[deprecated_after] is used or simply change it to support both as you say.

[dy-tea]

Coming back to this I think we have two options:

• require @[deprecated] when @[deprecated_after] is present and fix any instances of this occurring
• add optional date parameter to @[deprecated] and phase out @[deprecated_after] with a checker warning

Which do we think is better?

[JalonSolov]

Personally, I'm all for a single @[deprecated] attribute.

[dy-tea]

I agree, I think we could even introduce a vmft that changes to the new syntax and it will end up not being too much work.

[dy-tea]

I have a working concept that looks like this:

@[deprecated: '2025-10-10 use new function instead']
fn d0() {}

@[deprecated: '1234567890']
fn d1() {}

@[deprecated: '']
fn d2() {}

@[deprecated: 'a']
fn d3() {}

@[deprecated: 'greater than 10 chars']
fn d4() {}

@[deprecated: '2025-10-10close']
fn d5() {}

@[deprecated: ' 2025-10-10']
fn d6() {}

This would output:

test.v:23:2: warning: function `d0` has been deprecated since 2025-10-01, it will be an error after 2026-03-30;  use new function instead
   21 |
   22 | fn main() {
   23 |     d0()
      |     ~~~~
   24 |     d1()
   25 |     d2()
test.v:24:2: warning: function `d1` has been deprecated; 1234567890
   22 | fn main() {
   23 |     d0()
   24 |     d1()
      |     ~~~~
   25 |     d2()
   26 |     d3()
test.v:25:2: warning: function `d2` has been deprecated
   23 |     d0()
   24 |     d1()
   25 |     d2()
      |     ~~~~
   26 |     d3()
   27 |     d4()
test.v:26:2: warning: function `d3` has been deprecated; a
   24 |     d1()
   25 |     d2()
   26 |     d3()
      |     ~~~~
   27 |     d4()
   28 |     d5()
test.v:27:2: warning: function `d4` has been deprecated; greater than 10 chars
   25 |     d2()
   26 |     d3()
   27 |     d4()
      |     ~~~~
   28 |     d5()
   29 |     d6()
test.v:28:2: warning: function `d5` has been deprecated since 2025-10-01, it will be an error after 2026-03-30; close
   26 |     d3()
   27 |     d4()
   28 |     d5()
      |     ~~~~
   29 |     d6()
   30 | }
test.v:29:2: warning: function `d6` has been deprecated since 2025-10-01, it will be an error after 2026-03-30
   27 |     d4()
   28 |     d5()
   29 |     d6()
      |     ~~~~
   30 | }

Another option is supporting multiple values in an attribute (which currently is not supported) like:

@[deprecated: 'use d() instead', '2025-10-10'; noreturn]
fn d1() {
    for {}
}

[JalonSolov]

If it can only have 1 parameter, I'd still like to see a separator between the date and msg:

@[deprecated: '2025-10-14!message']

doesn't have to be !, just needs to be something there.

It would be handy if attributes worked similarly to functions with trailing struct literal parameters, so you could supply parameters by: all of them in order, none of them, supply in a different order by naming them, etc., etc.

[dy-tea]

Yeah would be good to have this. Was thinking either a separator like $$ or having the date within something like ${2025-10-10} or {{2025-10-10}}.

Edit: $$ wouldn't work I think

[dy-tea]

Pushed a version that uses !! as a separator. Another thing to consider is if deprecated dates should be allowed without a message; in my current implementation it is allowed.

[JalonSolov]

Yes, they should be. There might not be a reason to give a message, just deprecation dates.

[Eliyaan]

Why did the deprecation date change from being the date of the end of support to the date of the start of the deprecation? (it is also a bit wierd because the date in the message is 2025 10 01 but in the code it is 2025 10 10l be an error after 2026-03-30)
I would personnally prefer to put the date of the end of support in the code, as not everyone has the same deprecation wait times (seems to be 6 month in the example)

[JalonSolov]

The date changed because nobody has seen the deprecation notice before, since it was ignored with only @[deprecated_after]. That's what this PR is trying to fix.

If the date was left the same, they would suddenly start getting a deprecation message, but it would also immediately be an ERROR instead of just a WARNING for the first 6 months (since that much time has already passed since the original date).

And yes, it was decided that V would use a 6 month deprecation window.

[spytheman]

I've implemented the simpler alternative in #25712 , that always requires @[deprecated] to be used, if @[deprecated_after] is, by a warning. Both attributes are already documented in doc/docs.md and there is no need for complecting them and adding special separators to split the content of a single attribute etc.