On Fri Sep 22, 2023 at 9:43 PM EDT, Bor Grošelj Simić wrote:
> >    `...` fills in zero or more values (as opposed to now, where it fills
> >    in one or more values). So [...] will work to initialize any array
> >    type, provided the member type has a definite default value.
>
> About the expression... form, under the new rules, `alloc([a(), b(), c()...],
> 2);` is supposed to be legal.  Does c() ever get called (and side-effects
> observed) in this case? I'm leaning towards no, but either way it's a bit
> confusing and unfortunate.

Hm, I would think that c() would be called, but its result would be
discarded. Maybe we should just keep the current behavior when using ...
with a value ([0...]), but have it fill in zero or more values when used
on its own?

On Sun Sep 24, 2023 at 9:05 PM EDT, Ember Sawady wrote:
> On Mon Sep 18, 2023 at 8:01 PM UTC, Sebastian wrote:
> > I think we should pass on this for now, and instead add @default and use
> > it here once that's implemented.
>
> i think that this is still an incremental improvement over the current
> state of strconv, and i'm ok with merging it even though we'll still
> need to make some other changes in the future (concretely, in addition
> to using @default, i'd like to support arbitrary bases as well).
> thoughts?

Pretty sure I said this on IRC and forgot to send an email, but yeah,
I'm fine with merging this as a temporary improvement.

On Sat Sep 23, 2023 at 10:37 AM EDT, Autumn! wrote:
> and then secondly it just seems unnecessary to forbid it. this patch 
> just makes it so that the restriction of "you can't instantiate a type 
> of undefined size" is only applied where necessary. in fact honestly 
> e.g. *[4]opaque could be allowed too, since it's not doing any harm as a 
> pointer, and that would remove the special case for just bounded array 
> pointers. i hadn't really considered that part when i sent this patch.

By this logic we should also allow struct fields to have undefined size,
so long as the struct is only used indirectly. But I don't think we
should do that.

> the nice thing about pointers is that they're just an address to the 
> start of an item, so you don't have to care about the size of the item, 

On Fri Sep 22, 2023 at 9:57 PM EDT, Bor Grošelj Simić wrote:
> It is guaranteed that dest < src, so we can safely use memcpy

-1. The fact that this happens to work with our current memcpy
implementation doesn't mean we should rely on it. docs/runtime.txt also
explicitly says "the memory areas shall not overlap", and I think this
is correct.

On Tue Sep 19, 2023 at 9:57 PM EDT, Bor Grošelj Simić wrote:
> My concern are things like these:
>
> fn f(a: *mut int, b: *int) void = {
> 	*a = *b + 2;
> 	assert(*a != *b);
> };
>
> fn caller() void = {
> 	let p = &0: *mut int;
> 	f(p, p);
> };
>
> The assertion in f will, counterintuitively, fail.

On Tue Sep 19, 2023 at 8:01 PM EDT, Bor Grošelj Simić wrote:
> On Tue Sep 19, 2023 at 11:50 PM CEST, Sebastian wrote:
> > On Tue Sep 19, 2023 at 3:51 PM EDT, Bor Grošelj Simić wrote:
> > > One thing that I find useful about *[*]opaque is the ability to get an
> > > opaque slice from it via regular unbounded array slicing:
> > >
> > > fn to_slice(data: *[*]opaque, ndata: size) = {
> > > 	return data[..ndata];
> > > };
> > >
> > > Equivalent code without this patch involves quite a bit of casting gymnastics.
> >
> > I'm still not convinced tbh. It's only one additional cast, which is
> > hardly "casting gymnastics".

On Thu Sep 14, 2023 at 9:51 PM EDT, Bor Grošelj Simić wrote:
> > - Taking the address of an immutable object of type `foo` yields an
> >   object of type `*foo` (pointer to immutable foo).
>
> Calling *T a 'pointer to immutable T' imo does not convey the actual
> meaning of the type expression. It's just this particular reference to the
> underlying object that is immutable we don't know anything about the actual
> object. Unfortunately, it's really easy to mess this up mentally when thinking
> about immutability and I think it would be great if we came up with a better
> way to talk about this.

Hm, I kinda see what you mean. I don't have any better ideas though,
since I think "(im)mutable pointer/slice" is even more misleading.

On Tue Sep 19, 2023 at 3:51 PM EDT, Bor Grošelj Simić wrote:
> One thing that I find useful about *[*]opaque is the ability to get an
> opaque slice from it via regular unbounded array slicing:
>
> fn to_slice(data: *[*]opaque, ndata: size) = {
> 	return data[..ndata];
> };
>
> Equivalent code without this patch involves quite a bit of casting gymnastics.

I'm still not convinced tbh. It's only one additional cast, which is
hardly "casting gymnastics".

I'd also be interested in seeing real-world examples of places where

On Tue Sep 19, 2023 at 5:36 PM EDT, Ember Sawady wrote:
> On Tue Sep 19, 2023 at 9:32 PM UTC, Bor Grošelj Simić wrote:
> > '\u  aa' was also considered valid before this patch (strto* functions allow
> > whitespace before the number), so the commit message, comments and tests should
> > also reflect that.
>
> does the spec allow this? if so, it should be disallowed there as well

No, it was a bug caused by strto* allowing the string to begin with
arbitrary whitespace. Similar to how strto* allows a sign at the
beginning.

On Tue Sep 19, 2023 at 5:32 PM EDT, Bor Grošelj Simić wrote:
> I don't particularly like this. The name \u implies it has something to do with
> unicode in all contexts. Perhaps a less weird alternative would be to have \u
> behave identically in str and rune and instead allow arbitrary \x sequences up
> to 4 bytes in lenght in runes, consistently with how \x allows one to disregard
> the rules in string literals.

\u does have to do with Unicode in all contexts though. It's just that
codepoints are stored differently in rune than in str.

> Right now `str` serves a double purpose, as a type for string literals and as a
> type for constant byte sequences of valid UTF-8. We already sometimes employ
> various hacks to get around the second intended purpose, but before this
> proposed change at least the two purposes had a non-empty intersection because