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 bu
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
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.
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'
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.
Tha
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 s
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
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()
r
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.
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 implicit
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
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
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 proble
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
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
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.
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 th
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) {
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
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. D
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 on
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
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
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;
}
Poin
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;
}
Poin
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();
do
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
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
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 fun
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
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 wan
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 =
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
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
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 canno
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+
36 matches
Mail list logo
