Should we use flags instead of bool for stuff like eachUploPair? about mir-algorithm HOT 9 CLOSED

@9il I can see the argument for this, but I have no strong opinion either way so long as it is consistently done throughout mir-algorithm (and perhaps all of mir).

Some things would become more convenient. For instance, in lubeck some of the functions take strings like U and L, these can be changed to flags that represent upper and lower. You can then provide some general facility for U and L across all of mir. For instance, consider stairs, which uses + and - instead of true and false.

from mir-algorithm.

I like the fact that when using an API foo(PassThrough.Yes) is a lot more readable than foo(true), however, there are two potential disadvantages:

• increase in compilation time? (I haven't experimented with this)
• betterC mode? (@9il - does this already work out of the box?)

So if can clear these two points, I am all for flags. Otherwise we might want to roll our own flag implementation?

from mir-algorithm.

betterC mode? (@9il - does this already work out of the box?)

Please ignore this point. I didn't realize that we were talking just about template parameters.

from mir-algorithm.

• increase in compilation time? (I haven't experimented with this)

• There will be three addition template instances for each new flag F (Flag!"F".Flag enum aggregate, Yes.opDispatch!"F".opDispatch and No.opDispatch!"F".opDispatch manifest constants) all of which are essentially compile-time sugar (the compiler won't generate any code for them), so there's should be any increase in code bloat and the difference in compilation speed shouldn't be measurable, since template instances are cached.

• betterC mode?

• The std.typecons.Flag, std.typecons.Yes and std.typecons.No templates produce just enums which don't exist in object files, so this shouldn't add any link-time or run0time dependencies.

from mir-algorithm.

The std.typecons.Flag, std.typecons.Yes and std.typecons.No templates produce just enums which don't exist in object files, so this shouldn't add any link-time or run0time dependencies.

Importing typecons will pull in a huge chunk of Phobos.

from mir-algorithm.

@DmitryOlshansky I don't see how this would be the case.

You wouldn't import std.typecons, you would import std.typecons : Flag, yes, no.

from mir-algorithm.

Please ignore this point. I didn't realize that we were talking just about template parameters.

@wilzbach You mean that Flag takes template parameters, right? A Flag instance would just be an enum : bool. It could be used as a template parameter or a function parameter (or any place else an enum : bool would be used).

from mir-algorithm.

I did a quick test:

flag.d:

import core.stdc.stdio : printf;

extern (C) int main(int argc, in char** argv)
{
    return foo(yes1) + foo(yes2) + foo(no1) + foo(no2);
}

version (UseFlag)
{
    import std.typecons : Flag, Yes, No;

    extern (C) int foo(Flag!"isCool" cool)
    {
        if (cool)
            printf("Cool.\n");
        else
            printf("Not cool.\n");

        return cool ? 2 : 0;
    }

    enum yes1 = Yes.isCool;
    enum yes2 = Flag!"isCool".yes;
    enum  no1 = No.isCool;
    enum  no2 = Flag!"isCool".no;
}
else
{
    extern (C) int foo(bool cool)
    {
        if (cool)
            printf("Cool.\n");
        else
            printf("Not cool.\n");

        return cool ? 2 : 0;
    }

    enum yes1 = true;
    enum yes2 = true;
    enum  no1 = false;
    enum  no2 = false;
}

$ dmd --version
DMD64 D Compiler v2.076.0-dirty
Copyright (c) 1999-2017 by Digital Mars written by Walter Bright

(I used a vanilla DMD v2.076.0 from install.sh , even though the version string doesn't say so)

$ diff <(dmd -v -betterC flag.d) <(dmd -v -betterC -version=UseFlag flag.d)

1c1
< predefs   DigitalMars Posix linux ELFv1 LittleEndian D_Version2 all D_SIMD D_InlineAsm_X86_64 X86_64 CRuntime_Glibc D_LP64 D_PIC assert D_HardFloat
---
> predefs   UseFlag DigitalMars Posix linux ELFv1 LittleEndian D_Version2 all D_SIMD D_InlineAsm_X86_64 X86_64 CRuntime_Glibc D_LP64 D_PIC assert D_HardFloat
18a19,22
> import    std.typecons        (/home/zlx/dlang/dmd-2.076.0/linux/bin64/../../src/phobos/std/typecons.d)
> import    std.meta    (/home/zlx/dlang/dmd-2.076.0/linux/bin64/../../src/phobos/std/meta.d)
> import    std.traits  (/home/zlx/dlang/dmd-2.076.0/linux/bin64/../../src/phobos/std/traits.d)
> import    std.functional      (/home/zlx/dlang/dmd-2.076.0/linux/bin64/../../src/phobos/std/functional.d)

$ echo $?
1

First we see that importing std.typecons : Flag, Yes, No does indeed make the compiler parse more than std.typecons itself (caused by the three top-level imports), though not much more.
I think it should not be too difficult to remove them, though I haven't investigated more deeply.
Also, since goal for the compiler frontend is to become as lazy as possible, this unnecessary parsing can probably be fixed in the compiler in the (hopefully) not too distant future.

Next, we list the object file symbols for the boolean and std.typecons.Flag cases and diff them together:

$ diff <(dmd -betterC flag.d > /dev/null 2>&1 && nm flag) <(dmd -betterC -version=UseFlag flag.d > /dev/null 2>&1 && nm flag)

$ echo $?
0

As you can see, importing std.typecons : Flag, Yes, No doesn't make a difference at link time. As a matter of fact, the two binaries are identical, byte for byte:

$ dmd -betterC flag.d -offlag1 && dmd -betterC -version=UseFlag flag.d -offlag2 && diff flag1 flag2

$ echo $?
0

In conclusion, using std.typecons : Flag, Yes, No shouldn't pose any problems. It's purely a matter of API design.

from mir-algorithm.

OK, lets use them

from mir-algorithm.