Mime-Version: |
1.0 (Apple Message framework v935.3) |
Sender: |
|
Subject: |
|
From: |
|
Date: |
Mon, 10 Aug 2009 17:08:42 +0930 |
In-Reply-To: |
|
Content-Type: |
multipart/signed; boundary=Apple-Mail-1-999783362; micalg=sha1;
protocol="application/pkcs7-signature" |
Reply-To: |
|
Parts/Attachments: |
|
|
On 10/08/2009, at 4:45 PM, Joseph Wright wrote:
> 1) Design functions which clearly are expandable (such as \IfBooleanTF
> or the version of \IfNoValue in xparse-alt): these should left alone
> as
> they will behave "nicely".
>
> 2) Design functions which are not expandable (at least under pdfTeX or
> XeTeX: LuaTeX raises lots of issues, I suspect). This includes
> \ExplSyntaxOn/Off, \DeclareDocumentCommand and so on. I'd suggest that
> these should be \protected.
>
> I'm not saying it's likely that \edef-ing things like
> \DeclareDocumentCommand is likely, but that it seems more consistent.
Yes, this is sensible to me.
It's (essentially) an extension of how \def itself is \protected.
So I would say: any user-level command defined in LaTeX3 that is not
expandable should be protected. And any user-defined command (with
xparse) is protected, no matter what (I can't think of a case, off the
top of my head, where this is undesirable).
* * *
Moving slightly off-topic, but related to the discussion of protected
control sequences:
l3basics, in the docs for \cs_set_protected, says to use \exp_after:wN
\prg_do_nothing: if you want to expand a protected control sequence in
an expanding context. What do you think about the idea of providing a
command called \exp_protected:N for doing this? (I.e., good idea or
bad idea? Or unnecessary?)
Will
|
|
|