i'm a human i think
From Sebastian to ~sircmpwn/hare-rfc
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?
From Sebastian to ~sircmpwn/hare-dev
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.
From Sebastian to ~sircmpwn/hare-dev
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,
From Sebastian to ~sircmpwn/hare-dev
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.
From Sebastian to ~sircmpwn/hare-rfc
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.
From Sebastian to ~sircmpwn/hare-dev
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".
From Sebastian to ~sircmpwn/hare-rfc
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.
From Sebastian to ~sircmpwn/hare-dev
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
From Sebastian to ~sircmpwn/hare-dev
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.
From Sebastian to ~sircmpwn/hare-dev
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