Please cast your vote for std.uni at:
http://forum.dlang.org/post/zczqphzzqnxvjfllehzg@forum.dlang.org

On Monday, 20 May 2013 at 06:19:29 UTC, Jesse Phillips wrote:
> Please cast your vote for std.uni at:
> http://forum.dlang.org/post/zczqphzzqnxvjfllehzg@forum.dlang.org

Overall it looks great. I have one question l is it possible to build tries at runtime using CTFE ? Anyway, as long as this is implementable, this have my vote.

Second thing, it is probably too late, but let's ask anyway. Is that possible to rename the thing as std.unicode ?

20-May-2013 12:15, deadalnix пишет:
> On Monday, 20 May 2013 at 06:19:29 UTC, Jesse Phillips wrote:
>> Please cast your vote for std.uni at:
>> http://forum.dlang.org/post/zczqphzzqnxvjfllehzg@forum.dlang.org
>
> Overall it looks great. I have one question l is it possible to build
> tries at runtime using CTFE ?

At compile-time? The short answer is it should be possible but not quite yet.
The long answer is:

enum myA = unicode.alphabetic.toTrie!4;

---
Error: CTFE internal error: unsupported assignment this = p
uni.d(1841):        called from here: this.data.opAssign((Uint24Array!(GcPolicy) __ctmp6762 = 0;

 , __ctmp6762).this(flattened))
uni.d(6742):        called from here: (InversionList!(GcPolicy) __ctmp6477 = 0;

 , __ctmp6477).this(decompressIntervals(compressed))
---
So I forgot to reduce a bug it seems (or maybe I filed it).

Another reason is that will be quite slow to compile (in the current setting). That's why all of tables in new std.uni were precomputed by constructing at run-time and serializing to source.

This is actualy one of things I'd love to push as a separate feature Phobos-wide: serialization of objects to CTFE-able/mixin-able source code. Some of these done in std.uni weren't clean enough to fit into a public interface.

> Anyway, as long as this is implementable,
> this have my vote.
>
> Second thing, it is probably too late, but let's ask anyway. Is that
> possible to rename the thing as std.unicode ?

I dunno. Technically I see no problem with std.unicode except that we
have to patch old code and some ~1.5 year of painfully slow deprecation and for what? If the chief benefit of renaming is aesthetics then I'd rather pass. If we make it as part of restructuring of std.* that is long overdue then I'm fine but it's a discussion in its own.

We should probably split the discussion-while-voting in a separate thread in D.d.

-- 
Dmitry Olshansky

On Monday, 20 May 2013 at 08:15:48 UTC, deadalnix wrote:
> On Monday, 20 May 2013 at 06:19:29 UTC, Jesse Phillips wrote:
>> Please cast your vote for std.uni at:
>> http://forum.dlang.org/post/zczqphzzqnxvjfllehzg@forum.dlang.org
>
> Overall it looks great. I have one question l is it possible to build tries at runtime using CTFE ? Anyway, as long as this is implementable, this have my vote.
>
> Second thing, it is probably too late, but let's ask anyway. Is that possible to rename the thing as std.unicode ?

Please place this in the vote thread, or it will not be counted when I get to tallying.

On Monday, 20 May 2013 at 17:19:34 UTC, Dmitry Olshansky wrote:
> 20-May-2013 12:15, deadalnix пишет:
>> On Monday, 20 May 2013 at 06:19:29 UTC, Jesse Phillips wrote:
>>> Please cast your vote for std.uni at:
>>> http://forum.dlang.org/post/zczqphzzqnxvjfllehzg@forum.dlang.org
>>
>> Overall it looks great. I have one question l is it possible to build
>> tries at runtime using CTFE ?
>
> At compile-time? The short answer is it should be possible but not quite yet.
> The long answer is:
>
> enum myA = unicode.alphabetic.toTrie!4;
>

As long as it is doable, that sound good to me.

> Another reason is that will be quite slow to compile (in the current setting). That's why all of tables in new std.uni were precomputed by constructing at run-time and serializing to source.
>

I understand. To me a caching compiler is the solution here, but that is kind of off topic.

> I dunno. Technically I see no problem with std.unicode except that we
> have to patch old code and some ~1.5 year of painfully slow deprecation and for what? If the chief benefit of renaming is aesthetics then I'd rather pass. If we make it as part of restructuring of std.* that is long overdue then I'm fine but it's a discussion in its own.
>
> We should probably split the discussion-while-voting in a separate thread in D.d.

The problem wth that kind of naming convention is that names do not convey as much meaning. This can be an issue as the library get larger and larger, because you got to remember every single name and can't rely too much on autocompletion.

uni can be unicode, but also unique, union, unit, uniform, unix, unijambist, whatever.

On Tuesday, 21 May 2013 at 01:25:54 UTC, deadalnix wrote:
> On Monday, 20 May 2013 at 17:19:34 UTC, Dmitry Olshansky wrote:
>> 20-May-2013 12:15, deadalnix пишет:
> uni can be unicode, but also unique, union, unit, uniform, unix, unijambist, whatever.

I support renaming to std.unicode;

In the long run, std.uni is just unexpressive.

On 2013-05-20 22:58, eles wrote:
> On Tuesday, 21 May 2013 at 01:25:54 UTC, deadalnix wrote:
>> On Monday, 20 May 2013 at 17:19:34 UTC, Dmitry Olshansky wrote:
>>> 20-May-2013 12:15, deadalnix пишет:
>> uni can be unicode, but also unique, union, unit, uniform, unix, unijambist, whatever.
>
> I support renaming to std.unicode;
>
> In the long run, std.uni is just unexpressive.

+1