`export` as pragma

[metagn]

There are 2 syntaxes for exporting newly defined symbols in current Nim.

1. Postfix export marker:

let foo* = 3
proc foo* = discard
type Foo* = object
  foo*: int

2. Export statement:

export Foo, foo
export currentmodulename # ???

These have some weaknesses:

1. Postfix export marker: Hard to replicate in macros (class Foo*: is impossible). Complicates the parsing of things like tuple unpacking syntax. Complicates macros as well when used, as they have to account for its unique syntax.
2. Export statement: Does not work for every kind of symbol (fields for example), verbose, not very pretty. Also is a statement, so needs own line and cannot be replicated easily in macros.

The proposal is an additional syntax which also has weaknesses and is redundant in places; but is not super foreign, does not break existing code and compensates for the other export syntaxes.

Proposal

The export keyword can also be used as a pragma to export symbols it is attached to.

let foo {.export.} = 3
proc foo {.export.} = discard
type Foo {.export.} = object
  foo {.export.}: int

Advantages

• Separates visibility semantics from the syntax.
• Due to pragma expression syntax, class Foo {.export.}: compiles, meaning macros can use this.
• Allows for the possibility of {.push export.}, which saves having to type tons of *s. This would only inject export into where * is allowed.
• Since export is a keyword, there is way less of a chance of conflict with existing custom pragmas.

Criticisms

• Macros which check for exports will have to check for this as well.
  • Most macros only do this so they can make the output exported. If you just propagate pragmas, then the work will be done for you.
• It's ugly/verbose.
  • Yes, in fact *I still recommend `` for most purposes**, and the official style could share this opinion. Macros should also be pragma macros wherever it's possible, so special Nim syntax like export markers and objects can be directly used instead of having to be replicated. But this new syntax is still useful enough that I don't think it matters how ugly it is compared to the alternatives.
• This can be a pragma macro.
  • Not for fields. This would also cause issues when interacting with other macros and can't be pushed, Macros in general suck at being "standard" solutions for reasons beyond not being powerful enough.
• {.push export.} is bad practice.
  • For some code and purposes yes. I'd reckon its advantages still outweigh its disadvantages for other code and purposes.
• Too similar to exportc.
  • I'd say this is importc/exportc's fault for being named this way and they should have different names, but the average user shouldn't have to deal with this problem. So I don't know about this one.
• This requires a parser update.
  • {.cast().} was added recently.

[mratsim]

Having one way to two ways to do things in macros would seriously complicate their maintenance and lead to spaguetti if/elif/else

I don't see what's complex with the postfix marker. There is plenty of examples out there that exist today. If anything "How-to" are needed. If we now have both ways, writing an "How-to" will be even more complex.

Lastly you can write a template or macro as pragma to do what you want.

[metagn]

There were already some defenses to those statements in the post (except yes postfixes aren't really complex), and I would expand further, but yeah this is an unproductive proposal

[Araq]

The export method is for forwarding of symbols that stem from an imported module. It was never anticipated as an alternative to the export marker, that was a side-effect of the implementation that then got exploited.