RFC curl

Jonathan M Davis jmdavisProg at gmx.com
Thu Nov 10 02:21:22 PST 2011


On Thursday, November 10, 2011 10:58:14 Jacob Carlborg wrote:
> On 2011-11-10 09:50, Jonathan M Davis wrote:
> > On Thursday, November 10, 2011 08:27:53 Jacob Carlborg wrote:
> >> What is the actual Phobos guideline in naming things that are keywords
> >> in D. I'm thinking about Method.del, shouldn't it be Method.delete_ or
> >> something similar, don't know what the guidelines say in this case.
> >> BTW,
> >> I would really like to have more official guidelines somewhere at the
> >> dpl page.
> > 
> > Thus far, we've taken the approach of tacking an underscore on the end
> > (so delete would be delete_), but we haven't made any kind of official
> > decision on it. However, if it's reasonable to use a different word
> > entirely, then that's generally better. It's stuff like
> > std.traits.FunctionAttribute which pretty much _has_ to match the
> > keyword where we've appended the underscore (e.g. pure_ and nothrow_).
> > 
> > - Jonathan M Davis
> 
> I agree, but this case it's not a completely different word, it's a
> shorting of the word.
> 
> I just like that there should be something more official when these
> things pop up.

Well, for better or worse, we don't have an official policy on it. In general, I 
think that the tact is to try and rename the item so that it doesn't pose a 
problem, but that's not always possible (hence FunctionAttribute.pure_). In 
this case, since it comes from something else, it looks like it really should 
be some version of delete. However, whereas FunctionAttribute pretty much 
_had_ to be as close to the keyword as possible since it represented the 
keyword, that's not the case here, and given how ugly it is to tack the _ on, 
del seems like a reasonable solution.

In any case, if we want something official, we'd have to discuss it, and we 
generally have a hard time coming to any kind of consensus on stuff like that. 
So, I don't generally try unless it seems particularly important.

- Jonathan M Davis


More information about the Digitalmars-d mailing list