D1 -> D2

[Steven Schveighoffer]

On Thu, 18 Nov 2010 14:50:06 -0500, Walter Bright  
<newshound2 at digitalmars.com> wrote:

> Steven Schveighoffer wrote:
>> On Thu, 18 Nov 2010 14:19:12 -0500, Walter Bright  
>> <newshound2 at digitalmars.com> wrote:
>>
>>> Steven Schveighoffer wrote:
>>>> My recommendation -- when you are ready, switch wholly to D2.  Don't  
>>>> bother with compatibility, it's just not possible.
>>>
>>>  From what you wrote, it appears that most of the difficulties were in  
>>> dealing with strings. Might I suggest:
>>>
>>> 1. Replace all occurrences of char[] with string.
>>>
>>> 2. Compile to find every place that mutable strings are used.
>>>
>>> 3. Refactor the code to clearly encapsulate where mutable strings are  
>>> created and manipulated, and as the last step, cast them to string.
>>  But string is not always what is desired.  It depends on the library.
>
> Right.
>
>
>> Tango uses mutable arrays everywhere because it prefers not to use the  
>> heap as much as possible.  For example, something might take a char[]  
>> buffer, and a function may pass in a stack-allocated array for the  
>> buffer.  Changing this to string is useless.
>
> That's where refactoring comes in. I haven't looked at the Tango code,  
> but there's a big difference between "using mutable arrays everywhere"  
> and actually needing to mutate them. Only the latter needs to be char[],  
> and the boundaries between the two are bridged with a .idup or a  
> cast(string).
>
> If Tango is relying on string literals to be char[], i.e. be mutable,  
> this is a serious bug and will cause seg faults. So, this issue must  
> have already been dealt with in Tango, and codifying string literal  
> types as "string" rather than "char[]" should not negatively impact it.
>
> And lastly, if there are APIs in tango that accept char[] and leave the  
> caller perplexed about whether the API will mutate the string or not,  
> that is something that using string for the non-mutating ones nicely  
> resolves.

Yes, Tango obviously works on Linux, so it does not modify string literals  
(as much as it can, you can't really prevent a user from passing in a  
string literal to sort for example).  However, the char[] type accepts  
both string literals and mutable buffers.  In some cases, those strings  
are stored for later use, in some they are modified (obviously one has to  
avoid passing in literals for that), and in some they are just used  
temporarily.  The differences require you to change the argument type to  
string or const(char)[], and possibly to overload the function.  The rules  
I outlined were what I was going by in order to port D1 code.

It's not impossible, but Tango's #1 rule is minimize heap allocations.  By  
peppering idup everywhere, you have created a conflict with the main  
goal.  Refactoring in these cases isn't quite as simple as you say, and it  
certainly won't be backwards compatible.

In general, I tried to make Tango for D2 as const aware as possible (it's  
a standard lib, and shouldn't require people to ignore const), and found  
all sorts of issues with it (const).  The main one that made me quit was  
the problem that inout is supposed to solve.

For someone just trying to "get something working" on D2 from a D1 base,  
the biggest issue is to deal with string literals since you are forced to  
deal with const at that point.  Other than that, you can usually safely  
leave everything non-const-ified.  That's all I was saying.

And I don't think it's worth the effort to try and achieve backwards  
compatibility with D1.

-Steve