The path to unity [You ALL ignored my post!]

[Andrei Alexandrescu]

Don wrote:
> Piotrek wrote:
>> Don pisze:
>>> Don wrote:
>>>> With the druntime project, we now have a run time which is shared 
>>>> between Tango and Phobos. This is a huge step forward, but it's 
>>>> still not much use without some common user code.
>>>>
>>>> The highest priorities which I see are, in order:
>>>> (1) the C standard library
>>>> tango.stdc = std.stdc
>>>> (2) low-level compiler-related modules
>>>> most of tango.core -- for the most part, this is already part of 
>>>> druntime.
>>>> (3) tango.math.Math + tango.math.IEEE  = std.math - tgamma().
>>>>
>>>> Can we get agreement on unification of these, at least?
>>>>
>>>> If we are able to reach agreement on this, I propose the next step 
>>>> would be to ensure that the contents of these files be made 
>>>> "identical" on Phobos2 and Tango. ("identical" meaning that when the 
>>>> Tango code is ported to D2, it will be identical to the Phobos2 
>>>> version, except for module name differences).
>>>
>>> Please read it again. I'm not asking the question "where do we put it?"
>>> Rather, to agree that it WILL eventually go SOMEWHERE. If we agree on 
>>> that, there are immediate implications. Those modules have some 
>>> functions which differ in naming (mostly in case). That's a 
>>> difference we can fix right now without the politics.
>>
>> I do agree it's a right direction to extract the common functionality 
>> and put it in a one place. But it's a question to the Phobos and Tango 
>> maintainers. After all, more time consuming efforts are needed.
> 
> No, it's a question to the community. I'm the primary maintainer of the 
> math modules in both libraries. The efforts are straightforwards and not 
> very time consuming. But I don't think I can break code just because I 
> have a personal desire for unity.
> 
>> Indeed , I don't think there's a person who don't want to see it happen.
> 
> Are people OK with some of their code breaking for the sake of unity?
> For the math stuff, that would mean name changes on minor functions such 
> as:
> isnormal() -> isNormal()
> 
> I need a mandate.

I hereby grant you that mandate. Feel free to mess with other names too, 
and let's exchange email when there's ambiguity.

The convention I'd like to use for templates is the following: if the 
template ultimately resolves in a type, e.g. BaseClassesTuple, start 
with uppercase. If it resolves in a compile-time constant or a function, 
e.g. hasAliasing, start with lowercase. By the way, what happened to 
std.traits and std.typecons? They are two of my faves and are growing as 
we speak.


Andrei