02:33 <FromGitter> <mjfiano:matrix.org> Question about inlining: Is the compiler smart enough to inline a function that is annotated `AlwaysInline` at its callsite if the definition of the to-be-inlined function has not been seen yet (such as if it is defined later in the file, or in a different file that hasn't been processed), or does the compiler ensure the ordering.

02:33 <FromGitter> <Blacksmoke16> pretty sure all the code is loaded before doing any actual compilation

02:34 <FromGitter> <Blacksmoke16> LLVM is pretty smart so you could prob get away with not worrying about perf so much until you run into an actual bottleneck

02:36 <FromGitter> <mjfiano:matrix.org> Yes, I mostly am. I was just curious, and was hoping that would be the case, coming from Lisp where things are loaded and compiled in a strange way, so inlining has these problems.

02:49 <FromGitter> <Blacksmoke16> prob be fine

05:29 <FromGitter> <mjfiano:matrix.org> Do any of you have a naming convention to distinguish partial types from types?

07:40 <FromGitter> <HertzDevil> if you can deal with the empty prelude you can try experimenting with `@[AlwaysInline]` on compiler explorer

07:41 <FromGitter> <mjfiano:matrix.org> Thanks, will do

07:41 <FromGitter> <HertzDevil> speaking of that

07:41 <FromGitter> <HertzDevil> time to add 1.1.1 to ce

07:46 <FromGitter> <mjfiano:matrix.org> @HertzDevil: check my (just edited) comment on 10711 when you get a chance. Would like to know the reasoning :)

08:01 <FromGitter> <HertzDevil> that's because these two defs are currently considered redefinitions

08:01 <FromGitter> <HertzDevil> ```code paste, see link``` [https://gitter.im/crystal-lang/crystal?at=60ffbd52e9aaeb7fbe23d2ae]

08:01 <FromGitter> <mjfiano:matrix.org> o.O

08:02 <FromGitter> <HertzDevil> basically once there are optional positional params a lot of things break down

08:02 <FromGitter> <HertzDevil> for example

08:02 <FromGitter> <HertzDevil> ```code paste, see link``` [https://gitter.im/crystal-lang/crystal?at=60ffbdacc9f8852a970dbdc4]

08:03 <FromGitter> <HertzDevil> every def is considered a redefinition of the preceding one, so only the last one remains

08:03 <FromGitter> <mjfiano:matrix.org> that makes sense

08:03 <FromGitter> <mjfiano:matrix.org> and your PR solves some of this?

08:04 <FromGitter> <mjfiano:matrix.org> I only skimmed the referenced document

08:04 <FromGitter> <mjfiano:matrix.org> I will read more later

08:04 <FromGitter> <HertzDevil> all, to my knowledge

08:04 <FromGitter> <HertzDevil> except where comparisons between the individual restrictions break down ig

08:04 <FromGitter> <mjfiano:matrix.org> Very nice, so just waiting on some specs to be written?

08:06 <FromGitter> <HertzDevil> more like waiting for 2.0, though if a proper warning is decided upon we might be able to see this in 1.x

08:07 <FromGitter> <mjfiano:matrix.org> Great. I don't need it any time soon, as there wasn't any particular reason for optional arguments here, nor a T parameter.

08:07 <FromGitter> <mjfiano:matrix.org> Ok, bed time. enjoy the ce hacking

12:29 <FromGitter> <HertzDevil> crystal 1.1.1 is now live on ce

12:49 <yxhuvud> nice, though there are some unmerged fixes I hoped for that isn't in yet.

13:02 <straight-shoota> yxhuvud which ones?

13:03 <yxhuvud> well 11002. But it is of course possible to work around

13:04 <straight-shoota> Yeah, that's going into 1.2

13:04 <straight-shoota> 1.1.1 received only essential bugfixes (such as regressions in 1.1.0)

13:14 <yxhuvud> well, the problem was that from_errno also stopped accepting a custom errno. So things broke with no replacement.

13:15 <yxhuvud> But I guess I'm pretty alone in using that :D

13:42 <straight-shoota> Did that change in 1.1.0?

13:44 <yxhuvud> yes.

13:45 <yxhuvud> basically `from_errno(errno: Errno.new(2)) ` used to work but now gives an error due to errno being injected twice.

13:47 <yxhuvud> oh well, at least I can use the new interface if I provide a string. it might even provide some context so perhaps it isn't bad

13:49 <straight-shoota> You can open an issue about backporting that fix and we could release it in 1.1.2

13:52 <yxhuvud> not certain I care enough. I still have enough to rewrite due to your refactoring that it doesn't matter all that much :D

13:52 <yxhuvud> but that is my problem as I monkeypatch private apis :)

18:29 <FromGitter> <djberg96> How long for a brew version of 1.1?

18:33 <FromGitter> <Blacksmoke16> its already live

18:34 <FromGitter> <Blacksmoke16> ```code paste, see link``` [https://gitter.im/crystal-lang/crystal?at=610051976ccf813819dedca3]

18:58 <FromGitter> <RespiteSage> Is this expected behavior? https://carc.in/#/r/bnk5

18:59 <FromGitter> <RespiteSage> `Int#//` doesn't make note of that behavior, though it mentions other cases where it would raise.

19:14 <FromGitter> <djberg96> @Blacksmoke16 looks like i needed to `brew update`

19:15 <FromGitter> <Blacksmoke16> that would do it

19:17 <FromGitter> <mjfiano:matrix.org> Does Crystal have a bit-vector type of sorts?

19:17 <FromGitter> <Blacksmoke16> https://crystal-lang.org/api/master/BitArray.html ?

19:18 <FromGitter> <mjfiano:matrix.org> Oh sigh. Dunno how I missed that

19:18 <FromGitter> <mjfiano:matrix.org> Ty

19:22 <FromGitter> <mjfiano:matrix.org> It looks like the inheritance-based design wasn't very good either. Just finished what is hopefully the final design though, a hybrid mixin/inheritance dsign

19:23 <FromGitter> <mjfiano:matrix.org> The problem was mostly that the relationships between shared methods isn't very hierarchical...it's all mix and match

19:24 <FromGitter> <mjfiano:matrix.org> Otherwise would have been a lot of DRY violations and a pain to maintain

19:26 <FromGitter> <mjfiano:matrix.org> Someone should write about the flexibility Crystal provides wrt mixins, interfaces, inheritance, etc. Maybe I will when some time. I'm sure it would bring some newcomers around.

19:29 <FromGitter> <Blacksmoke16> i feel like thats just most OOP langs ;P

19:30 <FromGitter> <mjfiano:matrix.org> You must have not used many of them :)

20:14 <FromGitter> <mjfiano:matrix.org> Wishlist: Allow more lines of text after `:ditto:` to extend the previous text. Currently this causes a literal `:ditto: to be rendered.

20:21 <riza> I have that wish as well

20:43 <FromGitter> <mjfiano:matrix.org> I think the one thing missing from Crystal I'd really like to see is restrictive type ranges

21:01 <FromGitter> <asterite> What is that?

21:02 <FromGitter> <mjfiano:matrix.org> @asterite: Like, being able to restrict a numeric parameter to a specific domain ⏎ ⏎ ```code paste, see link``` ⏎ ⏎ Or at the very least be able to do something like Nim's range type, which is different from ours: https://git.mfiano.net/mfiano/origin.nim/src/branch/master/src/origin/mat.nim#L589 [https://gitter.im/crystal-lang/crystal?at=6100746eb8422d6f4f0c73dc]

21:24 <FromGitter> <asterite> I see. Yeah, I don't see that ever happening. You can restrict it in generic type arguments, I think. Not sure

21:25 <FromGitter> <Blacksmoke16> Afaik you'd have to check and manually raise in the method

21:25 <FromGitter> <RespiteSage> Yeah. But it works.

21:25 <FromGitter> <RespiteSage> And you can do it in a constructor.

21:37 <FromGitter> <RespiteSage> For example: https://github.com/RespiteSage/saline/blob/main/src/saline/saturating.cr#L29

21:42 <FromGitter> <Blacksmoke16> I think he's mainly wanting to support compile time errors for number literals not in a specific range. i.e instead of checking in code and raising an argument error at runtime

21:48 <FromGitter> <asterite> It can probably be done with macros too

21:59 <FromGitter> <RespiteSage> @Blacksmoke16 Yeah, I know. I was giving an example of restricting values in generic type arguments.

22:15 <raz> why limit it to numerics tho