Changed my mind about midend_is_solved: I've now reprototyped it as

midend_status(), and given it three return codes for win, (permanent)
loss and game-still-in-play. Depending on what the front end wants to
use it for, it may find any or all of these three states worth
distinguishing from each other.

(I suppose a further enhancement might be to add _non_-permanent loss
as a fourth distinct status, to describe situations in which you can't
play further without pressing Undo but doing so is not completely
pointless. That might reasonably include dead-end situations in Same
Game and Pegs, and blown-self-up situations in Mines and Inertia.
However, I haven't done this at present.)

[originally from svn r9179]

1 files changed, 5 insertions, 3 deletions

diff --git a/midend.c b/midend.c
index 0c8b3c0..8f4e4c9 100644
--- a/midend.c
+++ b/midend.c
@@ -1336,7 +1336,7 @@ char *midend_solve(midend *me)
     return NULL;
 }
 
-int midend_is_solved(midend *me)
+int midend_status(midend *me)
 {
     /*
      * We should probably never be called when the state stack has no
@@ -1347,8 +1347,10 @@ int midend_is_solved(midend *me)
      * practically, a user whose midend has been left in that state
      * probably _does_ want the 'new game' option to be prominent.
      */
-    return (me->statepos == 0 ||
-            me->ourgame->is_solved(me->states[me->statepos-1].state));
+    if (me->statepos == 0)
+        return +1;
+
+    return me->ourgame->status(me->states[me->statepos-1].state);
 }
 
 char *midend_rewrite_statusbar(midend *me, char *text)