unittest => 1==1;
unittest math_still_works => 1==1;//generates ddoc

I see roughly 3 criticisms to my last suggestion

1. unittest without docs are bad
2. this is a bug; that should already work (???)
3. we may want agrumented unittests in the future

so handling the arguments out of order

2.

what? whatever i'll simplify the syntax

3.

by not using ()'s I assume it will leave open the door for whatever this theory is

1. docs

I dont care about this in the slightest but... whatever

unittest [name] => code;

if optional name exists generate a header and code in ddoc

name will replace'_'s with spaces, put it in a header followed by a code block of the code

so given this code

/**
* a very important function
*/

auto foo=>[1,2,3,4,5];
unittest foo_returns_an_array=>foo==[1,2,3,4,5];

will generate the docs

# foo
## int[] foo()

a very important function

## foo returns an array

```d
foo==[1,2,3,4,5];

On Sunday, 16 March 2025 at 06:40:46 UTC, Walter Bright wrote:

unittest { assert(expression); }

unittest (parameters) { assert(expression); }

It’s the same case as in and out and invariant contracts, the fact that the concise version exists makes programmers more likely to actually write them.

For the cases you point out, the parser can look ahead and see if the closing parenthesis is followed up by a semicolon or an opening brace.

On Monday, 14 April 2025 at 18:16:08 UTC, Quirin Schroll wrote:

unittest { assert(expression); }

unittest (parameters) { assert(expression); }

I think they're quite different; unit tests are extremely unlikely to be one liners, whereas contracts are very likely to be exactly that.