http://d.puremagic.com/issues/show_bug.cgi?id=9102
--- Comment #8 from Steven Schveighoffer <[email protected]> 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: -------
