redefining "put" and "OutputRange"

[Dmitry Olshansky]

30-Aug-2013 18:38, monarch_dodra пишет:
>>
>> Which is all good and well, but seeing this:
>>
>> static
>> if (is (R == T function(const( char)[]), T) || is (R == T
>> delegate(const( char)[]), T))
>>         enum isSink = 1;
>>     else static if (is (R == T function(const(wchar)[]), T) || is (R
>> == T delegate(const(wchar)[]), T))
>>         enum isSink = 2;
>>     else static if (is (R == T function(const(dchar)[]), T) || is (R
>> == T delegate(const(dchar)[]), T))
>>         enum isSink = 4;
>>     else
>>         enum isSink = 0;
>>
>> Doesn't inspire confidence - it's special casing on (w|d)char arrays,
>> again... Let's hopefully stop spreading this plague throughout
>> especially under banners of generality.
>
> It's a special case for sinks, yes. I'm not a fan of this, but I think
> it is the *single* cases we can trust. (More on this bellow)

No thanks. Full functionality outweighs trusted but crippled.

>>> The real reason I'm starting this thread is I believe the current way
>>> "put" leads to a *MASSIVE*, *HORRIFYING* issue. I dare not say it:
>>> Escaping references to local stack variables (!!!).
>>
>> It is a dangerous primitive. It's not a good idea to wrap everything
>> with safe bags and specialize a single case - arrays and not even
>> appender of (w|d)char[].
>>
>> Instead it's once again a case where primitive needs better high-level
>> contract inexpressible in simply terms such as @safe-ty provides.
>>
>> The rule is: OutputRange must not hold references to any slices given.
>> And is trivially true for many of current ranges.
>
> OutputRange really just means that put(r, e) resolves one way or
> another. And it also fundamentally depends on what you consider the
> "element type".
>

You put too much faith in the source code alone. Not every assumption is 
written in the source (while it should be probably).

> For example, int[][] is an output range for the element int[]. It makes
> a copy of said element (int[]), but it certainly *won't* copy the
> contents of that slice.

The main reason for output range is to absorb data one by one or in 
chunks (= slices). In that sense int[][] is a bad output range.

I do not really care for formalism that defines what is an element type 
here.

>>> I'd like to make a proposition: "put" needs to be changed to *not*
>>> accept putting an E into something that accepts E[]. There is simply *no
>>> way* to do this safely, and without allocating (both of which, IMO, are
>>> non-negotiable).
>>
>> Just relax and step back for a moment. The bug in question is
>> painfully easy to blowup so chances for it being HORRIBLE are quite
>> low (it's a loud bug). Safety is cool but I expect that output ranges
>> are designed with idea of copying something somewhere or absorbing or
>> accumulating.
>
> I'd agree, if output ranges were actually "designed".

And they were.

> Right now, the
> basic definition is that an "OutputRange" collects "Elements". "put"
> extends the supported "Elements".
>
> The truth is that format sinks "(const(char)[]){}" is the *only*
> OutputRange that collects "Elements", but whose' signture is one that
> accepts a slice. This "flaws" the slice/element notion.

Because it was lacking in performance the most.

> If format sinks were defined as "(char){}" to begin with, then
> everything would work fine (and *does*),

And would slowly crawling into oblivion, that said std.stdio is slow 
even w/o put-ing char by char (+char is not complete thus would require 
buffering on the other side of fence).

but this is not the case today,
> and that is the *only* reason I made an exception for them.

Chances are you missed ubyte/ubyte[] of std.digest.

>>> For objects that define put/opCall, then it is not very complicated to
>>> have two different signatures for "put(E[])"/"opCall(E[])" *and*
>>> "put(E)"/"opCall(E)". This makes it explicit what is and isn't accepted.
>>
>> And that will subtly break some genuinely fine code...
>
> It would "explicitly" break code

... and that is bad ...

> that may (or may *not*) be fine.

The point is if it wasn't fine then it wouldn't survive a day in the wilds.

>>> Lucky enough, the problem never existed with input ranges: "int[][]"
>>> never accepted "int", so there is no problem there.
>>
>> This is it - a confusion between output range of int[]'s accepting
>> them one by one and of int and accepting them in chunks.
>
> I think the problem is "put" overstepping its boundaries. If
> "r.put(someSlice)" compiles, "put" has no reason to think that R
> actually owns the elements in the slice.

It should and this is where we differ I guess. I can't think of a useful 
output range that stores away aliases to slices it takes.

-- 
Dmitry Olshansky