Re: runnableExamples should generally be preferred to `.. code-block:: nim`

isn't the whole point of rst though that it's sufficiently structured to extract detailed code blocks to pass to the compiler? ie if you're not using this feature of rst, it's completely useless compared to markdown which has a much larger developer mindshare. tbh, I found the runnableExamples

Re: runnableExamples should generally be preferred to `.. code-block:: nim`

regarding editors, the same applies - an editor could easily provide ide features in code block sections thanks to RST

unary operators are often best replaced by explicit names, eg: `%*` => toJson

IMO, unary operators are often best replaced by explicit names. For eg: %* in [https://nim-lang.github.io/Nim/json.html#%25%2A.m%2Cuntyped](https://nim-lang.github.io/Nim/json.html#%25%2A.m%2Cuntyped) would be best replaced by toJson (and %* could become a deprecated alias to it):

Re: nim doc hypertext link

@geezer9 maybe send a bug report /feature request on [https://github.com/nim-lang/Nim/issues](https://github.com/nim-lang/Nim/issues) ?

Re: Capabilities of backend compiler and conditional flags

Seems indeed useful to have a standard library module for that. Could be based on stuff like this : const output = staticExec("cc --version")` when output.hasSomeProperty: ... # eg: check version > something Run const hasLTO = not staticExec("clang

Capabilities of backend compiler and conditional flags

Increasingly, I've been running into situations where it would be beneficial, from a cross-platform and cross-compiler point of view, to selectively enable flags and features depending on the capabilities and defaults of the C compiler is being used. There is some support for doing stuff like

Re: what happened to Nim community survey 2018?

Yeah, sorry, I simply didn't get a chance to do the write up yet.

Re: runnableExamples should generally be preferred to `.. code-block:: nim`

Some of my `runnableExamples` also has `.. code-block:: nim` ;P Actually I changed from `when is_main_module:` to `runnableExamples` (for libs), is the correct way. I think is an awesome feature, because other lang have DocTests or the like (Python, Rust, etc), but the code is on comments,

runnableExamples should generally be preferred to `.. code-block:: nim`

.. code-block:: nim (or similar) tends to go out of date eg [1], unlike runnableExamples which is guaranteed to stay in sync. runnableExamples is also easier to write IMO. ## links /cc @dom96| ---|--- * for eg:

what happened to Nim community survey 2018?

* [https://nim-lang.org/blog/2018/06/23/community-survey-2018.html](https://nim-lang.org/blog/2018/06/23/community-survey-2018.html) was launched in june ## links *

Question regarding --warning[ProveField] and proc params

I recently learning about the --warning[ProveField] flag for object variants, and enjoy the increased level of type checking that it provides. However, I have a small issue using this flag alongside procedures that take a specific branch of the object variant. The procedures shouldn't be used

docgen user defined role

Can a user define a custom "role" for the interpretation of ## source comments by docgen? The site <[http://docutils.sourceforge.net/docs/howto/rst-roles.html](http://docutils.sourceforge.net/docs/howto/rst-roles.html)> explains how to do this, but the context is python programming. Can this

Re: Some questions about Nim compiler parameters

Thank you both, this helped alot!