Getting the const-correctness of Object sorted once and for all

[Steven Schveighoffer]

On Mon, 14 May 2012 09:20:57 -0400, Dmitry Olshansky  
<dmitry.olsh at gmail.com> wrote:

> On 14.05.2012 16:37, Steven Schveighoffer wrote:

>> The one last puzzle to solve is sharing. File is this half-breed of
>> sharing, because it contains a FILE *, which is a shared type, but File
>> is not. Then it does some casting to get around the problems.
>
> And  it all went nice and well till I spotted FILE*. Boom.
> I mean I half assumed we are going to drop this crutch. Yep, too harsh.  
> So probably leave it as *one* of file backends that features  
> compatibility with C. Because IMHO using C-runtime this way is not  
> buying us anything else other then C compatibility and "welcome to the  
> world of unportable hacks where performance matters".

I think the compromise agreed upon will be reasonable.  A constructed File  
will start out as a FILE * entity until you want to do anything more  
complex than writeln or readf.  At that point, it switches over to D-based  
backend automatically.  I don't want to be trying to implement advanced  
buffer-based techniques using FILE *, and I also don't want to restrict  
phobos' types to only doing things that FILE * can do well.  At the same  
time, we have this legacy with std.stdio.File that we have to maintain  
(the comments on my preliminary library were near-unanimous -- it cannot  
break existing code).

Walter has a very very hard requirement that D's equivalent stdout stdin,  
and stderr all interoperate with the C calls that use the equivalent C  
structures.  In other words, it is a hard requirement that writeln and  
printf interoperate.

Really, printf is the *only* reason to have this backwards compatibility  
"feature", and I strongly wish we could get rid of it.

That being said, if you *want* to avoid FILE *, it will definitely be  
possible.

> We need a
>> better solution than this, but shared is so difficult to use, I think
>> I'm going to have to implement something similar. It has been stipulated
>> by Walter and Andrei that fixing this shared situation is a requirement
>> for any new replacement. I have some ideas, but I have to play around to
>> see if they actually work and make sense.
>>
> Probably it worths checking how std.stdio does it.

I have.  I don't know how well it applies to my library.  One thing about  
using FILE * is that you have full knowledge of the known universe of FILE  
*.  This means you can control internally the interactions between  
threads, making sure that you don't have an unshared pointer unless the  
thing is locked (and this is what std.stdio does).

The problem is when you create an *extendable* system like the one I'm  
doing.  At that point, you can lock when you cast away shared, but you  
have no idea whether a method call is going to squirrel away an unshared  
reference to itself somewhere, so that when you go back to shared (and  
unlock), there's a leaked thread-local reference somewhere.

It may have to require documentation-based restrictions (i.e.  
not-compiler-enforced).  I haven't put enough thought into the possible  
means to do this.  Ideas are welcome!

-Steve