1 files changed, 0 insertions, 51 deletions
diff --git a/doc/misc/design.rst b/doc/misc/design.rst
deleted file mode 100644
index 390049c..0000000
--- a/doc/misc/design.rst
+++ /dev/null
@@ -1,51 +0,0 @@
-================
-Design decisions
-================
-
-* Generally follow LuaJIT's ffi: http://luajit.org/ext_ffi.html
-
-* Be explicit: almost no automatic conversions.  Here is the set
-  of automatic conversions: the various C integer types are
-  automatically wrapped and unwrapped to regular applevel integers.  The
-  type ``char`` might correspond to single-character strings instead;
-  for integer correspondance you would use ``signed char`` or ``unsigned
-  char``.  We might also decide that ``const char *`` automatically maps
-  to strings; for cases where you don't want that, use ``char *``.
-
-* Integers are not automatically converted when passed as vararg
-  arguments.  You have to use explicitly ``ffi.new("int", 42)`` or
-  ``ffi.new("long", 42)`` to resolve the ambiguity.  Floats would be
-  fine (varargs in C can only accept ``double``, not ``float``), but
-  there is again ambiguity between characters and strings.  Even with
-  floats the result is a bit strange because passing a float works
-  but passing an integer not.  I would fix this once and for all by
-  saying that varargs must *always* be a cdata (from ``ffi.new()``).
-  The possibly acceptable exception would be None (for ``NULL``).
-
-* The internal class ``blob`` is used for raw-malloced data.  You only
-  get a class that has internally a ``blob`` instance (or maybe is a
-  subclass of ``blob``) by calling ``ffi.new(struct-or-array-type)``.
-  The other cases, namely the cases where the type is a pointer or a
-  primitive, don't need a blob because it's not possible to take their
-  raw address.
-
-* It would be possible to add a debug mode: when we cast ``struct foo``
-  to ``struct foo *`` or store it in some other struct, then we would
-  additionally record a weakref to the original ``struct foo`` blob.
-  If later we try to access the ``struct foo *`` but the weakref shows
-  that the blob was freed, we complain.  This is a difference with
-  ctypes, which in these cases would store a strong reference and
-  keep the blob alive.  "Explicit is better than implicit", so we ask
-  the user to keep a reference to the original blob alive as long as
-  it may be used (instead of doing the right things in 90% of the cases
-  but still crashing in the remaining 10%).
-
-* LuaJIT uses ``struct foo &`` for a number of things, like for ``p[0]``
-  if ``p`` is a ``struct foo *``.  I suppose it's not a bad idea at least
-  to have internally such types, even if you can't specify them through
-  pycparser.  Basically ``struct foo &`` is a type that doesn't own a
-  blob, whereas ``struct foo`` is the type that does.
-
-* LuaJIT uses ``int[?]`` which pycparser doesn't accept.  I propose
-  instead to use ``int[]`` for the same purpose (its use is anyway quite
-  close to the C standard's use of ``int[]``).