Re: uniform initialization in D (as in C++11): i{...}
On Tuesday, 5 April 2016 at 05:44:38 UTC, Timothee Cour wrote:
typo:
q{...} // comment (existing syntax)
=>
q{...} // string literal (existing syntax)
On Mon, Apr 4, 2016 at 10:39 PM, Timothee Cour
wrote:
[...]
D currently supports
Point3 p = { x:1, y:2, z:3 };
It just needs to be extended to work in more places.
https://issues.dlang.org/show_bug.cgi?id=15692
Re: Any usable SIMD implementation?
On 4/4/2016 11:10 PM, 9il wrote: It is impossible to deduct from that combination that Xeon Phi has 32 FP registers. Since dmd doesn't generate specific code for a Xeon Phi, having a compile time switch for it is meaningless. "Since the compiler never generates AVX or AVX2" - this is definitely nor true, see, for example, LLVM vectorization and SLP vectorization. dmd is not LLVM. It's entirely practical to compile code with different source code, link them *both* into the executable, and switch between them based on runtime detection of the CPU. This approach is complex, Not at all. Used to do it all the time in the DOS world (FPU vs emulation). I just want an unified instrument to receive CT information about target and optimization switches. It is OK if this information would have different switches on different compilers. Optimizations simply do not transfer from one compiler to another, whether the switch is the same or not. They are highly implementation dependent. Auto vectorization is only example (maybe bad). I would use SIMD vectors, but I need CT information about target CPU, because it is impossible to build optimal BLAS kernels without it! I still don't understand why you cannot just set '-version=xxx' on the command line and then switch off that version in your custom code.
Re: So... let's document dmd
On 1/16/2016 7:13 AM, H. S. Teoh via Digitalmars-d wrote: I disagree. I think having the dmd itself (lexer, parser, etc.) as a library (with the dmd executable merely being the default frontend) will do D a lot of good. For one thing, IDE's will no longer need to reinvent a D parser for the purposes of syntax highlighting; On the other hand, using lexer.d and parse.d as a guide to build your own is a trivial undertaking. The Boost license is designed so this can be done without worrying about making a derived work. I looked into doing syntax highlighting for my editor, MicroEmacs. It turns out it is not so easy to just use a compiler lexer/parser for it. For one thing, the one used in the compiler is optimized for speed in a forward pass through the text. But a syntax highlighter in a text editor is different. Suppose I change a character in the middle of a line. All the highlighting from that point forward may change. And to figure out what that change is, the parser/lexer has to start over from the beginning of the file! (Think string literals, nested comments, quoted string literals, etc.) This would make editing slow. I surmised that a solution is to have each line in the editor be tagged with a state to show the lexing state at the beginning of that line. Then, when a character in a line changes, the lexer can be restarted from that state, and it continues forward until the next line state matches the new computed state. This would make it enormously faster. But the compiler's lexer is not designed to be restartable in the middle. Similarly, a source code formatter would be different in a different way. It would need, for example, extra information about comments, token start/end positions, etc. Such data collection would be irrelevant to a compiler, and would slow it down and consume unneeded memory.
Re: Any usable SIMD implementation?
On Tuesday, 5 April 2016 at 08:34:32 UTC, Walter Bright wrote: On 4/4/2016 11:10 PM, 9il wrote: It is impossible to deduct from that combination that Xeon Phi has 32 FP registers. Since dmd doesn't generate specific code for a Xeon Phi, having a compile time switch for it is meaningless. "Since the compiler never generates AVX or AVX2" - this is definitely nor true, see, for example, LLVM vectorization and SLP vectorization. dmd is not LLVM. The particular design and limitations of the dmd backend shouldn't be used to define D. In the extreme, your argument would imply that there's no point having version(ARM) built in to the language, because dmd doesn't support it. It's entirely practical to compile code with different source code, link them *both* into the executable, and switch between them based on runtime detection of the CPU. This approach is complex, Not at all. Used to do it all the time in the DOS world (FPU vs emulation). I just want an unified instrument to receive CT information about target and optimization switches. It is OK if this information would have different switches on different compilers. Optimizations simply do not transfer from one compiler to another, whether the switch is the same or not. They are highly implementation dependent. Auto vectorization is only example (maybe bad). I would use SIMD vectors, but I need CT information about target CPU, because it is impossible to build optimal BLAS kernels without it! I still don't understand why you cannot just set '-version=xxx' on the command line and then switch off that version in your custom code. So you're suggesting that libraries invent their own list of versions for specific architectures / CPU features, which the user then has to specify somehow on the command line? I want to be able to write code that uses standardised versions that work across various D compilers, with the user only needing to type e.g. -march=native on GDC and get the fastest possible code.
Re: uniform initialization in D (as in C++11): i{...}
On Tuesday, 5 April 2016 at 05:39:25 UTC, Timothee Cour wrote:
what's D's answer for C++11's uniform initialization [1] which
allows DRY code?
Could we have this:
struct A{
int a;
int b;
}
A fun(A a, int b) {
if(b==1) return i{0,1};
else if(b==2) return i{2,3};
else return fun(i{3,4}, 1);
}
A fun(A a, int b) {
if(b==1) return [0,1];
else if(b==2) return [a:2,b:3];
else return fun([3,4], 1);
}
Re: Any usable SIMD implementation?
On Tuesday, 5 April 2016 at 08:34:32 UTC, Walter Bright wrote: On 4/4/2016 11:10 PM, 9il wrote: I still don't understand why you cannot just set '-version=xxx' on the command line and then switch off that version in your custom code. I can do it, however I would like to get this information from compiler. Why? 1. This would help to eliminate configuration bugs. 2. This would reduce work for users and simplified user experience. 3. This is possible and not very hard to implement if I am not wrong. Ilya
Re: Let's market D: tell us how you're using it
I use D as better C. Various things like a packer plugin for Total Commander. Previously I used C for it, but now I wonder why it was C? D is much better: slices, templates, UFCS, asserts, version. COM is more streamlined too, though TypeInfo the elephant doesn't fit in the kitchen yet :)
Re: Any usable SIMD implementation?
On 4/5/2016 2:03 AM, John Colvin wrote: So you're suggesting that libraries invent their own list of versions for specific architectures / CPU features, which the user then has to specify somehow on the command line? I want to be able to write code that uses standardised versions that work across various D compilers, with the user only needing to type e.g. -march=native on GDC and get the fastest possible code. There's a line between trying to standardize everything and letting add-on libraries be free to innovate. Besides, I think it's a poor design to customize the app for only one SIMD type. A better idea (I've repeated this ad nauseum over the years) is to have n modules, one for each supported SIMD type. Compile and link all of them in, then detect the SIMD type at runtime and call the corresponding module. (This is how the D array ops are currently implemented.) My experience with command line FPU switches is few users understand what they do and even fewer use them correctly. In fact, I suspect that having a command line FPU switch is too global a hammer. A pragma set in just the functions that need it might be much better. --- In any case, this is not a blocker for getting the library designed, built and debugged.
Re: Any usable SIMD implementation?
On 4/5/2016 2:39 AM, 9il wrote: On Tuesday, 5 April 2016 at 08:34:32 UTC, Walter Bright wrote: On 4/4/2016 11:10 PM, 9il wrote: I still don't understand why you cannot just set '-version=xxx' on the command line and then switch off that version in your custom code. I can do it, however I would like to get this information from compiler. Why? 1. This would help to eliminate configuration bugs. 2. This would reduce work for users and simplified user experience. 3. This is possible and not very hard to implement if I am not wrong. Where does the compiler get the information that it should compile for, say, AFX?
Re: uniform initialization in D (as in C++11): i{...}
On Tuesday, 5 April 2016 at 09:22:12 UTC, Jin wrote:
On Tuesday, 5 April 2016 at 05:39:25 UTC, Timothee Cour wrote:
what's D's answer for C++11's uniform initialization [1] which
allows DRY code?
Could we have this:
struct A{
int a;
int b;
}
A fun(A a, int b) {
if(b==1) return i{0,1};
else if(b==2) return i{2,3};
else return fun(i{3,4}, 1);
}
A fun(A a, int b) {
if(b==1) return [0,1];
else if(b==2) return [a:2,b:3];
else return fun([3,4], 1);
}
Square brackets look better than curly brackets which create a
lot of visual noise, especially when mixed with other brackets.
It also feels neat to treat tuples like an array of mixed types.
Can't we be more aggressive about reclaiming the comma operator
for tuples?
Re: Any usable SIMD implementation?
On Tuesday, 5 April 2016 at 09:39:21 UTC, 9il wrote: 3. This is possible and not very hard to implement if I am not wrong. Last time I looked into this (related to implementing @target, see [1]), I only found some Clang code dealing with this, but now I found LLVM functions about architectures, cpus, features, etc. So indeed I also think it will be relatively easy indeed to implement at least rudimentary support for what you'd want. [1] http://forum.dlang.org/post/eodutgruoofruperr...@forum.dlang.org
Re: Any usable SIMD implementation?
On Tuesday, 5 April 2016 at 10:30:19 UTC, Walter Bright wrote: On 4/5/2016 2:39 AM, 9il wrote: On Tuesday, 5 April 2016 at 08:34:32 UTC, Walter Bright wrote: 1. This would help to eliminate configuration bugs. 2. This would reduce work for users and simplified user experience. 3. This is possible and not very hard to implement if I am not wrong. Where does the compiler get the information that it should compile for, say, AFX? No idea about AFX. Do you choose AFX to disallow me to find an example? You know better than me, that GCC and LLVM based compilers have options like march, mcpu, mtarget, mtune and others. And things like `-mcpu=native` or `-march=native` are allowed. Ilya
Re: Any usable SIMD implementation?
On Tuesday, 5 April 2016 at 10:27:46 UTC, Walter Bright wrote: On 4/5/2016 2:03 AM, John Colvin wrote: There's a line between trying to standardize everything and letting add-on libraries be free to innovate. Besides, I think it's a poor design to customize the app for only one SIMD type. A better idea (I've repeated this ad nauseum over the years) is to have n modules, one for each supported SIMD type. Compile and link all of them in, then detect the SIMD type at runtime and call the corresponding module. (This is how the D array ops are currently implemented.) My experience with command line FPU switches is few users understand what they do and even fewer use them correctly. In fact, I suspect that having a command line FPU switch is too global a hammer. A pragma set in just the functions that need it might be much better. What wrong for scientist to write `-mcpu=native`? --- In any case, this is not a blocker for getting the library designed, built and debugged. Yes, but this is bad idea to have a set of versions for Phobos, is not it? Ilya
Re: So... let's document dmd
On 2016-01-16 16:13, H. S. Teoh via Digitalmars-d wrote: I disagree. I think having the dmd itself (lexer, parser, etc.) as a library (with the dmd executable merely being the default frontend) will do D a lot of good. For one thing, IDE's will no longer need to reinvent a D parser for the purposes of syntax highlighting; they can reuse the actual parser the compiler itself uses, and thus actually be correct (whereas their own parser may actually only parse a subset of D correctly). They will also be able to support instant feedback as the user types in D code (highlight syntax errors on the fly, etc.). I agree very much with this. Unfortunately many (most?) editors use their own weird syntax to describe grammars for syntax highlighting and cannot use a proper lexer/parser. -- /Jacob Carlborg
Re: uniform initialization in D (as in C++11): i{...}
On 2016-04-05 09:47, ZombineDev wrote:
D currently supports
Point3 p = { x:1, y:2, z:3 };
It just needs to be extended to work in more places.
https://issues.dlang.org/show_bug.cgi?id=15692
That's only for structs. A uniform initialization syntax needs to be ...
uniform. It has to work for everything.
--
/Jacob Carlborg
Re: uniform initialization in D (as in C++11): i{...}
On Tuesday, 5 April 2016 at 05:39:25 UTC, Timothee Cour wrote:
As for which syntax to use, that's an orthogonal question, but
here I used i{} since {} (from C++11) is already used by
delegates (with tuples also being discussed at some point,
which didn't pan out bc someone mentioned it was ambiguous in
some case; see my next email proposal below though [2])
{} // delegate (existing syntax)
q{...} // comment (existing syntax)
i{...} // uniform intialization (proposed syntax)
t{...} // tuple(a,b) (proposed syntax)
T{...} // TypeTuple!(a,b) (proposed syntax)
[1]
http://programmers.stackexchange.com/questions/133688/is-c11-uniform-initialization-a-replacement-for-the-old-style-syntax
[2] EMAIL:proposed syntax for tuple: t{} and TypeTuple: T{}
D doesn't have initialization syntax problems that C++ has, so it
doesn't need "uniformization" (it isn't really an uniformization,
which is hillarious) of the syntax.
Re: uniform initialization in D (as in C++11): i{...}
On Tuesday, 5 April 2016 at 05:39:25 UTC, Timothee Cour wrote:
q{...} // comment (existing syntax)
That is syntax for a string literal, not a comment (though unlike
other string literals, the contents must be valid D tokens and
editors usually do not highlight them as strings).
Re: uniform initialization in D (as in C++11): i{...}
On Tuesday, 5 April 2016 at 11:35:35 UTC, Jacob Carlborg wrote:
On 2016-04-05 09:47, ZombineDev wrote:
D currently supports
Point3 p = { x:1, y:2, z:3 };
It just needs to be extended to work in more places.
https://issues.dlang.org/show_bug.cgi?id=15692
That's only for structs. A uniform initialization syntax needs
to be ... uniform. It has to work for everything.
D already has `typeof(return)`.
struct A{
int a;
int b;
}
A fun(A a, int b) {
if(b==1) return typeof(return)(0,1);
else if(b==2) return typeof(return)(2,3);
else return fun(typeof(return)(3,4), 1);
}
Or to better mimic the proposed syntax:
A fun(A a, int b) {
alias i = typeof(return);
if(b==1) return i(0,1);
else if(b==2) return i(2,3);
else return fun(i(3,4), 1);
}
Re: So... let's document dmd
On Tuesday, 5 April 2016 at 08:46:30 UTC, Walter Bright wrote: On 1/16/2016 7:13 AM, H. S. Teoh via Digitalmars-d wrote: I disagree. I think having the dmd itself (lexer, parser, etc.) as a library (with the dmd executable merely being the default frontend) will do D a lot of good. For one thing, IDE's will no longer need to reinvent a D parser for the purposes of syntax highlighting; On the other hand, using lexer.d and parse.d as a guide to build your own is a trivial undertaking. The Boost license is designed so this can be done without worrying about making a derived work. I looked into doing syntax highlighting for my editor, MicroEmacs. It turns out it is not so easy to just use a compiler lexer/parser for it. For one thing, the one used in the compiler is optimized for speed in a forward pass through the text. But a syntax highlighter in a text editor is different. Suppose I change a character in the middle of a line. All the highlighting from that point forward may change. And to figure out what that change is, the parser/lexer has to start over from the beginning of the file! (Think string literals, nested comments, quoted string literals, etc.) This would make editing slow. This is how CE highlither works. The lexer used to highlight processes line by line. For each line infos about the previous line are available (nested comments count, region kind like quoted string, raw quoted string, asm, etc). Also keyword detection might use different dictionaries, up to 3 (one for the keywords, another for special keywords like __FILE__, a third for asm opcodes). Operators doesn't need to have a special token (tokxorequ, toplusplus, etc) there's just one. Also lexing number doesn't need to be as accurate as the front-end of the compiler (especially if the HL doesnt have a token type for the illegal "lexem". Another big difference is that the lexer used by an highlighter doesn't store the identifier associated to a token. Using the front-end (or even libdparse) would require a modularisation. But lexing is not hard so I don't think it's worse. At last it would only be used by 4 or 5 softwares.
Re: proposed syntax for tuple: t{} and TypeTuple: T{} (cf precedent of q{...})
On 05.04.2016 07:45, Timothee Cour via Digitalmars-d wrote:
How about the following syntax instead:
{} // delegate (existing syntax)
q{...} // string literal (existing syntax)
t{...} // tuple(a,b) (proposed syntax)
T{...} // TypeTuple!(a,b) (proposed syntax)
In existing syntax, most {...} blocks can contain semicolon separated
declarations. Your proposed constructs would be comma separated lists.
I'd vote for other delimiters because of that. Static struct
initializers are the exception in existing syntax, but they stick out,
and they're not used often.
Parentheses are not an option because of arbitrary identifiers in
function calls and such, and making `t`/`T` keywords for this purpose
doesn't seem wise. That leaves square brackets. `t[...]` doesn't clash
with anything, as far as I see. And it makes a good fit for the feature,
in my opinion. So I'd prefer `t[...]` over `t{...}`.
I'm not sure if the new syntax is worth adding, though. `T{...}` (or
`T[...]`) saves just one character over `T!(...)`. The latter can be
done without touching the language. For the value tuple, one can do
`alias t = std.typecons.tuple;` which gives you `t(...)`. That's just as
short as `t{...}`. But maybe std.typecons.tuple is lacking somehow. A
more proper `t(...)` could be implemented when functions could return
tuples, which would also be desirable if we had `t{...}` syntax. So
implementing `T!(...)` and `t(...)` in D seems like the way to go to me.
And maybe allow functions to return tuples.
Re: uniform initialization in D (as in C++11): i{...}
On Tuesday, 5 April 2016 at 11:35:35 UTC, Jacob Carlborg wrote:
On 2016-04-05 09:47, ZombineDev wrote:
D currently supports
Point3 p = { x:1, y:2, z:3 };
It just needs to be extended to work in more places.
https://issues.dlang.org/show_bug.cgi?id=15692
That's only for structs. A uniform initialization syntax needs
to be ... uniform. It has to work for everything.
Yeah, that's what I had in mind. new Object{}, int(3) -> int{3},
T() -> T{} (in generic code), and {42, "tuple"} where the type
can be deduced.
On the other hand, this may not be such a good idea, because of
https://github.com/D-Programming-Language/dmd/pull/1356, which
made T() the standard syntax for uniform construction syntax,
instead of T{}. Unfortunately the (1, 2, 3) syntax is can't be
used for tuples because it is ambiguous/looks bad in some places:
// this looks ok
auto tuple = (1, 3.4, "a string");
// however this looks really strange
foo((1, 3.4, "a string"))
// and this even more ambiguous for the reader.
int a=1, b=2, c=3;
auto i = (a += 2, a + b); // C-style comma operator usage, or
tuple?
Even the [] array syntax is not a good idea, because it implies a
homogeneous container.
I guess this leaves binary operator abuse like:
auto tuple = |a, "asd"|;
auto tuple = <"asd, 42, 'c'>;
:D
IMHO, the curly brace syntax auto t = {'a', "tuple"}; is the
least bad syntax.
Re: uniform initialization in D (as in C++11): i{...}
On Tuesday, 5 April 2016 at 14:45:33 UTC, ZombineDev wrote:
Yeah, that's what I had in mind. new Object{}, int(3) ->
int{3}, T() -> T{} (in generic code), and {42, "tuple"} where
the type can be deduced.
Unfortunately the (1, 2, 3) syntax is can't be used for tuples
because it is ambiguous/looks bad in some
If it is supposed to be uniform, why have the type name in one
place but not another?
I really don't understand what the problem with Whatever!(x,y,z)
is.
(other than the fact that Tuple sucks. structs are better in
every way. but it isn't because of syntax.)
Re: proposed syntax for tuple: t{} and TypeTuple: T{} (cf precedent of q{...})
On Tuesday, 5 April 2016 at 05:45:08 UTC, Timothee Cour wrote:
{} for tuples hasn't worked out since it was deemed ambiguous
with delegate syntax (was it for the case of empty
statements/tuple?).
How about the following syntax instead:
{} // delegate (existing syntax)
q{...} // string literal (existing syntax)
t{...} // tuple(a,b) (proposed syntax)
T{...} // TypeTuple!(a,b) (proposed syntax)
See also [1] where i propose i{...} for a D analog of C++11's
uniform initialization.
[1] EMAIL: uniform initialization in D (as in C++11): i{...}
I don't think that t or T is needed in front of {}.
1) Function literals / lambdas / delegates:
If someone wants an empty function literal, they just have to use
(){} instead of {}:
alias Action = void delegate();
Action action = (){}; // instead of
Action action = {}; // error: `{}` is an empty tuple, can't be
assigned to delegates
auto t = {}; // deduced as an empty tuple.
Also, the non-empty {} syntax can't be mistaken for a function
literal because non-empty function literals always have at least
one statement that ends with a semicolon.
2) Tuples and AliasSeq-s.
Correct me if I'm wrong, but I think that in all cases the
expression is unambiguous:
auto t1 = {3, 4}; // Tuple
enum t2 = {3, 4}; // Tuple
alias t3 = {3, 4}; // AliasSeq
void foo(Tuple!(int, int) x);
foo({3, 4}); // same as foo(t1), or foo(t2)
template staticMap(alias F, T...);
alias constTypes = staticMap!( constOf, { int, float, void[] }
);
static assert (is( constTypes == { const(int), const(float),
const(void[]) } );
writefln!({int, string, double})("%s %s %s", {3, "test", 4.2});
Re: uniform initialization in D (as in C++11): i{...}
On Tuesday, 5 April 2016 at 14:57:14 UTC, Adam D. Ruppe wrote:
On Tuesday, 5 April 2016 at 14:45:33 UTC, ZombineDev wrote:
Yeah, that's what I had in mind. new Object{}, int(3) ->
int{3}, T() -> T{} (in generic code), and {42, "tuple"} where
the type can be deduced.
Unfortunately the (1, 2, 3) syntax is can't be used for tuples
because it is ambiguous/looks bad in some
If it is supposed to be uniform, why have the type name in one
place but not another?
I really don't understand what the problem with
Whatever!(x,y,z) is.
(other than the fact that Tuple sucks. structs are better in
every way. but it isn't because of syntax.)
I still don't understand what's not uniform. In most cases you
would want to use the curly braces without the type:
auto {a, b} tuple = { add( {1, 2, 3}, {4, 5, 6} ), {7, 8, 9} };
assert (tuple == {{5, 7, 9}, {7, 8, 9}});
assert (a == {5, 7, 9} && b == {7, 8, 9});
// pattern-matching (note: no `static` in front)
if (is(a : {5, y, 9}))
{
writefln("The tuple is: {5, %s, 9}", y);
// The `y` identifier is valid until the end of the statement.
}
auto {x, y, z} = tuple[0];
assert (x == 5 && y == 7 && z == 9);
struct Point { double x, y, z; }
Point3 add(Point3 {ax, ay, az} a, Point3 {bx, by, bz} b)
{ return { ax + bx, ay + by, az + bz };
However in some places this is ambiguous:
struct S1 { float x, y, z; }
struct S2 { int x, y, z; }
struct S3 { int a, b, c;}
void foo(S1);
void foo(S2);
void foo(S3); // foo is overloaded
foo({a: 1, b: 2, c: 3}); // unambiguous
foo({x: 1, y: 2, z: 3}); // error: the function call is ambiguous:
// both foo(S1) and foo(S2) are callable with `{x:1, y:2, z:3}`.
// Prefix the tuple with a type to disambiguate.
foo(S1{x: 1, y: 2, z: 3}); // both
foo(S2{x: 1, y: 2, z: 3}); // are unambiguous.
Re: uniform initialization in D (as in C++11): i{...}
On Monday, April 04, 2016 22:39:25 Timothee Cour via Digitalmars-d wrote:
> what's D's answer for C++11's uniform initialization [1] which allows DRY
> code?
>
> Could we have this:
>
> struct A{
> int a;
> int b;
> }
>
> A fun(A a, int b) {
> if(b==1) return i{0,1};
> else if(b==2) return i{2,3};
> else return fun(i{3,4}, 1);
> }
>
So, the whole point of this is to be able to construct the return value
without typing the type name explicitly? typeof(return) already does this.
So, this doesn't seem like it would be solving anything new, just making it
less verbose.
In general though, construction is one of those things that tends to not be
generic, so it frequently doesn't work to just swap out one type for another
when construction is involved, and construction frequently doesn't work very
well in templated code. When it does, the construction syntax is already
pretty generic, such that I don't see much need to add anythnig for it. We
just don't have anything specific for containers, but you're not going to
swap construction of a scalar value for a container, and if the containers
all took variadic lists of arguments and/or ranges, then swapping the
construction of one container to another would tend to work.
I really don't see a problem here that needs solving.
- Jonathan M Davis
Re: proposed syntax for tuple: t{} and TypeTuple: T{} (cf precedent of q{...})
On Tuesday, 5 April 2016 at 15:29:06 UTC, ZombineDev wrote:
Action action = {}; // error: `{}` is an empty tuple, can't be
assigned to delegates
auto t = {}; // deduced as an empty tuple.
Also, the non-empty {} syntax can't be mistaken for a function
literal because non-empty function literals always have at
least one statement that ends with a semicolon.
Is making this
Action action = {};
an error a breaking change? It currently compiles without error
and I can get the typeof(action) as void delegate(), though I
can't really do much of anything with it. Similarly for empty
function literals.
Re: proposed syntax for tuple: t{} and TypeTuple: T{} (cf precedent of q{...})
On Tuesday, 5 April 2016 at 05:45:08 UTC, Timothee Cour wrote:
{} for tuples hasn't worked out since it was deemed ambiguous
with delegate syntax (was it for the case of empty
statements/tuple?).
How about the following syntax instead:
{} // delegate (existing syntax)
q{...} // string literal (existing syntax)
t{...} // tuple(a,b) (proposed syntax)
T{...} // TypeTuple!(a,b) (proposed syntax)
See also [1] where i propose i{...} for a D analog of C++11's
uniform initialization.
[1] EMAIL: uniform initialization in D (as in C++11): i{...}
Tuple and AliasSeq are library types, so the chance that they
will be added into the language is slim to none.
Re: proposed syntax for tuple: t{} and TypeTuple: T{} (cf precedent of q{...})
On Tuesday, 5 April 2016 at 16:56:15 UTC, Jack Stouffer wrote: Tuple and AliasSeq are library types, so the chance that they will be added into the language is slim to none. Yes on Tuple, but AliasSeq actually is in the language (just unnamed there, it is what you get with T... in a template argument list) and isn't actually a type at all. It is just a list of compile time names.
Re: proposed syntax for tuple: t{} and TypeTuple: T{} (cf precedent of q{...})
On Tuesday, 5 April 2016 at 16:34:49 UTC, jmh530 wrote:
On Tuesday, 5 April 2016 at 15:29:06 UTC, ZombineDev wrote:
Action action = {}; // error: `{}` is an empty tuple, can't be
assigned to delegates
auto t = {}; // deduced as an empty tuple.
Also, the non-empty {} syntax can't be mistaken for a function
literal because non-empty function literals always have at
least one statement that ends with a semicolon.
Is making this
Action action = {};
an error a breaking change? It currently compiles without error
and I can get the typeof(action) as void delegate(), though I
can't really do much of anything with it. Similarly for empty
function literals.
Yes, I think it would be a breaking change, if my proposal is
accepted.
Re: uniform initialization in D (as in C++11): i{...}
On 05.04.2016 07:39, Timothee Cour via Digitalmars-d wrote:
what's D's answer for C++11's uniform initialization [1] which allows DRY code?
If it's just about DRY, D is in quite good shape.
A fun(A a, int b) {
alias i=typeof(return);
if(b==1) return i(0,1);
else if(b==2) return i(2,3);
else return fun(i(3,4), 1);
}
Could we have this:
struct A{
int a;
int b;
}
A fun(A a, int b) {
if(b==1) return i{0,1};
else if(b==2) return i{2,3};
else return fun(i{3,4}, 1);
}
As for which syntax to use, that's an orthogonal question, but here I
used i{} since {} (from C++11) is already used by delegates (with
tuples also being discussed at some point, which didn't pan out bc
someone mentioned it was ambiguous in some case; see my next email
proposal below though [2])
{} // delegate (existing syntax)
q{...} // comment (existing syntax)
i{...} // uniform intialization (proposed syntax)
t{...} // tuple(a,b) (proposed syntax)
T{...} // TypeTuple!(a,b) (proposed syntax)
[1]
http://programmers.stackexchange.com/questions/133688/is-c11-uniform-initialization-a-replacement-for-the-old-style-syntax
[2] EMAIL:proposed syntax for tuple: t{} and TypeTuple: T{}
Well, the following is allowed:
struct A{
int a;
int b;
}
void main(){
A x={1,2};
A y={b:2,a:1};
assert(x==y);
}
It would be funny if the syntax for such literals was different in
initialization position and in other places. (Even more strange than the
fact that now, the expression syntax for initialization differs from the
usual expression syntax. {} is not always a delegate literal. E.g. auto
x={}; actually fails to compile.)
Re: uniform initialization in D (as in C++11): i{...}
On 05.04.2016 21:24, Timon Gehr wrote: On 05.04.2016 07:39, Timothee Cour via Digitalmars-d wrote: what's D's answer for C++11's uniform initialization [1] which allows DRY code? If it's just about DRY... NVM, I see those points have been brought up already (the thread was split into two).
Re: proposed syntax for tuple: t{} and TypeTuple: T{} (cf precedent of q{...})
On 05.04.2016 17:29, ZombineDev wrote:
On Tuesday, 5 April 2016 at 05:45:08 UTC, Timothee Cour wrote:
{} for tuples hasn't worked out since it was deemed ambiguous with
delegate syntax (was it for the case of empty statements/tuple?).
How about the following syntax instead:
{} // delegate (existing syntax)
q{...} // string literal (existing syntax)
t{...} // tuple(a,b) (proposed syntax)
T{...} // TypeTuple!(a,b) (proposed syntax)
See also [1] where i propose i{...} for a D analog of C++11's uniform
initialization.
[1] EMAIL: uniform initialization in D (as in C++11): i{...}
I don't think that t or T is needed in front of {}.
1) Function literals / lambdas / delegates:
If someone wants an empty function literal, they just have to use (){}
instead of {}:
alias Action = void delegate();
Action action = (){}; // instead of
Action action = {}; // error: `{}` is an empty tuple, can't be assigned
to delegates
(This specific case would actually be unproblematic. {} can be polysemous.)
auto t = {}; // deduced as an empty tuple.
Also, the non-empty {} syntax can't be mistaken for a function literal
because non-empty function literals always have at least one statement
that ends with a semicolon.
2) Tuples and AliasSeq-s.
Correct me if I'm wrong, but I think that in all cases the expression is
unambiguous:
auto t1 = {3, 4}; // Tuple
enum t2 = {3, 4}; // Tuple
alias t3 = {3, 4}; // AliasSeq
...
This is moot.
template T(alias a,alias b){}
template T(alias a){}
T!({1,2}) // <- ?
Note that template alias parameters can accept values. (Other alias
declarations can too, possibly depending on how you look at it; the
language grammar is a little warty there.)
I don't think there should be separate syntax for 'AliasSeq' especially
if it resembles tuple syntax. (The design is already confusing enough,
for no gain.)
void foo(Tuple!(int, int) x);
foo({3, 4}); // same as foo(t1), or foo(t2)
template staticMap(alias F, T...);
alias constTypes = staticMap!( constOf, { int, float, void[] } );
static assert (is( constTypes == { const(int), const(float),
const(void[]) } );
writefln!({int, string, double})("%s %s %s", {3, "test", 4.2});
That highlights another flaw in AliasSeq. This should do the trick, but
does not:
alias constTypes = const(AliasSeq!(int,float,void[]));
pragma(msg, constTypes); // (int, float, void[]) // wat?
This means that
auto a=...;
const b=a;
is not always the same as
auto a=...;
const(typeof(a)) b=a;
Re: proposed syntax for tuple: t{} and TypeTuple: T{} (cf precedent of q{...})
On Tuesday, 5 April 2016 at 20:13:59 UTC, Timon Gehr wrote:
On 05.04.2016 17:29, ZombineDev wrote:
On Tuesday, 5 April 2016 at 05:45:08 UTC, Timothee Cour wrote:
{} for tuples hasn't worked out since it was deemed ambiguous
with
delegate syntax (was it for the case of empty
statements/tuple?).
How about the following syntax instead:
{} // delegate (existing syntax)
q{...} // string literal (existing syntax)
t{...} // tuple(a,b) (proposed syntax)
T{...} // TypeTuple!(a,b) (proposed syntax)
See also [1] where i propose i{...} for a D analog of C++11's
uniform
initialization.
[1] EMAIL: uniform initialization in D (as in C++11): i{...}
I don't think that t or T is needed in front of {}.
1) Function literals / lambdas / delegates:
If someone wants an empty function literal, they just have to
use (){}
instead of {}:
alias Action = void delegate();
Action action = (){}; // instead of
Action action = {}; // error: `{}` is an empty tuple, can't be
assigned
to delegates
(This specific case would actually be unproblematic. {} can be
polysemous.)
auto t = {}; // deduced as an empty tuple.
Also, the non-empty {} syntax can't be mistaken for a function
literal
because non-empty function literals always have at least one
statement
that ends with a semicolon.
2) Tuples and AliasSeq-s.
Correct me if I'm wrong, but I think that in all cases the
expression is
unambiguous:
auto t1 = {3, 4}; // Tuple
enum t2 = {3, 4}; // Tuple
alias t3 = {3, 4}; // AliasSeq
...
This is moot.
template T(alias a,alias b){}
template T(alias a){}
T!({1,2}) // <- ?
The answer to this question and all similar cases is that is that
{1,2} is rewritten to AliasSeq!(1, 2). In this particular case it
auto-expands and calls the T template with two alias parameters.
Note that template alias parameters can accept values. (Other
alias declarations can too, possibly depending on how you look
at it; the language grammar is a little warty there.)
Yes I know. And I see no problem with this.
template K(alias fun, alias var, size_t idx, string str, T, Y...)
int local = 42;
K!(AliasSeq!(x => x * 2, local, 1 + 5, "asd", int, float,
double));
K!({ x => x * 2, local, 1 + 5, "asd", int, float, double });
// also the same as:
K!(x => x * 2, local, 1 + 5, { "asd", int, {float, double} });
I don't think there should be separate syntax for 'AliasSeq'
especially if it resembles tuple syntax. (The design is already
confusing enough, for no gain.)
Well it would be a pretty big whole in the language if you could
do tuple, but not alias sequences. Also it's nice to do:
{float, float} scale({float, float} vec, float x)
{
return vec * x;
}
void foo(Tuple!(int, int) x);
foo({3, 4}); // same as foo(t1), or foo(t2)
template staticMap(alias F, T...);
alias constTypes = staticMap!( constOf, { int, float, void[]
} );
static assert (is( constTypes == { const(int), const(float),
const(void[]) } );
writefln!({int, string, double})("%s %s %s", {3, "test", 4.2});
That highlights another flaw in AliasSeq. This should do the
trick, but does not:
alias constTypes = const(AliasSeq!(int,float,void[]));
pragma(msg, constTypes); // (int, float, void[]) // wat?
This means that
auto a=...;
const b=a;
is not always the same as
auto a=...;
const(typeof(a)) b=a;
Yeah this looks like a bug in the current implementation. I also
find the following limitation unfortunate:
struct Point3 { int x, y, z; }
Point3 a, b, c;
c = a.tupleof + b.tupleof; // doesn't work :(
Re: Any usable SIMD implementation?
On 4/5/2016 4:07 AM, 9il wrote: On Tuesday, 5 April 2016 at 10:30:19 UTC, Walter Bright wrote: On 4/5/2016 2:39 AM, 9il wrote: On Tuesday, 5 April 2016 at 08:34:32 UTC, Walter Bright wrote: 1. This would help to eliminate configuration bugs. 2. This would reduce work for users and simplified user experience. 3. This is possible and not very hard to implement if I am not wrong. Where does the compiler get the information that it should compile for, say, AFX? No idea about AFX. Do you choose AFX to disallow me to find an example? I want to make it clear that dmd does not generate AFX specific code, has no switch to enable AFX code generation and has no basis for setting predefined version identifiers for it.
Re: So... let's document dmd
On 4/5/2016 6:47 AM, Basile B. wrote: Also lexing number doesn't need to be as accurate as the front-end of the compiler (especially if the HL doesnt have a token type for the illegal "lexem". That is an interesting design point. If I was doing a highlighter, I'd highlight in red tokens that the compiler would reject, meaning I'd do the accurate number lexing. Lexing numbers correctly is not trivial, but since the compiler lexer's implementation can be cut/pasted, it is trivial in practice.
Re: So... let's document dmd
On 4/5/2016 4:34 AM, Jacob Carlborg wrote: I agree very much with this. Unfortunately many (most?) editors use their own weird syntax to describe grammars for syntax highlighting and cannot use a proper lexer/parser. Haha, MicroEmacs is written in D, so just use D code :-) I don't really understand why IDE makers don't use an actual programming language for plugins - I'd use javascript as there's a D implementation of a javascript engine you can use. (Using D as a plugin language would require making DLLs which is a pain or making a D interpreter, which would be a major project (CTFE in theory should work for that, but it consumes too much memory).)
Re: Any usable SIMD implementation?
On Tuesday, 5 April 2016 at 21:29:41 UTC, Walter Bright wrote:
I want to make it clear that dmd does not generate AFX specific
code, has no switch to enable AFX code generation and has no
basis for setting predefined version identifiers for it.
How about adding a "__target(...)" compile-time function, that
would return false if the compiler doesn't know?
__target("broadwell") --> true means: target cpu is broadwell,
false means compiler doesn't know or target cpu is not broadwell.
Would that work for all?
non-utf8-decoding regex (for speed)?
Is there a way to avoid decoding (as utf8) when calling regex' apis? or a plan to do so? use case: speed (no decoding) and avoiding throwing on invalid utf8 sequences ideally this should allow: --- auto s = cast(ubyte[]) "abcd"; //potentially not valid utf8 sequence auto r = cast(ubyte[]) `^\d`; auto m=match(s, r.regex); // right now: regex cannot deduce function from argument types !()(ubyte[]) ---
Re: proposed syntax for tuple: t{} and TypeTuple: T{} (cf precedent of q{...})
On 05.04.2016 22:48, ZombineDev wrote:
On Tuesday, 5 April 2016 at 20:13:59 UTC, Timon Gehr wrote:
On 05.04.2016 17:29, ZombineDev wrote:
On Tuesday, 5 April 2016 at 05:45:08 UTC, Timothee Cour wrote:
{} for tuples hasn't worked out since it was deemed ambiguous with
delegate syntax (was it for the case of empty statements/tuple?).
How about the following syntax instead:
{} // delegate (existing syntax)
q{...} // string literal (existing syntax)
t{...} // tuple(a,b) (proposed syntax)
T{...} // TypeTuple!(a,b) (proposed syntax)
See also [1] where i propose i{...} for a D analog of C++11's uniform
initialization.
[1] EMAIL: uniform initialization in D (as in C++11): i{...}
I don't think that t or T is needed in front of {}.
1) Function literals / lambdas / delegates:
If someone wants an empty function literal, they just have to use (){}
instead of {}:
alias Action = void delegate();
Action action = (){}; // instead of
Action action = {}; // error: `{}` is an empty tuple, can't be assigned
to delegates
(This specific case would actually be unproblematic. {} can be
polysemous.)
auto t = {}; // deduced as an empty tuple.
Also, the non-empty {} syntax can't be mistaken for a function literal
because non-empty function literals always have at least one statement
that ends with a semicolon.
2) Tuples and AliasSeq-s.
Correct me if I'm wrong, but I think that in all cases the expression is
unambiguous:
auto t1 = {3, 4}; // Tuple
enum t2 = {3, 4}; // Tuple
alias t3 = {3, 4}; // AliasSeq
...
This is moot.
template T(alias a,alias b){}
template T(alias a){}
T!({1,2}) // <- ?
The answer to this question and all similar cases is that is that
{1,2} is rewritten to AliasSeq!(1, 2). In this particular case it
auto-expands and calls the T template with two alias parameters.
Note that template alias parameters can accept values. (Other alias
declarations can too, possibly depending on how you look at it; the
language grammar is a little warty there.)
Yes I know. And I see no problem with this.
...
There might have been some underlying misunderstanding here.
My guess is that you want the new built-in tuple syntax to be lowered to
expression sequences? (I don't.)
template K(alias fun, alias var, size_t idx, string str, T, Y...)
int local = 42;
K!(AliasSeq!(x => x * 2, local, 1 + 5, "asd", int, float, double));
K!({ x => x * 2, local, 1 + 5, "asd", int, float, double });
// also the same as:
K!(x => x * 2, local, 1 + 5, { "asd", int, {float, double} });
I don't think there should be separate syntax for 'AliasSeq'
especially if it resembles tuple syntax. (The design is already
confusing enough, for no gain.)
Well it would be a pretty big whole in the language if you could do
tuple, but not alias sequences. Also it's nice to do:
{float, float} scale({float, float} vec, float x)
{
return vec * x;
}
...
IMAO any design that tries to make wacky auto-expansion even more
prominent is not good enough. Auto-expansion should be a derived notion
at best. (I.e. there are tuples that are actually tuples, and then they
might have an .expand property.)
(Also, note that multiple return values are explicitly ruled out at the
moment.)
void foo(Tuple!(int, int) x);
foo({3, 4}); // same as foo(t1), or foo(t2)
template staticMap(alias F, T...);
alias constTypes = staticMap!( constOf, { int, float, void[] } );
static assert (is( constTypes == { const(int), const(float),
const(void[]) } );
writefln!({int, string, double})("%s %s %s", {3, "test", 4.2});
That highlights another flaw in AliasSeq. This should do the trick,
but does not:
alias constTypes = const(AliasSeq!(int,float,void[]));
pragma(msg, constTypes); // (int, float, void[]) // wat?
This means that
auto a=...;
const b=a;
is not always the same as
auto a=...;
const(typeof(a)) b=a;
Yeah this looks like a bug in the current implementation.
Hopefully. Hard to tell. Walter?
I also find
the following limitation unfortunate:
struct Point3 { int x, y, z; }
Point3 a, b, c;
c = a.tupleof + b.tupleof; // doesn't work :(
There are many, way more arbitrary, limitations. E.g. auto-expansion
does not work in case labels, expression sequences cannot be operands of
the comma operator and ternary operator and they cannot be returned from
functions.
The main reason why AliasSeq is hard to evolve is that it is basically
fubar'd. I don't know if you know about this:
alias Seq(T...)=T;
void main(){
int x=0;
Seq!(int,int) y = ++x;
assert(y[0]==1 && y[1]==2);
}
Unless breaking changes are allowed, any design that builds on AliasSeq
will be... funny.
Re: So... let's document dmd
On 05.04.2016 10:46, Walter Bright wrote: On 1/16/2016 7:13 AM, H. S. Teoh via Digitalmars-d wrote: I disagree. I think having the dmd itself (lexer, parser, etc.) as a library (with the dmd executable merely being the default frontend) will do D a lot of good. For one thing, IDE's will no longer need to reinvent a D parser for the purposes of syntax highlighting; On the other hand, using lexer.d and parse.d as a guide to build your own is a trivial undertaking. The Boost license is designed so this can be done without worrying about making a derived work. I looked into doing syntax highlighting for my editor, MicroEmacs. It turns out it is not so easy to just use a compiler lexer/parser for it. For one thing, the one used in the compiler is optimized for speed in a forward pass through the text. But a syntax highlighter in a text editor is different. Suppose I change a character in the middle of a line. All the highlighting from that point forward may change. And to figure out what that change is, the parser/lexer has to start over from the beginning of the file! (Think string literals, nested comments, quoted string literals, etc.) This would make editing slow. ... Also, tools might want to parse a more intuitive grammar in order to be able to give suggestions on how to adapt the code such that DMDs parser will accept it. I surmised that a solution is to have each line in the editor be tagged with a state to show the lexing state at the beginning of that line. Then, when a character in a line changes, the lexer can be restarted from that state, and it continues forward until the next line state matches the new computed state. This would make it enormously faster. ... Some additional care will need to be taken, e.g. /+ or even simply /+ comment +/ But the compiler's lexer is not designed to be restartable in the middle. Similarly, a source code formatter would be different in a different way. It would need, for example, extra information about comments, token start/end positions, etc. Such data collection would be irrelevant to a compiler, and would slow it down and consume unneeded memory.
Re: Any usable SIMD implementation?
On 4/5/2016 4:17 AM, 9il wrote: What wrong for scientist to write `-mcpu=native`? Because it would affect all the code in the module and every template it imports, which is a problem if you are using 'static if' and want to compile different pieces with different settings.
Re: non-utf8-decoding regex (for speed)?
On Tuesday, April 05, 2016 15:00:36 Timothee Cour via Digitalmars-d wrote: > Is there a way to avoid decoding (as utf8) when calling regex' apis? > or a plan to do so? > > use case: speed (no decoding) and avoiding throwing on invalid utf8 > sequences > > ideally this should allow: > > --- > auto s = cast(ubyte[]) "abcd"; //potentially not valid utf8 sequence > auto r = cast(ubyte[]) `^\d`; > auto m=match(s, r.regex); // right now: regex cannot deduce function > from argument types !()(ubyte[]) > --- As a side note, you can use std.string.representation to convert a string to an array of ubyte with the correct constness. There's also std.utf.byCodeUnit. But it wouldn't surprise me at all of std.regex didn't really support either of those approaches at this point. I'm not very familiar with std.regex though. - Jonathan M Davis
Re: So... let's document dmd
On Tuesday, 5 April 2016 at 21:37:09 UTC, Walter Bright wrote: On 4/5/2016 6:47 AM, Basile B. wrote: Also lexing number doesn't need to be as accurate as the front-end of the compiler (especially if the HL doesnt have a token type for the illegal "lexem". That is an interesting design point. If I was doing a highlighter, I'd highlight in red tokens that the compiler would reject, meaning I'd do the accurate number lexing. Lexing numbers correctly is not trivial, but since the compiler lexer's implementation can be cut/pasted, it is trivial in practice. Even if when the most naive lexer see a number and consumes until a blank, a symbol or an operator, it's clear that this can be done: http://i.imgur.com/ehjps04.png Actually numbers is the only part of the D lexer where errors can be detected. There's no possible syntax errors otherwise. But one thing I forget to say in my previous post is that lexing can be "multi-pass". The D front-end does everything in a single pass, for example it direclty detects tokPlusPlus or tokXorEqu, but actually a multi pass lexer can work in 3 sub phases: 1/ split words 2/ detects token families in the words; identifier, keyword, operator, etc. 3/ specialize tokens: tokOp.data == "++" -> tokPlusPlus
Re: So... let's document dmd
On 4/5/2016 7:59 PM, Basile B. wrote: Actually numbers is the only part of the D lexer where errors can be detected. There's no possible syntax errors otherwise. D's lexer.d detects many errors. Search lexer.d for "error".
Re: So... let's document dmd
On 4/5/2016 4:08 PM, Timon Gehr wrote: Some additional care will need to be taken, e.g. /+ or even simply /+ comment +/ that should not be a problem.
Re: So... let's document dmd
On Tuesday, 5 April 2016 at 13:47:55 UTC, Basile B. wrote: [...] by 4 or 5 softwares. Believe or not, in 2012 I've registered a company with the same error (.softwares). I don't know why...it hasnot been a commercial success.
Re: How my little brother try D
Jesse Phillips wrote: > Oh this was the other thing I was looking for: > > http://stackoverflow.com/a/23231073/34435 > > C#'s move doesn't work across network. That's wrong AFAIK. Tobi
Re: Any usable SIMD implementation?
On Wednesday, 6 April 2016 at 00:45:54 UTC, Walter Bright wrote: On 4/5/2016 4:17 AM, 9il wrote: What wrong for scientist to write `-mcpu=native`? Because it would affect all the code in the module and every template it imports, which is a problem if you are using 'static if' and want to compile different pieces with different settings. 99.99% of them do not need to compile code with different settings. Furthermore 90% of them don't know what CPU their supercomputer has. They just want to have as fast code as possible without googling what CPU instructions are available for the CPU.
Re: Any usable SIMD implementation?
On Tuesday, 5 April 2016 at 21:29:41 UTC, Walter Bright wrote: On 4/5/2016 4:07 AM, 9il wrote: On Tuesday, 5 April 2016 at 10:30:19 UTC, Walter Bright wrote: On 4/5/2016 2:39 AM, 9il wrote: On Tuesday, 5 April 2016 at 08:34:32 UTC, Walter Bright wrote: 1. This would help to eliminate configuration bugs. 2. This would reduce work for users and simplified user experience. 3. This is possible and not very hard to implement if I am not wrong. Where does the compiler get the information that it should compile for, say, AFX? No idea about AFX. Do you choose AFX to disallow me to find an example? I want to make it clear that dmd does not generate AFX specific code, has no switch to enable AFX code generation and has no basis for setting predefined version identifiers for it. Please think that D has other compilers, not only DMD. We need a language feature, and I am ok that this feature would be useless for DMD. But the fact that DMD can not optimize code for, say, AVX, AVX2, AVX-512, FMA4, ..., is not good reason to reject small language changes that would be very helpful for D for community. Yes, only few of us would use this feature directly, however, many of us would use this under-the-hood in BLAS/SIMD oriented part of Phobos.
Re: Any usable SIMD implementation?
On Tuesday, 5 April 2016 at 21:41:46 UTC, Johan Engelen wrote:
On Tuesday, 5 April 2016 at 21:29:41 UTC, Walter Bright wrote:
I want to make it clear that dmd does not generate AFX
specific code, has no switch to enable AFX code generation and
has no basis for setting predefined version identifiers for it.
How about adding a "__target(...)" compile-time function, that
would return false if the compiler doesn't know?
__target("broadwell") --> true means: target cpu is broadwell,
false means compiler doesn't know or target cpu is not
broadwell.
Would that work for all?
Yes, something like that is what I am looking for.
Two nitpicks:
1. __target("broadwell") is not well API. Something like that
would be more efficient:
enum target = __target();
// .. use target
2. Is it possible to reflect additional settings about
instruction set? Maybe "broadwell,-avx"?
