[Issue 9102] OutputRange should be ref parameter

[d-bugmail at puremagic.com]

http://d.puremagic.com/issues/show_bug.cgi?id=9102



--- Comment #8 from Steven Schveighoffer <schveiguy at yahoo.com> 2013-02-25 11:13:32 PST ---
(In reply to comment #7)
> You're probably right with most of that. I'd still like to keep the name as
> "put" to avoid API breakage and for consistency with the OOP API. Also
> introducing a special reference type complicates the API, if we keep "put" the
> pointer type can be used as that reference type.

Yeah, this is true.  It would be inventing an external type when a reference
does just fine.  Hopefully the compiler could inline this to be equivalent
code.

Also, functions which *do* take a ref are short-changed of being able use this
as a valid output range.  There's not a very good answer to this.

> Disabling the postblit on CRC32 is IMHO a quite nice solution. It should be
> done anyway as in 99% if a CRC32 is passed to another function by value it's a
> bug and a @disabled postblit would prevent this nicely. It should therefore
> also prevent calling copy with a CRC32.

Well, the problem with this is, you disable legitimate copies.  For example, if
I wanted to save the current state because the next few bytes passed in may not
be valid.

I don't know if this is a valid concern, but it seems like that is solving the
problem by curing the symptoms.

I don't really have a horse in this race as I don't use the given code, just
offering my opinion.

> The only place where @disabling postblit should produce a different result than
> renaming "put" should be if a function takes an OutputRange by ref, such as the
> standalone put function. But I don't think that's a problem.

I don't think it would be different.  A ref of a ref is still a ref ;)

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------