On Tuesday, 1 May 2018 at 12:03:15 UTC, ag0aep6g wrote:
On 05/01/2018 01:44 PM, Per Nordlöw wrote:
In which cases (if any) is it possible to make a
delegate-style implementation of toString such as
void toString(scope void delegate(const(char)[]) sink)
const @trusted pure
{
// sink("...");
// sink.formattedWrite!"..."(...);
}
pure?
You have to mark `sink` as pure, too:
void toString(scope void delegate (const(char)[]) pure sink)
const @trusted pure
Then the toString method itself works, but it may not be
callable by other code that wants to use an impure sink.
For example, `format` works, but `writeln` doesn't:
----
struct S
{
void toString(scope void delegate(const(char)[]) pure sink)
const @trusted pure
{
import std.format: formattedWrite;
sink("...");
sink.formattedWrite!"%s"(" ...");
}
}
void main()
{
import std.format: format;
import std.stdio: writeln;
writeln(format("%s", S())); /* Ok. Prints "... ...". */
writeln(S()); /* Nope. writeln would like to use an impure
sink. */
}
----
By the way, you shouldn't mark toString as @trusted when `sink`
is @system.
I had similar issue for opApply.
The generalized problem is, the attributes (pure, nothrow, @safe,
@nogc) are too strong on functionals (i.e. functions taking
function/delegate arguments). We could (and IMO should) weaken
the attributes to mean: the same as always, *assuming all
function/delegate arguments have it*.
Concrete example, say your `toString(scope void
delegate(const(char)[]))` is conceptually pure, i.e. if `sink` is
a pure function (by static typing), `toString(sink)` acts pure,
and for impure `sink`, `toString(sink)` possibly impure. So
purity of the functional `toString` depends on the purity of its
arguments; that is very natural as most functionals call their
parameters.
The current state makes attributes virtually useless for
functionals. Often, toString can be templetized without drawback
(except virtual functions), but opApply cannot. opApply must not
be a template to enable type deduction for the variable.[1]
Making attributes act structurally has almost no consequences in
terms of breakage; just more functions can be
pure/nothrow/@nogc/@safe. It would make functionals
impure/unsafe/..
that do not call their argument. The question is, in which
contexts are they used and is it an issue -- is it a greater
issue than this.
Complete example what the change would do:
Say you have
void toString(scope void delegate(const(char)[]) sink) pure {
sink("Example"); }
toString is a pure functional, so calling it is pure iff the
argument itself is. The compiler statically knows if the argument
is pure and can infer the purity of the expression.
[1]
https://dlang.org/spec/statement.html#foreach_over_struct_and_classes
(We could define very general special cases where type deduction
can be archived, e.g. opApply(DG : int delegate(Args))(DG).)
