Date: Sat, 04 Jul 2020 15:05:46 -0500
From: Westerbly Snaydley <westerbly@gmail.com>
Subject: Re: unexpected behavior with arrays?
To: Shawn Walker <binarycrusader@gmail.com>
Cc: ~duangle/scopes@lists.sr.ht
Message-Id: <MTNYCQ.RQPHY6BNHH5M3@gmail.com>
In-Reply-To: <71NYCQ.87F07ED5PFH2@gmail.com>
References: 
	<CAAhSavZq+TFWtwg1+V_XC5W9cED8SFyzeqf1Na1LnzsePL5_XA@mail.gmail.com>
	<INGYCQ.3W7RABKQ2ZWQ@gmail.com>
	<CAAhSavZCFk0HisXMuG_v6vSUhF0J+75u91=eDXbAwADuVuYjnA@mail.gmail.com>
	<71NYCQ.87F07ED5PFH2@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: quoted-printable



On Sat, Jul 4, 2020 at 14:48, Westerbly Snaydley <westerbly@gmail.com>=20
wrote:
>=20
>=20
> On Sat, Jul 4, 2020 at 12:34, Shawn Walker <binarycrusader@gmail.com>=20
> wrote:
>> I guess I=E2=80=99m spoiled by the rust compiler=E2=80=99s reasoning abo=
ut=20
>> =7Flifetimes.  If I try to use =E2=80=98x=E2=80=99 once the binding has =
expired it=20
>> =7Fwon=E2=80=99t let me and tells me why.  Here it seems like Scopes sho=
uld=20
>> =7Fknow the lifetime of the storage and then could prevent or warn=20
>> about =7Ffurther use.
>=20
> Scopes' borrow checker is opt-in, and the core is designed such that=20
> lower level constructs / APIs are not checked. The higher level APIs=20
> on the other hand are built on top of those but with security added=20
> in. In this particular example, it's usually recommended to use the=20
> Array (from Array.sc) data-type instead, which is both bounds and=20
> lifetime checked. Similarly alloca, malloc shouldn't be used directly=20
> (ie. use `local` with a unique type, or a Box<T> for heap).
> The bottom line is that in normal usage you will always never deal=20
> with pointers (or use most LLVM intrinsic functions), except when=20
> dealing with external C APIs (in which case you can immediately wrap=20
> in a checked type) or when implementing new language features.
> ...This is not to say this couldn't change or be added in, but it's=20
> my understanding that the behaviour is by design.
>=20
> Westerbly (radgeRayden) Snaydley.

Slight correction: in this particular case it's fine to use plain=20
arrays, I meant it more that it's not recommended to use alloca, and if=20
you avoided that there would be no problem. The unique Array type=20
serves as the complementary solution for when you actually would use=20
dynamically allocated memory (like std::vector, I suppose).
Also, I think you need to hit reply all when responding to mailing list=20
emails, as your last one didn't show in the archives.

Westerbly (radgeRayden) Snaydley.