Re: Discussion Thread: DIP 1039--Static Arrays with Inferred Length--Community Review Round 1
On Monday, 11 January 2021 at 21:17:20 UTC, jmh530 wrote: On Monday, 11 January 2021 at 14:42:57 UTC, Nick Treleaven wrote: [snip] Just a suffix like `[1,2]$` or `[1]s`. Then just use `auto var =` with it as normal. Gotcha. I think I would use that more than the current DIP (though I prefer [1]s to [1]$). You can do it today if you don't mind putting the marker in front: https://run.dlang.io/is/E6ne4k (Its operator abuse. What would you expect?)
Re: Discussion Thread: DIP 1039--Static Arrays with Inferred Length--Community Review Round 1
On Tuesday, 12 January 2021 at 17:27:50 UTC, Q. Schroll wrote: On Monday, 11 January 2021 at 21:17:20 UTC, jmh530 wrote: On Monday, 11 January 2021 at 14:42:57 UTC, Nick Treleaven wrote: [snip] Just a suffix like `[1,2]$` or `[1]s`. Then just use `auto var =` with it as normal. Gotcha. I think I would use that more than the current DIP (though I prefer [1]s to [1]$). You can do it today if you don't mind putting the marker in front: https://run.dlang.io/is/E6ne4k (Its operator abuse. What would you expect?) Interesting approach! However, it doesn't really resolve my underlying issue, which was that I would still need to import that s struct.
Re: Discussion Thread: DIP 1039--Static Arrays with Inferred Length--Community Review Round 1
On Tuesday, 12 January 2021 at 18:19:14 UTC, jmh530 wrote: On Tuesday, 12 January 2021 at 17:27:50 UTC, Q. Schroll wrote: On Monday, 11 January 2021 at 21:17:20 UTC, jmh530 wrote: On Monday, 11 January 2021 at 14:42:57 UTC, Nick Treleaven wrote: [snip] Just a suffix like `[1,2]$` or `[1]s`. Then just use `auto var =` with it as normal. Gotcha. I think I would use that more than the current DIP (though I prefer [1]s to [1]$). You can do it today if you don't mind putting the marker in front: https://run.dlang.io/is/E6ne4k (Its operator abuse. What would you expect?) Interesting approach! However, it doesn't really resolve my underlying issue, which was that I would still need to import that s struct. To play the devil's advocate, it shouldn't be hard to change the compiler config file to auto-import any module of your choice (it config file would simply append it to the compiler command line). That said, for me the unnecessary template instances generated for each different type and array length is a bigger reason for me preferring this DIP proposal, over the library approach.
Re: Discussion Thread: DIP 1039--Static Arrays with Inferred Length--Community Review Round 1
On Tuesday, 12 January 2021 at 19:27:31 UTC, Petar Kirov [ZombineDev] wrote: [snip] To play the devil's advocate, it shouldn't be hard to change the compiler config file to auto-import any module of your choice (it config file would simply append it to the compiler command line). [snip] That sounds a bit like magic, in the Arthur C. Clarke sense. Would that work in a project that other people are working on? (i.e., do they have to modify their compiler config files too?). I'd rather put the import at the top of the file, or in a version(unittest) block than that. The problem with those approaches is that if you have an example unittest, then when a user tries to run it then they have to put the import in themselves.
Re: Discussion Thread: DIP 1039--Static Arrays with Inferred Length--Community Review Round 1
On Tuesday, 12 January 2021 at 19:49:10 UTC, jmh530 wrote: I'd rather put the import at the top of the file, or in a version(unittest) block than that. The problem with those approaches is that if you have an example unittest, then when a user tries to run it then they have to put the import in themselves. Seems like the obvious solution is to put the import inside the unittest.
Re: Printing shortest decimal form of floating point number with Mir
On Thursday, 7 January 2021 at 22:15:07 UTC, Ali Çehreli wrote: On 12/23/20 10:05 AM, 9il wrote: > It was a mockery executed by Atila For those who read the above comment but do not want to read the rest of this long thread, the linked PR discussion does not contain mockery: > https://github.com/dlang/dmd/pull/9778#issuecomment-498700369 Ali Agreed, just suboptimal communication.
Re: Discussion Thread: DIP 1039--Static Arrays with Inferred Length--Community Review Round 1
On Tuesday, 12 January 2021 at 20:04:00 UTC, Paul Backus wrote: On Tuesday, 12 January 2021 at 19:49:10 UTC, jmh530 wrote: I'd rather put the import at the top of the file, or in a version(unittest) block than that. The problem with those approaches is that if you have an example unittest, then when a user tries to run it then they have to put the import in themselves. Seems like the obvious solution is to put the import inside the unittest. I mean, I'm not chomping at the bit for it, or this DIP. If things stay as they are, then I'll keep doing what I'm doing.
Re: Discussion Thread: DIP 1039--Static Arrays with Inferred Length--Community Review Round 1
On Tuesday, 12 January 2021 at 20:04:00 UTC, Paul Backus wrote: On Tuesday, 12 January 2021 at 19:49:10 UTC, jmh530 wrote: I'd rather put the import at the top of the file, or in a version(unittest) block than that. The problem with those approaches is that if you have an example unittest, then when a user tries to run it then they have to put the import in themselves. Seems like the obvious solution is to put the import inside the unittest. I'd say that example unit tests shouldn't have anything available except the current module. That a unittest is just a function is wrong in many ways. By default, it shouldn't have access to imports outside of it and it shouldn't have access to non-public (private, package) symbols.
Re: Discussion Thread: DIP 1039--Static Arrays with Inferred Length--Community Review Round 1
On Tuesday, 12 January 2021 at 23:19:45 UTC, Q. Schroll wrote: On Tuesday, 12 January 2021 at 20:04:00 UTC, Paul Backus wrote: On Tuesday, 12 January 2021 at 19:49:10 UTC, jmh530 wrote: I'd rather put the import at the top of the file, or in a version(unittest) block than that. The problem with those approaches is that if you have an example unittest, then when a user tries to run it then they have to put the import in themselves. Seems like the obvious solution is to put the import inside the unittest. I'd say that example unit tests shouldn't have anything available except the current module. That a unittest is just a function is wrong in many ways. By default, it shouldn't have access to imports outside of it and it shouldn't have access to non-public (private, package) symbols. Agreed. Hence why we had to workaround those language limitations in phobos with this: https://github.com/dlang/tools/blob/master/tests_extractor.d