<FromGitter>
<stellarpower> @riza - thanks! I'll take a look. PErhaps it could be integrated in with one of the others. num.cr seemed to be the most popular I think/
<FromGitter>
<stellarpower> Actually on that note, can Crystal have non-type parameters for generics?
<FromGitter>
<stellarpower> I guess that would be a core language feature that would be necessary for all this to work, unless we used macros, but that feels a little at the wrong level
<FromGitter>
<Blacksmoke16> you can use numbers (and by extension enum members)
<FromGitter>
<stellarpower> Cool.
<FromGitter>
<stellarpower> That's the main use, I guess. C++20 I think gives us doubles which is pretty sweet, but not needed too often
brw has joined #crystal-lang
<FromGitter>
<stellarpower> Or string_views can be useful but we've got symbols here
<FromGitter>
<stellarpower> IS there documentation on the syntax for that?
<FromGitter>
<stellarpower> Well, that makes life easy
<FromGitter>
<stellarpower> And I guess if support for any other builtin types is added then there are no changes
<FromGitter>
<stellarpower> Presume also `forall` can be use to do something like constraints
<FromGitter>
<Blacksmoke16> are some issues about specialization and such. like restricting what types a type supports etc. but not a lot on allowing other types
<FromGitter>
<stellarpower> Given that types are first-class, I could write an arbitrary predicate that decides if a type meets certain requirements
<FromGitter>
<stellarpower> MM
<FromGitter>
<stellarpower> Guess it's early days still
<FromGitter>
<stellarpower> Just anything goes a long way for me.
<FromGitter>
<Blacksmoke16> i think you could already do that via checking `T` in a macro within `initialize`
<FromGitter>
<stellarpower> I've been having to use numpy and scipy etc. and it's just absolute slop, anything you write is so brittle and the only way you can verify it or pin things down is to test at runtime
<FromGitter>
<stellarpower> Yeah I guess so
<FromGitter>
<Blacksmoke16> e.g. you know, like `{% @type.raise "This type only supports Numbers" unless T <= Number %}` or something like that
<FromGitter>
<stellarpower> Must admit, not seen static exceptions before
<FromGitter>
<stellarpower> I assumed something existed, but not used it myself yet
<FromGitter>
<stellarpower> It's powerful.
<FromGitter>
<stellarpower> Do you speak C++ yourself?
<FromGitter>
<stellarpower> There's something very exciting called Circle:
<FromGitter>
<stellarpower> It simil;arly brings the runtime and compile-time a lot closer, offering the ability to use "normal" structures and algorithms but executing in the context of the compiler
<FromGitter>
<moe:busyloop.net> to toot my horn again: i wish there was syntax like `def foo() throws BarError, BatzError`. ⏎ and crystal would refuse to compile when the method raises anything else.
<FromGitter>
<moe:busyloop.net> that would make crystal code a lot safer (no more surprise `IOError`'s bubbling up from the depths of stdlib). ⏎ and it would also help shard-developers to make their APIs less brittle. ⏎ ("oh, i'm exposing six dozen exceptions here at every step? - maybe should try to model this differently...")
<FromGitter>
<moe:busyloop.net> (methods that don't have a `throws` would just behave like today and let everything bubble through unchecked - that way one can put it only in the strategic places where it matters)
taupiqueur has quit [Remote host closed the connection]
<yxhuvud>
Checked exceptions. Java has that and basically taught people that is not something nice.
<FromGitter>
<moe:busyloop.net> i'm talking about *optional* checked exceptions, though. ⏎ also i believe the java myth is a myth. ⏎ ⏎ what turned java bad is that they made them non-optional and added unchecked exceptions on top (insult + injury). ⏎ ... [https://gitter.im/crystal-lang/crystal?at=636fc6e9473cf96648e19c67]
hightower2 has joined #crystal-lang
<FromGitter>
<Blacksmoke16> There's an issue open about it. Iirc it was mainly for documentation purposes tho
<FromGitter>
<moe:busyloop.net> yeh that would at least be a start. merely discovering what exceptions can bubble up is already a major problem today.
<FromGitter>
<Blacksmoke16> I also wish you could resuce exceptions based on a module they include, like you can with ruby
<FromGitter>
<moe:busyloop.net> yup, that too...
<FromGitter>
<Blacksmoke16> Then you could have your projects exceptions extend a base one, like argument error, and implement the module
<FromGitter>
<Blacksmoke16> Such that you can rescue that specific one, any argument error, or any error from the lib itself
<FromGitter>
<moe:busyloop.net> yea, that doesn't solve my main gripe, but should def be useful. ⏎ ⏎ my main gripe is that my carefully crafted server can crash at basically any time ⏎ just because the dev of some underlying shard (e.g. a websocket lib) forgot to ⏎ handle `IndexError` somewhere. ... [https://gitter.im/crystal-lang/crystal?at=636fcb4d25ca105c88b25f6a]
<FromGitter>
<moe:busyloop.net> i think once people have the option to add `throws` to their methods, we would ⏎ immediately see a bazillion github-tickets raised against low-level shard, asking them ⏎ to please not let `IndexError` bubble up :P
<FromGitter>
<Blacksmoke16> Have the unconditional one last and log when they happen. Gracefully handles the error, but still makes you aware of it if you want to do something special with it
<yxhuvud>
IndexError is typically an indication of a bug, so of course they want it to bubble up.
<FromGitter>
<moe:busyloop.net> yea, that's what i'm doing. but discovering these things incrementally in production is not nice. ⏎ esp. as they can change when the underlying shards change.
<FromGitter>
<oprypin:matrix.org> > as much as i despise go-lang, there is something to be said for it ⏎ > forcing the developer to be at least aware of all errors that can happen. ⏎ ⏎ you can be in that world too if you add an unqualified `rescue` to every call 😂 [https://gitter.im/crystal-lang/crystal?at=636fcbf42cb6570240245319]
<yxhuvud>
oprypin: or use the @-operator in PHP
<yxhuvud>
*shudders*
<FromGitter>
<moe:busyloop.net> no thanks. it's one of the reasons i avoid touching go-lang unless there's a gun to my head. :P ⏎ but i think "optional checked exceptions" would be a nice middleground. ⏎ ⏎ i can put that on the methods where i care. it will tell me exactly which exceptions i need to worry about. ⏎ if the underlying shards change later, compiler will alert me of the fact.
<FromGitter>
<oprypin:matrix.org> Go errors are just forcing you to write `if err!=nil return nil, err` or whatever. it's as good as not doing anything about exceptions. ⏎ the only difference is that there explicitly are functions that can error and functions that claim to never error
<FromGitter>
<oprypin:matrix.org> in crystal you dont have functions that claim to never error, so yea i guess
<FromGitter>
<moe:busyloop.net> yea, go-lang is basically "manually managed exceptions". ⏎ they ask you to "handle or pass upwards". which... well... is basically writing your own exception handling on every freakin' line of code.
<FromGitter>
<moe:busyloop.net> i'm still amazed by how that language became so popular. whenever i look at go-code it takes me ages to make out what its even doing, because half the screen is "if err"
<FromGitter>
<oprypin:matrix.org> yea
<FromGitter>
<moe:busyloop.net> my theory is that one of the biggest parts in its success are the training wheels. ⏎ the compiler is really good at telling you exactly in what places you forgot the `if err`. ⏎ so you can largely copy/paste your way through and it's all good as long as you don't ⏎ try to read back what you've written. [https://gitter.im/crystal-lang/crystal?at=636fce1425ca105c88b265a8]
<FromGitter>
<moe:busyloop.net> anyway, go is way off too far to the left. ⏎ crystal is imho a little bit too far to the right. ⏎ ⏎ if we could nudge crystal just a tiny little bit, it's error handling may end up in the perfect middle. 😊 [https://gitter.im/crystal-lang/crystal?at=636fce8f655bc46025c3cd36]
notzmv has quit [Ping timeout: 260 seconds]
walez has joined #crystal-lang
rymiel has joined #crystal-lang
hightower2 has quit [Remote host closed the connection]