Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Variant concat of char and string doesn't work #9774

Open
dlangBugzillaToGithub opened this issue Jul 5, 2019 · 1 comment
Open

Variant concat of char and string doesn't work #9774

dlangBugzillaToGithub opened this issue Jul 5, 2019 · 1 comment
Labels
Arch:x86 Issues specific to x86 Severity:Normal

Comments

@dlangBugzillaToGithub
Copy link

simen.kjaras reported this on 2019-07-05T11:25:16Z

Transfered from https://issues.dlang.org/show_bug.cgi?id=20030

CC List

Description

The following code throws a VariantException complaining about different types (char and immutable(char)[]):

unittest {
    import std.variant;
    Variant v = "";
    v ~= 'a';
}

It's correct in some ways, but clearly a more useful behavior would be to concat the string and char and move on.
@dlangBugzillaToGithub
Copy link
Author

shove commented on 2019-07-08T02:10:01Z

(In reply to Simen Kjaeraas from comment #0)
> The following code throws a VariantException complaining about different
> types (char and immutable(char)[]):
> 
> unittest {
>     import std.variant;
>     Variant v = "";
>     v ~= 'a';
> }
> 
> It's correct in some ways, but clearly a more useful behavior would be to
> concat the string and char and move on.

This shouldn't be a bug. Variant's design has strict restrictions on type qualifiers, because string = immutable (char) [], so the ~ operator restricts char. v ~= cast (immutable char)'a'; is possible because its qualifier is consistent.

For these limitations, you can see the unittest:
https://github.com/dlang/phobos/blob/master/std/variant.d#L2655

There are many anomaly collection behaviors for qualifier inconsistencies.

I don't know whether it was intentionally designed to do this, or because it was temporarily done for the sake of simplicity. I think, if there are no other factors, it would be better to fix the variant implementation and remove these restrictions.

@LightBender LightBender removed the P3 label Dec 6, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Arch:x86 Issues specific to x86 Severity:Normal
Projects
None yet
Development

No branches or pull requests

2 participants