Is D open for different code conventions?

[Bill Baxter]

Sean Kelly wrote:
> Bill Baxter wrote:
>> Anonymous wrote:
>>>
>>>> I just want to ask D's community: it is appropriate if some projects 
>>>> will use different code convention?
>>>
>>> If it is your project I don't see anybody forcing you to do anything.
>>> Personally I don't even know which convention I'm supposed to use.
>>> I wouldn't even be able to name the convention I use myself :D
>>
>> toString, opApply, opCall, opCatAssign....
>>
>> Some uses of camel case are dictated by the spec currently.
>> And Phobos and Tango both use camelCase for methods.
>>
>> I also used to like camelCase and groaned whenever I saw a different 
>> convention, and *especially* at GTK code.  But I also came to the 
>> realization at some point that underscore_separated really is easier 
>> to read close to the deadline, late at night, with too little sleep.
> 
> It's a bit of a religious issue, but I've decided I like CamelCase for 
> type names because it helps visually distinguish them from variable 
> names, etc.  It's also a tiny bit more compact.  For what it's worth, I 
> was an underscore_fellow until I started using D.

I was actually only talking about method names. For class names I'm all 
for CapitalizedWords.  But as you say, it is just a religious thing, 
which is why the OP suggests making it a preference.  But I just don't 
see how that would work.  So to the OP:  what did you have in mind?  The 
only think I could imagine would be to make the compiler magically 
mangle a bunch of related names to the same symbol.  Like making all of

to_string
ToString
To_String
etc...

mangle to the same thing as

toString

but that doesn't really cover the std libary.  And I think it would be a 
really bad idea to globally treat some_function as synonymous with 
SomeFunction.  Reminds me of case-insensitive languages where 
SomeVArIaBle is the same thing as someVariable.

--bb