andremedeiros has quit [Ping timeout: 240 seconds]
andremedeiros has joined #crystal-lang
sorcus has quit [Quit: WeeChat 3.0]
sorcus has joined #crystal-lang
deavmi has quit [Ping timeout: 272 seconds]
deavmi has joined #crystal-lang
_ht has joined #crystal-lang
hendursa1 has joined #crystal-lang
hendursaga has quit [Ping timeout: 268 seconds]
<FromGitter>
<HertzDevil> yeah that snippet doesn't work
<FromGitter>
<HertzDevil> in fact even doing the literal expansion for `&&` and `||` manually seems to break typing too https://play.crystal-lang.org/#/r/agg2
<FromGitter>
<HertzDevil> 1) 35.1 and before were similar
deavmi has quit [Ping timeout: 265 seconds]
deavmi has joined #crystal-lang
<FromGitter>
<RespiteSage> Re the conversation yesterday about `break` with a value: what I'm getting at is that I'm not sure the perceived benefit outweighs its lack of semantic clarity. One of the benefits of Crystal (and, I assume, Ruby) is that the syntax allows for language-like semantics, so even someone who isn't familiar with the language or deeply familiar with the standard library can understand most code that's written.
<FromGitter>
... And certainly, if I think that `break` with a value is unclear, I can just avoid using it. But people will use it, because usually they care more about how fast they can write their thing (and how clever they can be) than whether they or someone else will be able to read it later.
<FromGitter>
<RespiteSage> Also, I think the "to be more like Ruby" is a silly reason to add things to the language, unless it's a minor weighing factor on a decision that is otherwise balanced in more important pros and cons. But I think I've made that clear on the forums before.
<FromGitter>
<RespiteSage> All that said, "consistent with all existing behavior" is a pretty convincing argument to me.
<FromGitter>
<RespiteSage> In the sense of matching the behavior of "next".
deavmi has quit [Ping timeout: 272 seconds]
deavmi has joined #crystal-lang
deavmi has quit [Ping timeout: 272 seconds]
alexherbo2 has joined #crystal-lang
deavmi has joined #crystal-lang
<FromGitter>
<naqvis> true and another point i would like to add is both `break` and `next` behaves differently in `Blocks` and `Loop` constructs.
HumanG33k has quit [Remote host closed the connection]
HumanG33k has joined #crystal-lang
HumanG33k has quit [Max SendQ exceeded]
HumanG33k has joined #crystal-lang
<watzon>
It would be nice if we could have arbitrarily large integers in Crystal without using GMP. LLVM actually has support for integers with as many as 2^23 - 1 bits. I wonder why we're not using that.
<watzon>
I think such a thing could actually be done without many breaking changes too. Just have `Int` be instead `Int(N)` where N is the bitsize. Then existing abstractions like `Int32` could be defined as `struct Int32 < Int(32)`. Numbers could still default to 32 bit blocks (Int32, Int64, Int128, etc), but if someone wanted they could also do `0_i256` or `Int(256).new(0)`.
<watzon>
The main place where I can see this being useful is in cryptography and different RPC protocols. For instance, the MTProto library I'm working on right now requires the ability to serialize and deserialize 128 and 256 bit integers to and from binary.
<sorcus>
watzon: And how hard is to implement BigInt in crystal?
<watzon>
With BigInt it's a major pain in the ass. First of all, there's no built in way to write BigInt's to a byte slice. There's also no "standard" way of doing so. Even if there was though, there's the problem of how many bytes to write. You could have a BigInt that's meant to represent a Int256, but if the number it contains isn't 32 bytes you''ll end up writing the wrong number of bytes.
<watzon>
This can be remedied by doing something like `to_slice(byte_count)` or something, but that breaks the possibility of a unified interface with the other number types. With all of them I can just do `slice.write_bytes(number, IO::ByteFormat::LittleEndian)`
<FromGitter>
<RespiteSage> Isn't the benefit of `BigInt` that it's only as big as it needs to be?
<watzon>
Overall it's a big time edge case. I know only a very small percentage of developers will ever work with integers larger than 64 bits, let alone 128. But it is something that happens quite a bit in the crypto world now.
<watzon>
@RespiteSage from what I understand, yes. Which is great for cases where it makes sense, but not so great when you need to serialize that BigInt to bytes.
<FromGitter>
<RespiteSage> Could that be a shard instead of something in stdlib?
alexherbo2 has quit [Ping timeout: 240 seconds]
<watzon>
Possibly, but it would require working with a lot of LLVM intrinsics, and certain things wouldn't be able to be implemented outside of the compiler. For instance, being able to actually parse larger integers. All integers larger than a UInt64 would have to be wrapped in `Int.new`.
<watzon>
Second thought I don't think it could be done at all in the way I was talking about. You couldn't rewrite the Int type, so you'd have to make your own and lose direct compatibility with builtins. Granted it could still be done, but this is definitely something that would belong as a core part of the language.
<watzon>
It would also make Crystal one of only two languages that I know of that support arbitrarily large integers. With the other being Zig.
<FromGitter>
<RespiteSage> I think probably a main reason why we're not using the LLVM arbitrary-precision integers is that they were added to LLVM in 2019; I believe `BigInt` has been in Crystal longer than that.
<watzon>
That would make sense. Maybe my proposal isn't too far out there then. Crystal has been around since 2014, so it makes sense that this wouldn't have been a consideration early on.
<FromGitter>
<RespiteSage> No, wait. This is about a patch to C that uses the LLVM arbitrary-width integers, I think.
<watzon>
Ahh yeah, it is. It mentions LLVM's already existing ability to represent integers with a bitwidth from 1 to 16,777,215 at the very beginning.
<watzon>
Yeah it looks like that RFC is for Clang specifically to support it. Looks like LLVM already did at the time.
<FromGitter>
<oprypin:matrix.org> RespiteSage (Benjamin Wade): ⏎ ⏎ > I think the "to be more like Ruby" is a silly reason to add things ⏎ ⏎ look, im the biggest hater of Ruby out here, and yet i was the one to suggest that break with value makes more sense [https://gitter.im/crystal-lang/crystal?at=6036a674739b422ea754f05f]
<FromGitter>
<RespiteSage> @watzon I'm having trouble figuring out when they added it to llvm-ir; it seems like the same kind of documentation opaqueness as the language reference being on one huge web page.
<watzon>
Yeah LLVM isn't super easy to decipher. I suppose one could go find that method in github and check the blame.
<FromGitter>
<RespiteSage> @oprypin:matrix.org A fair point. I do see the validity in arguments for it, particularly the consistency argument. I just think it's not a self-documenting feature at all.