User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-GB; rv:1.9.2.14)
            Gecko/20110221 Thunderbird/3.1.8
MIME-Version: 1.0
References: <4D731368.1060701@gmx.de> <4D7335FC.3050007@morningstar2.co.uk>    
            <19827.15373.437917.416434@morse.mittelbach-online.de>           
            <4D735487.8070809@morningstar2.co.uk> <4D73663A.5020508@gmx.de>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Message-ID:  <4D737EC5.5090809@morningstar2.co.uk>
Date:         Sun, 6 Mar 2011 12:32:05 +0000
Reply-To: Mailing list for the LaTeX3 project
              <LATEX-L@listserv.uni-heidelberg.de>
Sender: Mailing list for the LaTeX3 project <LATEX-L@listserv.uni-heidelberg.de>
From: Joseph Wright <joseph.wright@MORNINGSTAR2.CO.UK>
Subject: Re: \coffin_new:c ?
To: LATEX-L@listserv.uni-heidelberg.de
In-Reply-To:  <4D73663A.5020508@gmx.de>
Precedence: list
Status: R

On 06/03/2011 10:47, Arno Trautmann wrote:
>> When I rewrote the coffins code, I originally included "c" variants, but
>> decided to leave them out pending seeing whether they were needed. I've
>> no objection to them, I was just trying to avoid 'variant overkill'.
>> Note that if you allow "c"-type names, then it's not just \coffin_new:N
>> that needs variants. All of the 'code-level interface' functions should
>> be done for consistency. This is the work of 5 minutes: shall I make the
>> change?
> 
> If no one else has needed it so far, I'll just add it to my package. I
> only asked to see if there was a special reason that coffin names should
> not be handled this way.

As I said, what would be nice is an idea of the context. It may well be
that we need the "c" variants: after all, until people try these things
out then it's hard to know.
-- 
Joseph Wright