Date: Sat, 04 Jul 2020 14:48:43 -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: <71NYCQ.87F07ED5PFH2@gmail.com>
In-Reply-To: 
	<CAAhSavZCFk0HisXMuG_v6vSUhF0J+75u91=eDXbAwADuVuYjnA@mail.gmail.com>
References: 
	<CAAhSavZq+TFWtwg1+V_XC5W9cED8SFyzeqf1Na1LnzsePL5_XA@mail.gmail.com>
	<INGYCQ.3W7RABKQ2ZWQ@gmail.com>
	<CAAhSavZCFk0HisXMuG_v6vSUhF0J+75u91=eDXbAwADuVuYjnA@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=windows-1251; format=flowed
Content-Transfer-Encoding: quoted-printable



On Sat, Jul 4, 2020 at 12:34, Shawn Walker <binarycrusader@gmail.com>=20
wrote:
> I guess I=92m spoiled by the rust compiler=92s reasoning about=20
> lifetimes.  If I try to use =91x=92 once the binding has expired it=20
> won=92t let me and tells me why.  Here it seems like Scopes should=20
> know the lifetime of the storage and then could prevent or warn about=20
> further use.

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 on=20
the other hand are built on top of those but with security added in. In=20
this particular example, it's usually recommended to use the Array=20
(from Array.sc) data-type instead, which is both bounds and lifetime=20
checked. Similarly alloca, malloc shouldn't be used directly (ie. use=20
`local` with a unique type, or a Box<T> for heap).
The bottom line is that in normal usage you will always never deal with=20
pointers (or use most LLVM intrinsic functions), except when dealing=20
with external C APIs (in which case you can immediately wrap in a=20
checked type) or when implementing new language features.
...This is not to say this couldn't change or be added in, but it's my=20
understanding that the behaviour is by design.

Westerbly (radgeRayden) Snaydley.