Restrict the type of the last expression in at-eval blocks

[mortenpi]

Currently, you are generally allowed to have at-eval to return anything, and the resulting object will get spliced into the document somehow, but we do not really define how we treat arbitrary objects (HTML just reprs them and dumps the resulting string as text in the document).

In practice, and based on our docs, most of the time you're expected to either return nothing (so nothing gets displayed) or Markdown.MD (so you get properly rendered Markdown). This makes that requirement general and explicit, making it easier to support this block in the writers (that now know that it will always be either nothing or Markdown.MD, and don't have to deal with arbitrary types).

This can be breaking because it was possible to get somewhat reasonable output for some return types and it's possible that people are using it (in particular, I am concerned about cases where people might be returning various Markdown.* nodes without wrapping them in Markdown.MD). For that reason, this does not make that case quite an error, but instead you get a warning, and the resulting object is showed into a text representation and displayed as a code block (so there is behavior change for users).

[fredrikekre]

Perhaps possible to display the same as an example block?

[mortenpi]

Yeah, I agree, I think eventually we want to treat this the same as at-example. But I would stick to this change for now, to make my life a little easier in #1912 and in its HTML counterpart. Properly rendering non-Nothing/Markdown.MD elements can be done as a non-breaking enhancement in the future.

[fredrikekre]

Yea, and maybe it makes sense to keep that restriction. If you want an example block you can just use an example block (the only advantage would be hiding the code by default I suppose).

[mortenpi]

Yea, and maybe it makes sense to keep that restriction. If you want an example block you can just use an example block (the only advantage would be hiding the code by default I suppose).

Let's leave that as an open issue for now.