January 12, 2021
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.
January 12, 2021
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.
January 12, 2021
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.
January 13, 2021
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

January 13, 2021
On Monday, 11 January 2021 at 12:32:42 UTC, Nick Treleaven wrote:
> On Friday, 8 January 2021 at 14:07:29 UTC, Luhrel wrote:
>>> Example a3 is straightforward the primary use case for staticArray:
>>>     auto a3 = [1,2,3].staticArray;
>>
>> I really don't like the `.staticArray` because it's non-esthetic. I don't know if it's really argument, mainly because it's very personal.
>
> The worst thing about it is you have to import std.array, so probably people won't bother scrolling to the top to add the import and losing/bookmarking their place,

Why do they have to scroll to the top? Even if they did, what editor are they using that they can't jump back to where they were?

January 13, 2021
On Wednesday, 13 January 2021 at 14:48:07 UTC, Atila Neves wrote:
>
> Why do they have to scroll to the top?

They don't, you're right. But if you want to use it throughout the module you need a top-level import, by convention at the top.

Also the convention seems to be to put a local import at the start of a scope rather than sandwiched in the middle of statements.

> Even if they did, what editor are they using that they can't jump back to where they were?

Geany. You can set a marker but probably the editor should automatically add to location history before the go to start of file key binding is executed.
January 13, 2021
On Monday, 11 January 2021 at 20:25:14 UTC, Luhrel wrote:
>> I think if the DIP proposed a literal syntax instead of a new variable declaration syntax, it would be much less of a burden to the compiler. I think we don't have any partial (variable) type inference syntax ATM.
>
> I don't think that will be complicated to implement, the compiler already says "mismatched array lengths, 2 and 1".

Ok, you're right. I still think a literal syntax is the more natural way to do this though.

January 13, 2021
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:
>> 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?)

Cool. I'd call it F for fixed size array, `F[e1,e2]`.
January 13, 2021
On Wednesday, 13 January 2021 at 15:31:33 UTC, Nick Treleaven wrote:
> On Wednesday, 13 January 2021 at 14:48:07 UTC, Atila Neves wrote:
>>
>> Why do they have to scroll to the top?
>
> They don't, you're right. But if you want to use it throughout the module you need a top-level import, by convention at the top.
>
> Also the convention seems to be to put a local import at the start of a scope rather than sandwiched in the middle of statements.

Yes.

1. Save point
2. Jump to start of function
3. Write local import
4. Jump back

More work than not having to do anything, obviously, but still.

January 13, 2021
On Wednesday, 13 January 2021 at 15:40:35 UTC, Nick Treleaven 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:
>>> 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?)
>
> Cool. I'd call it F for fixed size array, `F[e1,e2]`.

[rant]
Calling T[n] an array is correct and useful. In my opinion, calling T[] an array is wrong, not even imprecise, plain wrong. It's a slice: a typed part of memory that may overlap with arrays and other slices, potentially even typed differently. "Array" gives one, at least it gives me, a wrong impression how the object behaves. Have you seen overlapping "arrays" in any other language? I have not.

Calling T[] an array (sometimes) is the biggest didactic mistake the D community makes. That way, it is unnecessarily hard to learn the concept for anyone who already has an idea what an array is.
[/rant]