Re: GtkD Blog Now Up and Running
On Thursday, 31 January 2019 at 20:33:43 UTC, Ron Tarrant wrote: On Wednesday, 30 January 2019 at 21:21:24 UTC, Mike Wey wrote: This is whats going on: https://issues.dlang.org/show_bug.cgi?id=15418 To work around this you can either build things with "--arch=x86mscoff" or tell dub not to build the debug version with "--build=plain". Ah! Thanks, Mike. Does the lack of an answer to the last question there mean that this is an on-going issue? The issue is unrelated to dub. It only has to do with object format and linker that dmd uses on Windows by default. This issue is perhaps the reason why you had to use the -m64 dmd flag in your first post. If you don't specify the target arch on Windows - the -mXX flag for dmd, or the --arch=YYY flag for dub - the default is going to be -m32 and --arch=x86 respectively. So, assuming you have the MSVC C++ toolchain installed, just build with dub by specifying either the --arch=x86_mscoff or --arch=x86_64 flags. But no one should ever need to modify their dmd installation, in order to use gtkd.
GSOC 2019 Mentors Needed
A couple of people have put their names forward as potential mentors for GSOC 2019, but I need more! If you are interested in participating, please let me know. Doing so does not guarantee that you will be a part of the event, but we need a large enough pool that when students begin submitting their applications we can have a better chance of matching them up with the mentor who’s a best fit for their project. Also a reminder — the Wiki page of potential projects for GSOC is still rather light. Please don’t make me have to spend time digging through old ideas to see what’s still valid. If you an idea for a project that is suitable for GSOC, something you’d love to work on but don’t have the time for perhaps, then please add it to the ideas page! Let’s get it fleshed out so potential applicants can have more time to consider what they’d like to work on. The deadline for organizations to apply is Feb 6. We should hear on Feb 27 if we’re accepted or not. If we are, then students will have until April 9 to submit their applications. It will go by fast, so the sooner we get more ideas on the page the better. https://wiki.dlang.org/GSOC_2019_Ideas
Re: Hunt framework 2.0.0 released
On Tuesday, 29 January 2019 at 10:41:48 UTC, Dejan Lekic wrote: On Tuesday, 29 January 2019 at 10:00:22 UTC, zoujiaqing wrote: The HuntLabs team is happy to announce the release of Hunt Framework 2.0. Looks impressive. I like the fact that VibeD has some competition - it is healthy that way. Good job guys! We will provide usage examples in the next two weeks :)
Re: DIP 1016--ref T accepts r-values--Formal Assessment
On Thursday, 31 January 2019 at 22:35:26 UTC, H. S. Teoh wrote:
On Thu, Jan 31, 2019 at 10:26:39PM +, jmh530 via
Digitalmars-d-announce wrote:
On Thursday, 31 January 2019 at 21:57:21 UTC, Steven
Schveighoffer wrote:
[...]
> That being said, you can look at the fact that most people
> don't even know about this problem, even seasoned veterans,
> as a sign that it's really not a big problem.
>
The way you put it makes it sound like a bug...
I don't know if it helps, but below compiles without error.
struct Foo
{
private int _x;
int* x() { return &_x; }
}
struct Bar
{
private Foo _y;
Foo* y() { return &_y; }
void y(Foo foo) { _y = foo; }
}
void main() {
Foo a = Foo(1);
assert(*a.x == 1);
*a.x *= 2;
assert(*a.x == 2);
Bar b;
b.y = Foo(1);
assert(*b.y.x == 1);
*b.y.x *= 2;
assert(*b.y.x == 2);
}
Why is it a problem that this code compiles without error?
T
Sorry if I didn't really complete my thought.
The code below corresponds to the ref version mentioned above and
gets the same error originally reported. The only difference is
that I use Foo instead of Foo* for the getter in Bar. So if you
instead make that member function a ref function, then it also
compiles without error (regardless of if you use the
doubleMyValue function or not).
So they were right that the issue is with the getter. However,
you're not really protected in any way if you have a ref getter
at one point in a chain and a non-ref getter somewhere else.
Making all the getters auto ref also avoids the issue.
struct Foo
{
private int _x;
ref int x() { return _x; }
}
struct Bar
{
private Foo _y;
Foo y() { return _y; }
void y(Foo foo) { _y = foo; }
}
void main() {
Foo a = Foo(1);
assert(a.x == 1);
a.x *= 2;
assert(a.x == 2);
Bar b;
b.y = Foo(1);
assert(b.y.x == 1);
b.y.x *= 2;
assert(b.y.x == 2);
}
Re: DIP 1016--ref T accepts r-values--Formal Assessment
On Thursday, 31 January 2019 at 22:00:10 UTC, Walter Bright wrote:
On 1/31/2019 1:46 PM, Andrei Alexandrescu wrote:
The proposal could actually disallow rvalues that have lvalue
syntax, such as "symbol", "symbol[expr]", "symbol.symbol",
"symbol.symbol[expr]", etc. Ugh. Gets hairy quickly.
That's why it's problematic to have a rule that rvalues can be
implicitly converted, but not lvalues. There's not a hard line
between lvalues and rvalues. For example,
foreach(i; 0..2)
{
int[] a = [1, 2];
assert(a[0] == 1]);
a[0] = 3; // will this cause the assert to fail?
}
Why would it cause the assert to fail? A new array is constructed
each loop.
Re: DIP 1016--ref T accepts r-values--Formal Assessment
On Thu, Jan 31, 2019 at 10:26:39PM +, jmh530 via Digitalmars-d-announce
wrote:
> On Thursday, 31 January 2019 at 21:57:21 UTC, Steven Schveighoffer wrote:
[...]
> > That being said, you can look at the fact that most people don't
> > even know about this problem, even seasoned veterans, as a sign that
> > it's really not a big problem.
> >
>
> The way you put it makes it sound like a bug...
>
> I don't know if it helps, but below compiles without error.
>
> struct Foo
> {
>private int _x;
>int* x() { return &_x; }
> }
>
> struct Bar
> {
>private Foo _y;
>Foo* y() { return &_y; }
>void y(Foo foo) { _y = foo; }
> }
>
> void main() {
> Foo a = Foo(1);
> assert(*a.x == 1);
> *a.x *= 2;
> assert(*a.x == 2);
>
> Bar b;
> b.y = Foo(1);
> assert(*b.y.x == 1);
> *b.y.x *= 2;
> assert(*b.y.x == 2);
> }
Why is it a problem that this code compiles without error?
T
--
Perhaps the most widespread illusion is that if we were in power we would
behave very differently from those who now hold it---when, in truth, in order
to get power we would have to become very much like them. -- Unknown
Re: DIP 1016--ref T accepts r-values--Formal Assessment
On Thursday, 31 January 2019 at 21:57:21 UTC, Steven
Schveighoffer wrote:
[snip]
That being said, you can look at the fact that most people
don't even know about this problem, even seasoned veterans, as
a sign that it's really not a big problem.
The way you put it makes it sound like a bug...
I don't know if it helps, but below compiles without error.
struct Foo
{
private int _x;
int* x() { return &_x; }
}
struct Bar
{
private Foo _y;
Foo* y() { return &_y; }
void y(Foo foo) { _y = foo; }
}
void main() {
Foo a = Foo(1);
assert(*a.x == 1);
*a.x *= 2;
assert(*a.x == 2);
Bar b;
b.y = Foo(1);
assert(*b.y.x == 1);
*b.y.x *= 2;
assert(*b.y.x == 2);
}
Re: DIP 1016--ref T accepts r-values--Formal Assessment
On Thursday, 31 January 2019 at 21:50:19 UTC, Olivier FAURE wrote: On Thursday, 31 January 2019 at 21:44:53 UTC, jmh530 wrote: It doesn't compile with dip1000 without first giving the getter functions a return attribute for this. But it still compiles with -dip1000 once you give x() and y() return attributes, even though what's happening is clearly different from what the user wants (and the compiler has enough info to know that). Agreed. I had checked that it didn't work and as I figured out how to get it work I got distracted reading the documentation and return and scope.
Re: DIP 1016--ref T accepts r-values--Formal Assessment
On 1/31/19 4:46 PM, Andrei Alexandrescu wrote: On 1/31/19 4:42 PM, Olivier FAURE wrote: On Thursday, 31 January 2019 at 16:38:42 UTC, Steven Schveighoffer wrote: Yeah, that's already a thing that ref in D doesn't protect against: It took me a while to understand what the compiler was doing. This really feels like something that shouldn't compile. The proposal could actually disallow rvalues that have lvalue syntax, such as "symbol", "symbol[expr]", "symbol.symbol", "symbol.symbol[expr]", etc. Ugh. Gets hairy quickly. No, because those calls might actually do something with side effects! rvalues can contain other references. The only way to fix this would be to overload member functions on the lvalue-ness of `this`. I don't recommend this at all, as I see this as a weird but rare problem that doesn't affect most D code. -Steve
Re: DIP 1016--ref T accepts r-values--Formal Assessment
On 1/31/2019 1:46 PM, Andrei Alexandrescu wrote:
The proposal could actually disallow rvalues that have lvalue syntax, such as
"symbol", "symbol[expr]", "symbol.symbol", "symbol.symbol[expr]", etc. Ugh. Gets
hairy quickly.
That's why it's problematic to have a rule that rvalues can be implicitly
converted, but not lvalues. There's not a hard line between lvalues and rvalues.
For example,
foreach(i; 0..2)
{
int[] a = [1, 2];
assert(a[0] == 1]);
a[0] = 3; // will this cause the assert to fail?
}
Re: DIP 1016--ref T accepts r-values--Formal Assessment
On 1/31/19 4:42 PM, Olivier FAURE wrote: On Thursday, 31 January 2019 at 16:38:42 UTC, Steven Schveighoffer wrote: Yeah, that's already a thing that ref in D doesn't protect against: It took me a while to understand what the compiler was doing. This really feels like something that shouldn't compile. The problem is that `this` is passed by reference EVEN for rvalues. Knowing this, you can construct difficult situations, but normally these don't appear in the wild. If you've ever tried to make a simple math wrapper type, you would see how this is weird. And it has been like this since the beginning of D2. You get things like: a + Foo(1); // error Foo(1) + a; // OK! That being said, you can look at the fact that most people don't even know about this problem, even seasoned veterans, as a sign that it's really not a big problem. -Steve
Re: DIP 1016--ref T accepts r-values--Formal Assessment
On Thursday, 31 January 2019 at 21:44:53 UTC, jmh530 wrote: It doesn't compile with dip1000 without first giving the getter functions a return attribute for this. But it still compiles with -dip1000 once you give x() and y() return attributes, even though what's happening is clearly different from what the user wants (and the compiler has enough info to know that).
Re: DIP 1016--ref T accepts r-values--Formal Assessment
On 1/31/19 4:46 PM, Olivier FAURE wrote:
On Thursday, 31 January 2019 at 18:31:22 UTC, Steven Schveighoffer wrote:
BTW, the DIP discusses how to annotate these rare situations:
int doubleMyValue(ref int x) { ... }
@disable int doubleMyValue(int x);
I don't think that's a solution. The problem is in the getter method,
not in doubleMyValue. If nothing else, since the DIP is designed to work
on existing functions, it could happen on doubleMyValue functions which
would be both designed by and used by people completely unaware of
DIP-1016.
How is the problem not in doubleMyValue? It's sole purpose is to update
an lvalue. It is the perfect candidate to mark with @disable for rvalues.
-Steve
Re: DIP 1016--ref T accepts r-values--Formal Assessment
On 1/31/19 4:42 PM, Olivier FAURE wrote: On Thursday, 31 January 2019 at 16:38:42 UTC, Steven Schveighoffer wrote: Yeah, that's already a thing that ref in D doesn't protect against: It took me a while to understand what the compiler was doing. This really feels like something that shouldn't compile. The proposal could actually disallow rvalues that have lvalue syntax, such as "symbol", "symbol[expr]", "symbol.symbol", "symbol.symbol[expr]", etc. Ugh. Gets hairy quickly.
Re: DIP 1016--ref T accepts r-values--Formal Assessment
On Thursday, 31 January 2019 at 18:31:22 UTC, Steven
Schveighoffer wrote:
BTW, the DIP discusses how to annotate these rare situations:
int doubleMyValue(ref int x) { ... }
@disable int doubleMyValue(int x);
-Steve
I don't think that's a solution. The problem is in the getter
method, not in doubleMyValue. If nothing else, since the DIP is
designed to work on existing functions, it could happen on
doubleMyValue functions which would be both designed by and used
by people completely unaware of DIP-1016.
Re: DIP 1016--ref T accepts r-values--Formal Assessment
On Thursday, 31 January 2019 at 16:38:42 UTC, Steven Schveighoffer wrote: Yeah, that's already a thing that ref in D doesn't protect against: It took me a while to understand what the compiler was doing. This really feels like something that shouldn't compile.
Re: DIP 1016--ref T accepts r-values--Formal Assessment
On Thursday, 31 January 2019 at 21:42:04 UTC, Olivier FAURE wrote: [snip] It took me a while to understand what the compiler was doing. This really feels like something that shouldn't compile. It doesn't compile with dip1000 without first giving the getter functions a return attribute for this.
Re: DIP 1016--ref T accepts r-values--Formal Assessment
On 1/31/19 11:38 AM, Steven Schveighoffer wrote:
On 1/31/19 11:04 AM, Olivier FAURE wrote:
On Thursday, 31 January 2019 at 02:10:05 UTC, Manu wrote:
I still can't see a truck-sized hole.
I don't know if it's truck-sized, but here's another corner case:
int doubleMyValue(ref int x) {
x *= 2;
return x;
}
Point pt;
pt.x = 5;
pt.y = foobar();
doubleMyValue(pt.x);
assert(pt.x == 10);
Question: in the above code, will the assertion pass?
Answer: it depends on Point's implementation. If x is a member
variable, then yes. If it's a getter, then doubleMyValue will take a
rvalue and x won't be mutated and the assertion will fail.
I think this is a non-trivial conceptual problem.
Yeah, that's already a thing that ref in D doesn't protect against:
struct Point
{
private int _x, _y;
ref int x() { return _x; }
ref int y() { return _y; }
}
struct Rect
{
private Point _origin, _lengths;
Point origin() { return _origin; }
Point lengths() { return _lengths; }
void origin(Point p) { _origin = p; }
void lengths(Point p) { _lengths = p; }
}
Rect r;
r.origin = Point(1, 2);
r.lengths = Point(5, 5);
doubleMyValue(r.lengths.x);
assert(r.lengths.x == 10); // fail
-Steve
Affirmative. This discussion should be part of the revised DIP along
with an assessment of its gravity.
Goes the same with scope-level variables replaced with homonym functions
that return rvalues.
Andrei
Re: GtkD Blog Now Up and Running
On 31-01-2019 21:33, Ron Tarrant wrote: On Wednesday, 30 January 2019 at 21:21:24 UTC, Mike Wey wrote: This is whats going on: https://issues.dlang.org/show_bug.cgi?id=15418 To work around this you can either build things with "--arch=x86mscoff" or tell dub not to build the debug version with "--build=plain". Ah! Thanks, Mike. Does the lack of an answer to the last question there mean that this is an on-going issue? Yes, the issue is still open / on-going. -- Mike Wey
Re: GtkD Blog Now Up and Running
On Wednesday, 30 January 2019 at 21:21:24 UTC, Mike Wey wrote: This is whats going on: https://issues.dlang.org/show_bug.cgi?id=15418 To work around this you can either build things with "--arch=x86mscoff" or tell dub not to build the debug version with "--build=plain". Ah! Thanks, Mike. Does the lack of an answer to the last question there mean that this is an on-going issue?
Re: GtkD Blog Now Up and Running
On Wednesday, 30 January 2019 at 21:53:27 UTC, sanjayss wrote: Some simple screenshots would be nice to see I thought about it, but then realized that even though it would add visual appeal, readers might be more inclined to actually follow along at home if the only visual they get is the one they produce themselves. :) -- but good job on this. Nice to see examples/how-to's. Hope you keep going into complex topics. Thanks for the kind words, sanjayss. Yup, I'll be moving into complex subjects as things progress. I'm already working on a few behind the scenes, as it were. It seems I need lots of lead time to find a concept, outline it, write it, then rewrite it 1242 times so it's the best I can do. And like a good roast, it has to 'rest' for a while before I can see all the glaring faux pas and correct them... if you know what I mean. :) Thanks for reading.
Re: GtkD Blog Now Up and Running
On Wednesday, 30 January 2019 at 20:07:15 UTC, Jacob Carlborg wrote: It's Optlink being stupid as always. If you want to figure out what's wrong you can invoke Dub with the "--verbose" flag to have it print the commands it's running, i.e. how it's invoking the compiler and the linker. You can do the same thing when invoking the compiler manually by adding "-v" to see how it links the application and compare that with Dub. Or, you can try compiling as COFF instead of OMF which will not use Optlink. Add the flag "--arch=x86mscoff" when invoking Dub. I think I'll wait, but thanks for letting me know.
Hunt Console 0.1.0 released
Hunt Console library eases the creation of beautiful and testable
command line interfaces.
It is a port from Symfony's Console component. ( reference here
https://symfony.com/doc/current/console.html )
The Application object manages the command-line application:
import hunt.console;
console = new Application();
console.run(new ArgsInput(args));
The run() method parses the arguments and options passed on the
command line and executes the right command.
Registering a new command can easily be done via the register()
method, which returns a Command instance:
void main(string[] args)
{
Application app = new Application("Hunt Console", "1.0.0");
app.setAutoExit(false);
app.add(new GreetingCommand());
app.add((new Command("test")).setExecutor(new class
CommandExecutor {
override public int execute(Input input, Output output)
{
output.writeln("hello world");
return 0;
}
}));
if(args.length > 1)
app.run(args[1..$]);
else
app.run([]);
}
You can also register new commands via classes.
The component provides a lot of features like output coloring,
input and output abstractions (so that you can easily unit-test
your commands), validation, automatic help messages ...
Github repo:
https://github.com/huntlabs/hunt-console
HuntLabs website:
https://www.huntlabs.net/
Re: DIP 1016--ref T accepts r-values--Formal Assessment
On 1/31/19 11:04 AM, Olivier FAURE wrote:
On Thursday, 31 January 2019 at 02:10:05 UTC, Manu wrote:
I still can't see a truck-sized hole.
I don't know if it's truck-sized, but here's another corner case:
int doubleMyValue(ref int x) {
x *= 2;
return x;
}
Point pt;
pt.x = 5;
pt.y = foobar();
doubleMyValue(pt.x);
assert(pt.x == 10);
Question: in the above code, will the assertion pass?
Answer: it depends on Point's implementation. If x is a member variable,
then yes. If it's a getter, then doubleMyValue will take a rvalue and x
won't be mutated and the assertion will fail.
I think this is a non-trivial conceptual problem.
BTW, the DIP discusses how to annotate these rare situations:
int doubleMyValue(ref int x) { ... }
@disable int doubleMyValue(int x);
-Steve
Re: DIP 1016--ref T accepts r-values--Formal Assessment
On 1/31/19 11:04 AM, Olivier FAURE wrote:
On Thursday, 31 January 2019 at 02:10:05 UTC, Manu wrote:
I still can't see a truck-sized hole.
I don't know if it's truck-sized, but here's another corner case:
int doubleMyValue(ref int x) {
x *= 2;
return x;
}
Point pt;
pt.x = 5;
pt.y = foobar();
doubleMyValue(pt.x);
assert(pt.x == 10);
Question: in the above code, will the assertion pass?
Answer: it depends on Point's implementation. If x is a member variable,
then yes. If it's a getter, then doubleMyValue will take a rvalue and x
won't be mutated and the assertion will fail.
I think this is a non-trivial conceptual problem.
Yeah, that's already a thing that ref in D doesn't protect against:
struct Point
{
private int _x, _y;
ref int x() { return _x; }
ref int y() { return _y; }
}
struct Rect
{
private Point _origin, _lengths;
Point origin() { return _origin; }
Point lengths() { return _lengths; }
void origin(Point p) { _origin = p; }
void lengths(Point p) { _lengths = p; }
}
Rect r;
r.origin = Point(1, 2);
r.lengths = Point(5, 5);
doubleMyValue(r.lengths.x);
assert(r.lengths.x == 10); // fail
-Steve
Re: DIP 1016--ref T accepts r-values--Formal Assessment
On Thursday, 31 January 2019 at 02:10:05 UTC, Manu wrote:
I still can't see a truck-sized hole.
I don't know if it's truck-sized, but here's another corner case:
int doubleMyValue(ref int x) {
x *= 2;
return x;
}
Point pt;
pt.x = 5;
pt.y = foobar();
doubleMyValue(pt.x);
assert(pt.x == 10);
Question: in the above code, will the assertion pass?
Answer: it depends on Point's implementation. If x is a member
variable, then yes. If it's a getter, then doubleMyValue will
take a rvalue and x won't be mutated and the assertion will fail.
I think this is a non-trivial conceptual problem.
Re: unit-threaded v0.8.0
On Thursday, 31 January 2019 at 14:42:43 UTC, Atila Neves wrote: [snip] I've never had a need to use complicated values, so I haven't coded that. If presented with an example, I think there's a high chance I'd consider it an anti-pattern. I was thinking about something like what is in one of mir's sum unittests https://github.com/libmir/mir-algorithm/blob/deb64093afa7f934956c1568358444a803d2240c/source/mir/math/sum.d#L1587 The code builds up a bunch a tuple of tuples with each containing an array and a value that the array is supposed to sum to. It then runs through them all with a foreach loop. Here's another example: https://github.com/libmir/mir-algorithm/blob/deb64093afa7f934956c1568358444a803d2240c/source/mir/math/sum.d#L1762 [snip] I tried by using examples, but without knowing what's not clear it's hard for me to know what to do about it. I was just thinking like some more real-world examples of how you have used it. The readme.md is good!
Re: unit-threaded v0.8.0
On Thursday, 31 January 2019 at 15:03:26 UTC, Colin wrote:
On Wednesday, 30 January 2019 at 14:27:25 UTC, Atila Neves
wrote:
New release of unit-threaded, the advanced test framework for
D:
https://code.dlang.org/packages/unit-threaded
Besides bug fixes, the main difference is now cartesian
product of types works as it did for values when it comes to
parameterized tests:
--
@Types!(ubyte, byte)
@Types!(int, uint, float)
@UnitTest
void fun(T0, T1)() {
static assert(T0.sizeof == 1);
static assert(T1.sizeof == 4);
}
--
This now generates 6 tests, one for each combination of types,
similarly to what already worked with the @Values UDA.
Thanks for this library. One of the more useful on
code.dlang.org!
Thanks!
Re: DIP 1016--ref T accepts r-values--Formal Assessment
On 1/31/19 3:25 AM, Walter Bright wrote: But the DIP says const ref is not required. Therefore, copying an lvalue to a temporary cannot be allowed, therefore implicit conversion of lvalues cannot happen. The biggest reason I see to not worry about const is that we already don't for member functions. And the world hasn't ended (yet). Then we're faced with the question of if implicit conversion of lvalues is not allowed, should implicit conversion of rvalues be allowed? I'm not so sure it should be. For one thing, a lot of people are confused about lvalues vs rvalues, and would find the difference in behavior puzzling. For another, it can complicate overloading rules. I'd say allowing the conversions needs a strong rationale. We could certainly start out with no conversions allowed (except you MUST allow conversions of compile-time data -- e.g. literals and CTFE produced values -- that is very key), and then relax the rules later if that's important. -Steve
Re: unit-threaded v0.8.0
On Wednesday, 30 January 2019 at 14:27:25 UTC, Atila Neves wrote:
New release of unit-threaded, the advanced test framework for D:
https://code.dlang.org/packages/unit-threaded
Besides bug fixes, the main difference is now cartesian product
of types works as it did for values when it comes to
parameterized tests:
--
@Types!(ubyte, byte)
@Types!(int, uint, float)
@UnitTest
void fun(T0, T1)() {
static assert(T0.sizeof == 1);
static assert(T1.sizeof == 4);
}
--
This now generates 6 tests, one for each combination of types,
similarly to what already worked with the @Values UDA.
Thanks for this library. One of the more useful on code.dlang.org!
Re: DIP 1016--ref T accepts r-values--Formal Assessment
On 1/31/19 2:26 AM, Andrei Alexandrescu wrote:
The trouble is major.
Replace "if" with "while":
while (ref_fun(10)) { ... }
==>
{
int __tmp = 10;
while (ref_fun(__tmp)) { ... }
}
That means ref_fun is called with the same lvalue multiple times. In all
likelihood this is not what you want!
Yes, the trouble specifically is loops. Because loops execute their
internal expressions over and over again.
Unfortunately, this means lowering isn't possible. That is, lowering to
something expressible in the normal language isn't possible.
However, we all know that loops are essentially "lowered" in the AST to
simple ifs and gotos. We just need to operate at that level.
So for instance the above looks something like this in AST:
loop_continue:
if(ref_fun(10))
{
...
}
else
goto loop_end;
goto loop_continue;
loop_end:
(I know I'm omitting a lot of extra stuff like scope cleanup, that is
implied here, as I don't know the exact details).
What needs to happen is the temporary (with extra scope)is inserted
between the loop start and the if statement:
loop_continue:
{
int __tmp = 10;
if(ref_fun(__tmp))
{
...
}
else
goto loop_end;
}
goto loop_continue;
loop_end:
A possible retort is: "Of course, while would not be lowered that way,
but a slightly different way!" etc. The point is, ALL OF THAT must be in
the DIP, not assumed obvious or clarified in informal discusson outside
the DIP.
Again: please be thorough, state your assumptions, cover all cases.
Agree, this needs to handle all possible cases. Really I think loops are
the only problems, foreach, for, and while/do..while
A possible way forward is inventing a new syntax to allow declarations
in this space, and then lowering can happen. Something similar to
if(auto x = ...)
-Steve
Re: unit-threaded v0.8.0
On Wednesday, 30 January 2019 at 14:55:37 UTC, jmh530 wrote:
On Wednesday, 30 January 2019 at 14:27:25 UTC, Atila Neves
wrote:
[snip]
--
@Types!(ubyte, byte)
@Types!(int, uint, float)
@UnitTest
void fun(T0, T1)() {
static assert(T0.sizeof == 1);
static assert(T1.sizeof == 4);
}
--
This now generates 6 tests, one for each combination of types,
similarly to what already worked with the @Values UDA.
I'm a little confused on this. What if you have void fun(T0,
T1, T2)) {}, but only two @Types listed? Does it just do the
first two?
It would fail to compile.
Also, there is an example in the readme on @Values of
@Values(1, 2, 3) unittest { assert(getValue!int % 2 == 0); }
What if it's not so easy to create the values? I suppose you
could pass the parameters in @Values to some other function
that will then create what you actually need and then test
using that.
I've never had a need to use complicated values, so I haven't
coded that.
If presented with an example, I think there's a high chance I'd
consider it an anti-pattern.
Maybe good to provide some more examples of advanced usage?
Documentation is hard. :(
I tried by using examples, but without knowing what's not clear
it's hard for me to know what to do about it.
Re: Spasm 0.1.3 released - with bindings to web apis
On Thursday, 31 January 2019 at 09:21:45 UTC, Thomas Brix Larsen wrote: The targets wasm32 and wasm64 are missing in the Arch package. Ah, too bad. wasm is still considered an experimental LLVM target (at least for LLVM 7), so LLVM needs to be built in a special way (LLVM_EXPERIMENTAL_TARGETS_TO_BUILD CMake variable) to enable it.
Re: unit-threaded v0.8.0
On Wednesday, 30 January 2019 at 14:55:37 UTC, jmh530 wrote:
Also, there is an example in the readme on @Values of
@Values(1, 2, 3) unittest { assert(getValue!int % 2 == 0); }
What if it's not so easy to create the values? I suppose you
could pass the parameters in @Values to some other function
that will then create what you actually need and then test
using that. Maybe good to provide some more examples of
advanced usage?
I suppose that if the values you want to test with require some
complicated initialization only possible at runtime, @Values
could be made to hold a list functions that would be called at
runtime to create the values, before executing your test function.
Re: Spasm 0.1.3 released - with bindings to web apis
On Wednesday, 30 January 2019 at 11:49:17 UTC, kinke wrote: On Wednesday, 30 January 2019 at 11:03:13 UTC, WebFreak001 wrote: I install LDC from the arch repositories, which should just be the prebuilt binaries from the ldc repo I think Nope, they aren't. I guess your problem is that you cannot *link* wasm; that will only work with v1.14 for distro packages (without integrated LLD). The targets wasm32 and wasm64 are missing in the Arch package.
Re: DIP 1016--ref T accepts r-values--Formal Assessment
On 1/30/2019 5:55 PM, Manu wrote:
lets replace 10 with a short variable named: S
"a short variable named: S" is an lvalue, so why would the rewrite be
attempted? S must be an rvalue for any rewrite to occur. We're talking
about rvalues here.
This illustrates why this should be compared with C++. Consider this C++ code:
const int& foo(const int& x) { return x; }
const int& test() {
short s;
return foo(s);
}
It compiles with clang++. The code generated for test() is:
pushRBP
mov RBP,RSP
sub RSP,010h
lea RDI,-8[RBP]
movsx EAX,word ptr -2[RBP]
mov -8[RBP],EAX
callfoo
add RSP,010h
pop RBP
ret
See what it is doing? It's converting s to an int, putting the int into a
temporary, then passing a reference to that temporary to foo(). So when you ask
why would a person think that this would happen with the DIP, if they know C++,
they would assume similar behavior. This is why the DIP needs to specifically
say this is not the proposed behavior. It is why a comparison to C++ behavior is
essential. It is a lot easier to understand the DIP if people can apply their
existing understanding, with a few modifications, to the D behavior. It's also
necessary to compare with C++ to see if the DIP missed something important, and
to justify any other behavioral differences.
The interesting question is, since C++ supports this behavior, what about the
truck-sized hole? The answer is in the declaration of foo(const int&). The const
is the reason. The referenced value cannot be modified. The realloc example is
blocked by the compiler.
But the DIP says const ref is not required. Therefore, copying an lvalue to a
temporary cannot be allowed, therefore implicit conversion of lvalues cannot happen.
Then we're faced with the question of if implicit conversion of lvalues is not
allowed, should implicit conversion of rvalues be allowed? I'm not so sure it
should be. For one thing, a lot of people are confused about lvalues vs rvalues,
and would find the difference in behavior puzzling. For another, it can
complicate overloading rules. I'd say allowing the conversions needs a strong
rationale.
