ChanServ changed the topic of #zig to: zig programming language | ziglang.org | be excellent to each other | channel logs: https://irclog.whitequark.org/zig/
bheads has quit [Quit: Leaving]
<rhencke>
Hi, all. I see references to 'zig fmt' on the issue tracker, but I can't figure out how to invoke it. I'm building zig from the master branch. Does anyone know?
<MajorLag1>
andrewrk what's the recommend way to take a [*] to an array?
rhencke has quit [Ping timeout: 260 seconds]
davr0s has joined #zig
<GitHub11>
[zig] jayschwa opened pull request #1113: Make `zig version` compliant with SemVer (master...semver-build-metadata) https://git.io/vhPoO
davr0s has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
JinShil has joined #zig
davr0s has joined #zig
davr0s has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
davr0s has joined #zig
<MajorLag1>
Well, catching up with pointer reform wasn't so bad. Only took 2 hours to correct all my code. Casting structs to byte slices is much more verbose than it used to be though. And you can't `@ptrCast` to `[*]const c_void` at all.
davr0s has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
<MajorLag1>
spoke too soon, something broke in my ini parser. Possibly because something broke in BufMap again.
xtreak has joined #zig
xtreak has quit [Remote host closed the connection]
very-mediocre has joined #zig
jjido has joined #zig
alexnask has joined #zig
very-mediocre has quit [Ping timeout: 260 seconds]
jjido has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
xtreak has joined #zig
jcan has joined #zig
<pianofingers>
andrewrk, Have you seen Herb's c++ proposal on zero overhead deterministic exceptions? People are really liking it so it's good to be aware of it, C++ is going to be in a huge flux because of them once they finally arrive. They are more efficient than error codes because they share the return channel while a CPU flag (like the carry) is used to indicate whether an error occured. They want to coordinate this ABI extension with C, so in C you would have
<pianofingers>
_Either(int, std_error).
<pianofingers>
Also they seem to be deciding to that throwing exceptions should be done significantly less often than today. No exceptions on precondition violations for example, and they're even thinking about handling OOM differently..not handling them by default. So people would opt in to handling those in some way by calling a different function like try_push_back. I'm not sure what they'll do with constructors then..
<alexnask>
@pianofingers I took a look at that, it seems pretty interesting
<alexnask>
TBH I don't understand why exceptions weren't like that in C++ in the first place
<alexnask>
But then again I wasn't around when C++ was being designed :P
very-mediocre has joined #zig
<very-mediocre>
hindsight is 20/20
jjido has joined #zig
<pianofingers>
The way they'll integrate them into the current language is "noexcept" = no exceptions, "" = dynamic exceptions, "throws" = static exceptions (no dynamic exceptions).
<alexnask>
This is not gonna confuse beginners at all /s
<very-mediocre>
They need to make a clean break and deprecate more things
<very-mediocre>
There's wayyyy too much baggage in C++
jjido has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<alexnask>
Yes, it could actually become pretty good, but they will never get rid of features less obscure than trigraphs :p
very-mediocre has quit [Ping timeout: 260 seconds]
very-mediocre has joined #zig
<very-mediocre>
I really only ever used it as C with classes and generics
<very-mediocre>
beyond that things get messy
<alexnask>
I like me some templates unsuprisingly :P
<alexnask>
RAII is a great idea but yes you need to chose a subset of the language carefully
davr0s has joined #zig
davr0s has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
<pianofingers>
There's quiet a lot of game programmer types rebelling against 'OOP' right now. As far as I can see, the main problem is that people private everything by default and therefore treat any type T as a hierarchy of types that need to communicate instead of just a flat table of data. This I think is really the only problem and it's fitting that Zig doesn't have private. RAII on the other hand is great, but C++ messes it up with non destructive moves.
<pianofingers>
Rust and Zig show better alternatives, with Zig possibly having "var x = clean foo()" or "var x = noclean foo()" <- that's a proposal I noticed that I really like.
very-mediocre has quit [Ping timeout: 260 seconds]
Triplefox[m] has joined #zig
<alexnask>
@andrewrk Should @elemCast work for Fn and Promise types?
<alexnask>
I guess promise types should work but I dont see how Fn types would
very-mediocre has joined #zig
<very-mediocre>
I don't mind class hierarchies of actual things
<very-mediocre>
what I hate is those very abstract Javaesque classes
<very-mediocre>
overuse of design patterns is infuriating
<very-mediocre>
You end up with interfaces like IGameFactoryFactory
<very-mediocre>
yes that's a factory of a factory
<very-mediocre>
and you have to pass it something that implements IGameModuleDBAdapter
<Triplefox[m]>
i am a fan of shallow hierarchies...ime the applications i write usually manifest most simply as an intricate top level
<Triplefox[m]>
deeper code with reusable modules, those are the things i can't get until much later when the code matures...i see it as like harvesting
<very-mediocre>
I think erring on the side of pure functions fixes a lot of these things
<very-mediocre>
it helps you identify if a function or structure can be a module on its own
<very-mediocre>
The problem with OOP is nobody can decide what should be its own module/abstraction
<Triplefox[m]>
since i'm also working on games it serves me really well...when you have a real-time event loop the difficulty is that aiming for pure functions is the exceptional case
<very-mediocre>
It's more of a design thing I guess
<very-mediocre>
I try to decide if the thing I am trying to abstract is actually "pure" in nature
<very-mediocre>
if so, it's a separate module
<very-mediocre>
(could be a class, depends on the language)
<very-mediocre>
I might still implement it with some side effects
<very-mediocre>
if needed.
<very-mediocre>
Conceptual purity is just a really powerful hint
<Triplefox[m]>
semi-related, i had a bad experience with how "pure" worked in D - transcendental math sets hardware state, so doing some trigonometry made my function non-pure...turned me off to how they did there
<alexnask>
@TripleFox I think you can mark a function as pure when it actually mutates stuff in D right?
quc has joined #zig
<alexnask>
So called "weak purity"
<Triplefox[m]>
there is some workaround yes...but it feels like it's not the right way to do it(not that i have a better idea)
<very-mediocre>
I'm not a compiler guy but I still don't understand why a compiler can't mark functions as impure
<very-mediocre>
and then taint any function that calls an impure function, making it impure too
<Triplefox[m]>
i guess in my mind, if i want weak guarantees about semantics for a specific application, metaprogramming tends to do better at that
<Triplefox[m]>
the time-honored tradition of the macroassembler
very-mediocre has quit [Ping timeout: 260 seconds]
very-mediocre_ has joined #zig
<very-mediocre_>
ugh flaky internet keeps dropping
<alexnask>
How is Ds nogc these days?
<alexnask>
Haven't checked it out in ages, I remember the standard library used it in many places it shouldnt though
<very-mediocre_>
My last message got eaten. tl;dr: andrewrk's idea was: when passing a const pointer as a function param, it would be guaranteed that item would not be modified by any side effects
<very-mediocre_>
const pointer to a struct**
<very-mediocre_>
so you don't want to call any function that has side effects on that struct
<very-mediocre_>
the compiler should complain if you try
<very-mediocre_>
in his example `innocent_function` mutates the parameter
<Triplefox[m]>
nogc is a work in progress but I understand there's a commitment being made there and a lot of interest in using D in its "betterC" mode. i don't work with D frequently enough to say more.
<Triplefox[m]>
i'm more interested in zig as the "better c" of course :)
xtreak has quit [Remote host closed the connection]
<pianofingers>
If you were to ask the D people "How do I write an application that uses custom memory allocators and just doesn't use the GC" they'd look at you like you were crazy. That's just the truth. In their eyes you always use the GC except in a few places where you really can't. Super dumb, super sad. They're competing with C#, not C++, and they still can't see it.
<alexnask>
There is Allocator support in their std experimental library I think
<very-mediocre_>
In my experience they tell you the GC runs on allocation, so just preallocate
<alexnask>
But yes most people probably just use the GC
<pianofingers>
Triplefox[m]: I've heard that transitive const isn't all that fun to use
<pianofingers>
whoops you guys were talking about pure functions, not immutable :)
<Triplefox[m]>
truth be told, the things that I use D for are kind of "scripting" tasks that I would prefer a native binary for
<pianofingers>
very-mediocre_: Which means "we're not like you, you're a weirdo, here's how you can do something that nobody else does". It's a lonely rode, no one should take it.
<very-mediocre_>
Part of it was using pure functions to detect mutability violations
<very-mediocre_>
Yeah they are a bit cult-ish
<very-mediocre_>
The people who make D are decent imho
<very-mediocre_>
the community is a bit fanatical though
<very-mediocre_>
One thing I found weird though is Walter Bright and Andrei Alexandrescu have been publicly sighing about the GC for a few years now
<very-mediocre_>
Makes the whole nogc attempt feel low energy
<very-mediocre_>
that's what scared me away from D
<pianofingers>
agreed
<very-mediocre_>
I still can't tell if they're serious about nogc
<very-mediocre_>
Lately they've published blog articles that recommend living with it :/
<very-mediocre_>
pianofingers: "They're competing with C#, not C++, and they still can't see it."
<very-mediocre_>
this
<very-mediocre_>
I don't know why I'd roll a web server using vibe.d
<very-mediocre_>
It's barely maintained, anyone rational would just use C#
<very-mediocre_>
and the same goes across the board
<very-mediocre_>
for any use case.
<pianofingers>
I mean I don't know, it's the one thing that looks pretty cool and performant?
<very-mediocre_>
I was considering it for a web backend but the low energy scared me off
<very-mediocre_>
Performance was a bit hard to understand, I read some discussions where people had poor results
<very-mediocre_>
and there were some not-obvious cavetas
<very-mediocre_>
caveats
<very-mediocre_>
In the end it's just async
<very-mediocre_>
You get that out of the box in C# or node.js
<Triplefox[m]>
one thing that keeps me coming back to D is that the basic compiler tech seems good. i really trust walter's work there. but maybe the language needs a reset
<very-mediocre_>
This *is* D 2.0 though!
<very-mediocre_>
this is the reset
alexnask has quit [Ping timeout: 264 seconds]
<pianofingers>
Anyways, I wasn't around back when D was created. Back then the GC probably seemed like the correct choice. And yes Walter has certainly done a lot of cool and impressive work and made a really fast compiler as I understand it.
very-mediocre has joined #zig
very-mediocre_ has quit [Ping timeout: 260 seconds]
xtreak has joined #zig
very-mediocre has quit [Ping timeout: 260 seconds]
JinShil has quit [Quit: Leaving]
ManDeJan has joined #zig
enoent has joined #zig
alexnask has joined #zig
<GitHub4>
[zig] alexnask opened pull request #1116: WIP: Remove @ptrCast and replace it with @elemCast (master...elemCast) https://git.io/vhXTR
<alexnask>
The issue with this PR is that we lose the ability to cast Fn pointers through @ptrCast
<alexnask>
But I'll see how I can workaround this while fixing tests and the standard library
Hejsil has joined #zig
<Hejsil>
alexnask, not to be a downer, but maybe it would be best to wait for the proposal to be accepted before puping to much work into it :)
<alexnask>
Oh woops I just assumed it would be accepted :p
<Hejsil>
Not being able to ptr to a fn ptr, seems like a big flaw
<alexnask>
Well I've started now, I just need to modify some zig code so I may as well do it and close it if it isnta ccepted :P
<alexnask>
Can't they be explicitely casted?
rcdchen has joined #zig
<alexnask>
If they can, I don't see the difference tbh, you wouldn't need @ptrCast in the first place
<alexnask>
I'll check it out
<rcdchen>
run the test error: $ zig test test.zig error: invalid token:']' assert(@typeOf(null_terminated_bytes) == [*]const u8); ^
davr0s has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
<rcdchen>
I think it would be more convenient to use the gitter to communicate than freenode. Please think about it. Maybe I'm used to the gitter.
noonien has joined #zig
<bheads__>
Some of the issues in D come from the fact that the language devs dont use it for more then trivial programs. Even Walter doesn't bother with the GC, he just disables it and leaks memory. The DMD compiler leaks memory all day long, so if you have a non trivial program you can run out of memory compiling it! I had to rewrite a vibe.d site cause of that issue.
<bheads__>
They added nogc, but only like 20% of the stdlib supports it, and you cant use a few of the language features. Like how can you support nogc when the language uses the gc?!? So they added betterc, guess what its just a worst language then zig cause it wasn't a thought out language, just a subset of D :) And of course there is not stdlib, so you just have to use libc
rcdchen has quit [Ping timeout: 260 seconds]
davr0s has joined #zig
<alexnask>
Actually even worse, @ptrCast is the only way to convert *T to [*]T it seems
<Hejsil>
Ye, that's pretty bad too
<Hejsil>
I think implicit cast from * -> [*] is being considered
bodie__ has joined #zig
<bodie__>
yay zig-fmt in vim :D
<bodie__>
I'm getting "Unable to find zig lib directory" after building zig from master and linking it into my PATH using a symlink
<bodie__>
macOS 10.13.5
<bodie__>
er, when I try to run "zig build-exe main.zig" on the hello-world example
<bodie__>
It works if I refer to it using the real full path in the build directory
davr0s has quit [Ping timeout: 245 seconds]
<bodie__>
I assume this means that the zig binary looks for its libraries in its local path?
<bodie__>
maybe a relative path such as "../lib"?
<Hejsil>
did you make install?
ManDeJan has quit [Ping timeout: 240 seconds]
<bodie__>
I used ninja but yes
<bodie__>
it looks like it's installing libs to the local path of the build
<bodie__>
perhaps there's a CMake variable that needs to be set?
<Hejsil>
Naah, it should just work
<Hejsil>
you should have: <build_folder>/zig and <build_folder>/lib/std
<bodie__>
Well it's $BUILD/lib/zig/std but yes
<Hejsil>
Aah right
<bodie__>
I created a symlink in my user's PATH to $BUILD/bin/zig
<Hejsil>
Idk if bin/zig will work
<bodie__>
that works on ubuntu, because when you `ninja install`, it installs the libs to a global path
<bodie__>
on macOS it appears to install them to a build-local path
<Hejsil>
On my linux machine, it installs libs locally
<bodie__>
hmm
<Hejsil>
and I symlink $BUILD/zig and not $BUILD/bin/zig
<bodie__>
well I'm not at my linux box so I could be wrong about that, but that's what I recall
<bodie__>
hmm, ok. I'll try that
<Hejsil>
I think it did at some point
<Hejsil>
But the default was changed to local
<bodie__>
I changed the symlink to $BUILD/zig and the problem remains
<Hejsil>
Hmm
* bodie__
does a bit of a think
<bodie__>
any other mac users?
<bodie__>
I could've sworn I had this working on my personal laptop
<bodie__>
nope, same issue
<bodie__>
I just built it without ever checking that it worked since I assumed it was working after checking on my linux box
<bodie__>
the homebrew (0.2.0) macOS installation of zig works
<bodie__>
guess I'll open an issue
<bodie__>
When I build from 0.2.0, the install path is /usr/local/lib.
<Hejsil>
Ye, that changed after 2.0
xtreak has quit [Remote host closed the connection]
<bheads__>
How do you test if some type A is an array of type T? I think I am okay testing []T []const T, but how to detect static array types? [N]T
<MajorLag1>
`@typeId(A) == builtin.TypeId.Array and A.Child == T`
<bheads__>
Looks like it only works with static arrays I am seeing some odd behavoir...
<MajorLag1>
[N]T is a static array
<bheads__>
right, I am working on code that should work with any array of T
<MajorLag1>
I don't understand, you want to also test for [*]T?
<bheads__>
no, not the unknown length
<bheads__>
but a *const []T should also wok
<alexnask>
Right so you want indexables basically
<MajorLag1>
Then you'll have to see if it is a pointer first
<alexnask>
Slices + arrays
<bheads__>
yeah I got that part
<bheads__>
its just static array were throwing me off
<alexnask>
I would unwrap the type, (have an F that takes *const T and returns T) then use TypeInfo to check if this is an array or slice.
<bheads__>
cant test the type in a switch
<bheads__>
assert(@typeId([]i32) == TypeId.Array); // thrown off on this
<alexnask>
Right
<bheads__>
this fails
<alexnask>
So
<MajorLag1>
because it isn't an array
<alexnask>
Slices are structs
<alexnask>
With a .ptr and .len field
<alexnask>
So it's a bit involved to check if a type is a slice (unless you know what the type of the slice should be), will probably be a function in std.meta
<bheads__>
this does alright at unwrapping it for me
<alexnask>
Right, to check if arg_t is a slice you should take its TypeInfo, check that it has Struct typeId then check its fields
<MajorLag1>
The docs don't say it, but at some point I think a TypeId.Slice was added. Though apparently @tagName(@typeId()) is broken right now, so I can't check.
<Hejsil>
On master, slices are not structs anymore
<MajorLag1>
I'm pretty sure that compiler isn't up to date
<Hejsil>
Ye, it's not lol
<MajorLag1>
Ah, ok
<Hejsil>
Though, TypeId.Slice is fairly new too
<MajorLag1>
Point is, it is a lot less cumbersome to determine if a type is a slice than it used to be
<alexnask>
Ah right
<bodie__>
man, looking at all these proposals in github, I can really see how feature creep is a nightmare beast to be fought with all of one's might :)
<alexnask>
Its still a struct in the compiler code, @typeInfo just treats it like a pointer and adds Slice to the size enum
<Hejsil>
Yep
<bodie__>
please don't turn Zig into a worse D or Rust...
<Hejsil>
andrewrk has been good at saying no
<alexnask>
Does anyone know if I can force docgen_tmp around when executing the tests?
<MajorLag1>
oh weird, @tagName(@typeId(T)) crashes, but only in tests.
Hejsil has quit [Quit: Page closed]
<bodie__>
Maybe the right approach to some of the features people want is some kind of macro / language extensions package
jcan has quit [Quit: Page closed]
<bheads__>
what, you want macros....?
<alexnask>
/mnt/c/dev/test.zig:12:51: error: slice of non-array type '?*u8'
<bodie__>
well, like how Haskell lets you import language features.
<bodie__>
Then zig could be kept small but also have the option to have e.g. third-party extensions. just thinking out loud here.
<bheads__>
... TODO const expr analyze union field value for equality ....
very-mediocre has joined #zig
<very-mediocre>
how do people around here feel about private/public for properties?
<very-mediocre>
i find myself wanting it, but I suspect it's bad for some reason :)
<very-mediocre>
private properties that is
dsn has quit [Quit: Connection closed for inactivity]
<bheads__>
its is a mixed bag, it gets overused in OOP patterns, but for example you might have a struct that has thread safe accessor function you dont want users to bypass them...
Ichorio has joined #zig
Hejsil has joined #zig
<very-mediocre>
hm I'm not convinced of them being bad
Hejsil_ has joined #zig
very-mediocre_ has joined #zig
<very-mediocre_>
messages got eaten again, ah well :/
Hejsil has quit [Ping timeout: 260 seconds]
very-mediocre has quit [Ping timeout: 260 seconds]
Hejsil_ is now known as Hejsil
bodie__ has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<MajorLag1>
bheads__, ver-mediocre, my feeling is that the programmer can communicate to the user that a field is private and shouldn't be directly accessed via simple naming convention: _varname. If the programmer insists on accessing it directly they might have a good reason. That said, if you really, really need to access it then there's always `@intToPtr(T, @ptrToInt(struct_instance.field) + @offsetOf(Struct, "field"))` as an escape hatch, so it
<MajorLag1>
n't that big a deal to me.
<MajorLag1>
..in fact, thinking about it, it's probably better than the naming convention for one big reason: that information will be explicitly communicated via @typeInfo to comptime code.
<bheads__>
naming convention is not a good or safe way to handle things
<alexnask>
The comptime is probably reduntant there, yes
<alexnask>
The comptime ifs too
<alexnask>
It doesn't hurt since it will guarantee a compiler error if your condition somehow ends up being a runtime condition
bodie__ has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<very-mediocre_>
i see
<alexnask>
In general any expression that can be evaluated at comptime will be
<alexnask>
If you shove the result into a runtime variable, it's just the result of the comptime computation
<bheads__>
yeah I was probably went overboard on the comptimes
<GitHub112>
[zig] andrewrk closed pull request #1113: Make `zig version` compliant with SemVer (master...semver-build-metadata) https://git.io/vhPoO
<alexnask>
In general, I feel like a good guideline is to use it when you want a whole block of code (with variable decls etc) at comptime and in places where you may have intermediate expressions that you want in static storage
<alexnask>
e.g. some_ptr = &comptime some_meta_func(FooType, BarType)
<bheads__>
I do want to avoid comptime at the call site
<bheads__>
but maybe I shouldnt care
<alexnask>
Right, in this case even without comptime I'm 90% positive it would happen at comptime
<alexnask>
It's just that it would have been stored in an intermediate runtime variable
<alexnask>
(Which would be initialized with the value evaluated at comptime)
<andrewrk>
in summary we want casts that do very specific things rather than T(value) "guessing" what you want
<andrewrk>
T(value) can still do "implicit casts" or maybe we remove that syntax altogether and users would need to bind something to a variable if they wanted to cast: const casted_value: T = value;
<alexnask>
Right, so we keep implicit casts for certain (useful) cases and handle the rest of the casts with builtins
<bheads__>
const casted_value: T = value; <- That is a good pattern but results in lots of extra code
<alexnask>
There are some fundamentally unsafe casts though, how should those be handled?
<alexnask>
E.g. T* -> fn(<ArgList>)RetType
<alexnask>
Well
<alexnask>
All those "unsafe casts" can be done with @ptrCast I guess, I just started replacing it without really thinking about it, I assumed those casts where available with the explicit casting syntax
<andrewrk>
some of the casts are simply known and documented to be unsafe
<bheads__>
you have to md5 the the filename, line number and type to compute the unsafe cast key
<Hejsil>
Nice
<andrewrk>
I was thinking though it would be neat to have a "safety score" calculator
<alexnask>
@bheads__ Someone would hack some metaprogramming solution :P
<andrewrk>
it analyzes the codebase, and docks points for unsafe casts
<bheads__>
alexnask, it wans't me
<andrewrk>
an IDE could maybe gently underline the unsafe things, in a way that looks like, ok you don't necessarily need to change this
<andrewrk>
but it would make you uncomfortable if it felt like the code didn't need such a thing
<andrewrk>
might make someone compelled to write a comment to justify it
<bheads__>
really as long as unsafe casts stickout it should be okay
<Hejsil>
Every time you compile, the compiler sends your score to a leaderboard :)
<alexnask>
It just sends the score, we promise /s
<bheads__>
well you could have your repo reject the pull request
<bheads__>
so something like @unsafeCast(T, var) would do a possible unsafe C style case
<bheads__>
most cases implicate cast will work
<bheads__>
@truncating for a few known types i64 -> i8
<bheads__>
then cast between signed/unsigned and flaot/int types
<bheads__>
I thought most was convered already
<Hejsil>
@truncating does not do the safty check i8(some_i64) does
<bheads__>
ah, okay so that would need to change
<bheads__>
would there we want an @unsafeTruncate or just use @unsafeCast?
<Hejsil>
Well, i8(some_i64) is not an unsafe cast, because the compiler does the runtime check. The unsafe casts, are the ones that the compiler cannot check.
<Hejsil>
Like the current @ptrCast
diefroggy242 has joined #zig
<bheads__>
right, I dont think we can remove unsafe casts as long as you can interface to C
<andrewrk>
Hejsil, i8(some_i64) is unsafe - it invokes undefined behavior in release-fast mode if the number didn't fit
<Hejsil>
Aah, welll
<Hejsil>
Ok, then we have unsafe-but-checked casts and unsafe casts :)
<andrewrk>
yeah
diefroggy242 has quit [Client Quit]
<Hejsil>
Let's say, we had all casts as builtins. Would we categories the casts based on unsafeness?
<Hejsil>
In the docs that is
<andrewrk>
we're always looking for ways to try to add checks to unsafe stuff though. for example, it is within zig's rights to insert a field into a struct at the beginning with a "magic identifier" and check for that if you cast to it
<Hejsil>
Hmm
<Hejsil>
Alright, all casts are unsafe-but-checked-if-possible!
<andrewrk>
lol
<Hejsil>
Except @truncate
<bheads__>
there is always unsafe blocks
<andrewrk>
hmm, I think we would perhaps make a nice red noticable warning label and put it on all the casts that assert
<andrewrk>
and on the + operator
<andrewrk>
the + operator looks so innocent
<Hejsil>
:)
<andrewrk>
but it's a bug factory
<Hejsil>
u8 + u8, should give a u9 :)
<Hejsil>
Then it's safe
<andrewrk>
woah
<bheads__>
I think you blew up andrew
<Hejsil>
Lol
<Hejsil>
We're not gonna consider this as a feature, are we?
<Hejsil>
It was a joke, lol
<andrewrk>
nah don't worry, but just run with it for a second
<andrewrk>
that actually would let us make the + operator safe
<andrewrk>
with the result being that you'd have to put @intShorten casts at a lot of places
<bheads__>
yeah it would
<Hejsil>
Hmmm
<andrewrk>
so the safety moves to this cast
<bheads__>
or use +%
<andrewrk>
I don't think we should do it, but I also don't think it's as bad of an idea as it seems
<Hejsil>
And then we can have @unsafeAdd :)
<andrewrk>
especially if we had min/max values in the integer type system
<bheads__>
could this happen at comptime?
<bheads__>
if not already
<Hejsil>
Well, if you use 2 + 2, then it's comptime_int + comptime_int
<bheads__>
comptime_int doesnt have a size does it?
<Hejsil>
And comptime_int is a bigint
<bheads__>
so its already happening
<Hejsil>
But, u8(1) + 1 casts to u8 + u8, so not always
<bheads__>
ah... so + in comptime could overflow
davr0s has joined #zig
<Hejsil>
Yes
<bheads__>
that trick wont help with the other overflows though
<bheads__>
u8(1) - 2 :(
<Hejsil>
Woun't that become a i10
<Hejsil>
And then im pretty use it's safe
<Hejsil>
s/use/sure/g
bodie__ has joined #zig
<bheads__>
thats interesting, then u8(255) * u8(10) ....
<bheads__>
a u16?
<Hejsil>
I think, yes
<Hejsil>
Your int types could explode really fast, lol
<bheads__>
well thats why andrew suggested a cap on the that
<alexnask>
I think there's a C++ library that does similar stuff (through a safe_int type)