On 4/16/21 2:25 PM, John Cowan wrote:
>     Good question.  In my implementation safe? starts off #f, and mutable?
>     starts off #t.  I'm pretty sure this was discussed somewhere in the
>     mail
>     list, but it doesn't seem to be in the document.  I'll add it to the
>     pull request.
>
> I think there are good arguments for safe or immutable or both as
> reasonable defaults, so I'd rather leave this explicitly
> implementation-specific.

Some of my thoughts:

1. We did discuss it on the mail list as starting with default-mutable?:
#t default-safe?: #f, so in some ways I consider this simply an error in
the SRFI document.

2. If the default is implementation dependent, then every program, no
matter how it wants default-mutable? and default-safe? to be set, is
going to have to start with calls to

(specialized-array-default-safe? <whatever>)
(specialized-array-default-mutable? <whatever>)

which is, in my opinion, unfortunate.

3.  When default-safe? is #t, then many, many array operations will be
significantly slower than when default-safe? is #f.  I think programmers
will be willing to pay this price when they truly need safe arrays, but
it would be unfortunate to slow down array operations significantly
because what some programmers might consider to be an obscure parameter
is set to be #t by implementation default.

4.  I know that people programming with arrays generally want things to
go fast, so I've been quite conscious about the speed of this library,
and I've put a fair amount of programming effort and somewhat grotty
code to speed it along.  Because of the dynamic nature of Scheme, where
array dimensions and bounds and storage classes may not be known at
compile time, this library already has a significant speed disadvantage
to a library written in C or C++ (although I suspect it will hold its
own against a pure Python library).  It was never my intention that an
implementation would have default-safe?: #t by default.

Open to thoughts of others.

Brad