| 26 Jul 2024 |
 graveflo | so that would be considered done when the instantiation is sem checked I assume, because under certain conditions related to constrained T the generic body doesn't always have all the info needed to do that | 05:06:04 |
| graveflo | well unless the constraint is deigned to have that information like your concept idea. Thanks for the info. That helped me think through it. I still don't think there is a way to get this done without allowing a symbol to pass through lookup in semGenericStmt and actually bind later. I dunno how I'm going to do that without making it gross but I'll try | 05:08:33 |
| graveflo | * well unless the constraint is designed to have that information like your concept idea. Thanks for the info. That helped me think through it. I still don't think there is a way to get this done without allowing a symbol to pass through lookup in semGenericStmt and actually bind later. I dunno how I'm going to do that without making it gross but I'll try | 05:09:21 |
 _araq | I think you're looking at it from the wrong angle | 05:11:40 |
| _araq | you basically say "this must compile and then by extension this must also compile" | 05:12:06 |
| _araq | but that way lies madness, you end up with a language were everything compiles for consistencies sake | 05:12:55 |
| _araq | and when everything compiles, nothing is prevented at compile-time and you lose all of the benefits of a static language | 05:13:49 |
| _araq | it's the inconsistencies that do the error checking. Yes string does not offer a + operator, that's a feature not a bug. | 05:14:48 |
| _araq | generics are blueprints in Nim, some parts of it are early bound, some parts of it are late-bound. The language design is good if it's clear about when what happens | 05:16:48 |
| _araq | and it's bad when you try to cover every use case without a mixin annotation. | 05:17:26 |
| graveflo | I've heard a similar argument, and it's not a bad one. Are dirty templates flawed by design then? | 05:18:48 |
| _araq | symbol injections invisible at callsite pretty much are. | 05:19:13 |
| graveflo | isn't mixin also a potential problem because it opens the scope fully where the dirty template would not permit bindings outside of the mutual coupling? | 05:19:50 |
| _araq | mixin x simply says "there will be an x here, eventually, don't complain it's undeclared" | 05:20:36 |
| _araq | I guess for my proposal that also means "x is of type <generic parameter>" | 05:21:10 |
| _araq | it doesn't open a scope, it only declares a symbol | 05:21:46 |
| _araq | bbl | 05:21:52 |
| graveflo | yea I guess there shouldn't be a problem of the wrong thing getting bound. If the template expansion is in scope it would be hard to overshadow that. makes sense. does that mean that the issues that reference this problem should officially be solved by using mixin where applicable? I think there were a couple that had issues even with mixin. The only problem is that it's confusing. I'm all for learning a language through and through but knowing how generic procs are processed and how that then affects the interaction with injectable symbols is really not obvious. It's almost tempting to say that mixing in symbols that cannot be bound is a better default then failing to compile. I'd call that javascript level shenanigans so I don't really mean it, but both effects are surprising. Now that I've chased this around for a while I agree with what you're saying. Still can't shake the want for those symbols to bind automatically though without binding too liberally. idk though. I'm going to bed. Thanks for ur help | 05:37:07 |
| _araq | I'm all for learning a language through and through but knowing how generic procs are processed and how that then affects the interaction with injectable symbols is really not obvious. It's almost tempting to say that mixing in symbols that cannot be bound is a better default then failing to compile. I'd call that javascript level shenanigans so I don't really mean it, but both effects are surprising.
Correct. The solution here is to typecheck generics as it's easy to explain and produces good results with no further annotations. | 06:26:35 |
| _araq | (usually) | 06:31:33 |
|  TӨMΛ ☠ changed their profile picture. | 07:54:55 |
 amjadhd | _araq Is it allowed to have a top level atom in NIF ? | 08:16:17 |
| graveflo | so from what was said earlier, type checking them means: typecheck them as best you can with the information that is present and leave the old behavior in place when there is not enough information? | 13:55:25 |
|  mo_ar2006 joined the room. | 14:36:53 |
 mratsim | 
Download image.png | 16:55:08 |
| mratsim | I have some files only used as compile-time and they still generated empty C files with just NimErrorTestFlag | 16:55:18 |
| mratsim | changing to --mm:refc removes all of those useless files | 16:58:14 |
| mratsim | https://github.com/nim-lang/Nim/issues/23897 | 17:05:11 |
|  bbbscarter joined the room. | 19:31:13 |
| _araq | typecheck them as best you can with the information that is present and leave the old behavior in place when there is not enough information?
No, it just typechecks it with the additional typing rule that an unconstrained generic parameter T matches every value and that ambiguous calls/usages are not reported | 21:51:20 |
