Awesome!

Remember if you need any help with any of the Unicode changes, please let me know!

On 2/2/23 10:01 AM, jmh530 wrote:

> I was reading through some of the PRs referenced in [issue 23548](https://issues.dlang.org/show_bug.cgi?id=23548), and a little confused by the takeaway. It currently searches for Di, then D files. If it finds none of them, then it searches for C/h files. Is that right? Is this search order described in the spec anywhere?

Previously, it would search in each path, and look for the files in the order of di, then d, then i, then c. So based on the order of the paths, it might find a matching C file before a matching D file in a later import path.

Now, it searches all the paths for D files first, then all the paths for C files second, ensuring that it will prefer D files.

The spec I don't think covers how files are searched for module definitions. The compiler command line docs have some information on what files are expected to contain, but doesn't seem to specify priorities or how they are searched. I don't know if it should be covered in the spec or the compiler docs.

-Steve

On Thursday, 2 February 2023 at 15:56:56 UTC, Steven Schveighoffer wrote:
> [snip]
>
> Previously, it would search in each path, and look for the files in the order of di, then d, then i, then c. So based on the order of the paths, it might find a matching C file before a matching D file in a later import path.
>
> Now, it searches all the paths for D files first, then all the paths for C files second, ensuring that it will prefer D files.
>
> The spec I don't think covers how files are searched for module definitions. The compiler command line docs have some information on what files are expected to contain, but doesn't seem to specify priorities or how they are searched. I don't know if it should be covered in the spec or the compiler docs.
>
> -Steve

Thanks. The new way seems to make more sense to me.

On 2/2/23 04:30, Iain Buclaw wrote:

> Glad to announce D 2.102.0, ♥ to the 40 contributors.

Thanks indeed! Two issues that I had some interest in are fixed. Yay!

  https://issues.dlang.org/show_bug.cgi?id=17378

  https://issues.dlang.org/show_bug.cgi?id=23561

I am aware how complex unicode collation is[1] but I somehow find it very wrong to list Ömer at the end. :)

[...]
> Steven Schveighoffer
> Vladimir Panteleev
> Walter Bright
> Ömer Faruk IRMAK

Obviously because I am used to the Turkish alphabet but in any case because Ö is very much related to O, I find it universally better to list Ö right after O. (The same should be for all latin based characters.)

I see there is std.uni.icmp which uses

  dmd/std/internal/unicode_tables.d

but it doesn't help because the array fullCaseTable in there seems to be about equivalence (e.g. of ß and ss). I think we need a "mostly correct" collation for latin based characters.

I have a hacky[2] solution only for Turkish, which I used for the Index section of my book:


https://bitbucket.org/acehreli/ddili/src/4c0552fe8352dfe905c9734a57d84d36ce4ed476/src/alphabet.d#lines-50

Ali

[1] https://www.unicode.org/reports/tr10/

[2] The comment about the hacky treatment of 'I' in there is another example of how difficult collation is. This may not fit everybody's preference but as a result and as I desired, the entries "IDE" and "InputRange" appear under 'İ' in the index (instead of 'I'):

  http://ddili.org/ders/d/ix.html

On 03/02/2023 6:22 AM, Ali Çehreli wrote:
> but it doesn't help because the array fullCaseTable in there seems to be about equivalence (e.g. of ß and ss). I think we need a "mostly correct" collation for latin based characters.

Yeah collation is a very different beast than comparison, we can absolutely have a correct implementation its just somebody has to do it.

What we have is correct (although incomplete and on my todo list to improve), but it isn't collation and won't be as its a different algorithm and tables.

I.e. we are missing https://www.unicode.org/Public/UCA/15.0.0/allkeys.txt

https://issues.dlang.org/show_bug.cgi?id=10566

On Thursday, 2 February 2023 at 17:22:46 UTC, Ali Çehreli wrote:
> [snip]
>
>   https://issues.dlang.org/show_bug.cgi?id=17378
>
> 

Looks like your bug report is for assert and static assert, but the PR only handles static assert. You might want to file a separate one for assert.

On Thursday, 2 February 2023 at 17:22:46 UTC, Ali Çehreli wrote:
> I am aware how complex unicode collation is[1] but I somehow find it very wrong to list Ömer at the end. :)
>
> [...]
> > Steven Schveighoffer
> > Vladimir Panteleev
> > Walter Bright
> > Ömer Faruk IRMAK
>
> Obviously because I am used to the Turkish alphabet but in any case because Ö is very much related to O, I find it universally better to list Ö right after O. (The same should be for all latin based characters.)
>
> I see there is std.uni.icmp which uses
>
>   dmd/std/internal/unicode_tables.d
>
> but it doesn't help because the array fullCaseTable in there seems to be about equivalence (e.g. of ß and ss). I think we need a "mostly correct" collation for latin based characters.
>

You are more than welcome to raise a PR to fix the sort. :-)

https://github.com/dlang/tools/blob/master/contributors.d#L107-L113