On Saturday, 13 January 2018 at 18:28:55 UTC, Timon Gehr wrote:
However, this proposal is independent of all the other ones, so
in the end it is up to Walter and Andrei.
Have there been any discussions regarding the semantics of _?
struct G { ~this() { writeln("destruct"); } }
void main() {
On Saturday, 1 September 2018 at 20:15:15 UTC, Walter Bright
wrote:
Note the "may or may not be evaluated." We've debated this here
before. I'm rather pleased that John agrees with me on this.
I.e. the optimizer can assume the expression is true and use
that information to generate better
On Tuesday, 31 July 2018 at 07:49:40 UTC, Shachar Shemesh wrote:
On 31/07/18 10:29, Mike Franklin wrote:
Please clarify if I'm missing the point.
You are. I want something along the lines of:
assertEQ(a, b, "a and b are not equal");
When run, it would issue an assert that says:
Assertion
On Friday, 12 January 2018 at 22:44:48 UTC, Timon Gehr wrote:
foreach((sum, diff); [(1, 2), (4, 3)].map!((a, b) => (a + b, a
- b)))
{
writeln(sum, " ", diff);
}
I'm not a big fan of the foreach syntax. It's so easy to forget
or accidentally add parentheses while coding, or read it
On Thursday, 5 October 2017 at 22:04:10 UTC, Jonathan M Davis
wrote:
It's far cleaner for them to be tied to the type - especially
when you consider that it's not possible to differentiate
between conflicting overloadeded operators.
In other words, we lose global uniqueness of operators if we
On Thursday, 17 August 2017 at 16:32:20 UTC, bitwise wrote:
In a high-performance context though, the performance hit may
be unacceptable.
Well in those super rare situations, there's always the
workaround with mixins:
mixin template funcWithAttr(string decl, string attributes,
string
On Saturday, 19 August 2017 at 16:02:27 UTC, bitwise wrote:
We have to consider the potential for abuse.
I don't like measuring features on the potential for abuse, but
this feature cries for abuse. Even in the simpler form of your
proposal.
Let's say there are two functions with
On Wednesday, 16 August 2017 at 12:58:03 UTC, Joakim wrote:
That is correct. After a while it gets tiring to see a
neverending stream of complexity added to the language while
things that would actually help (like IDE support) do not get
any attention.
+1, though I'd go for bug-fixing over
On Sunday, 16 July 2017 at 20:15:11 UTC, Timon Gehr wrote:
On 16.07.2017 21:49, Guillaume Boucher wrote:
On Sunday, 16 July 2017 at 12:41:06 UTC, Timon Gehr wrote:
It is therefore most natural to say that Bottom.sizeof == ∞.
True, but size_t.max doesn't have the properties of ∞.
The only
On Sunday, 16 July 2017 at 20:04:25 UTC, Timon Gehr wrote:
The issue isn't purism, it is type safety. If you create an
EvolvedPenguin, upcast it to a Penguin and call the fly method
you get UB. So noreturn would indeed need to enforce that all
overrides are also noreturn.
I see it as some
On Sunday, 16 July 2017 at 12:41:06 UTC, Timon Gehr wrote:
It is therefore most natural to say that Bottom.sizeof == ∞.
True, but size_t.max doesn't have the properties of ∞.
The only sane choice to me seems to be a value of type Bottom,
i.e. is(typeof(Bottom.sizeof) == Bottom).
On Sunday, 16 July 2017 at 13:03:40 UTC, Timon Gehr wrote:
I don't think that's true. A Bottom type does not cover all
use cases of @noreturn/@pragma(noreturn).
...
I think it does, but it is a significantly more invasive
language change.
The best you can hope for is that any code with
On Monday, 10 July 2017 at 04:02:59 UTC, Nicholas Wilson wrote:
1)@noreturn
2)@disable(return)
3)none
w.r.t optimisation assuming both 1 & 3 impact DMD equally [...]
I don't think that's true. A Bottom type does not cover all use
cases of @noreturn/@pragma(noreturn).
Example 1:
On Monday, 26 June 2017 at 18:42:24 UTC, Ola Fosheim Grøstad
wrote:
On Monday, 26 June 2017 at 17:44:15 UTC, Guillaume Boucher
wrote:
Java uses A, Rust/Go use B. C++ uses B to some extend (e.g.
in std::experimental::filesystem).
The C++17 filesystem api provides two alternatives, the
On Monday, 26 June 2017 at 17:50:47 UTC, Moritz Maxeiner wrote:
I have tried using such Monads in D, but in the end it always
ended up being too verbose or too hard to read compared to
using exceptions or even simple error codes (with 0 == no
error).
I haven't tried that yet, tbh. visit is
On Monday, 26 June 2017 at 16:52:22 UTC, Sebastien Alaiwan wrote:
Checked exceptions allow a lot more precision about what types
of exceptions a function can throw.
I totally agree that this is a problem with D right now. If you
want to catch all errors, how are you supposed to remember what
On Sunday, 25 June 2017 at 15:46:12 UTC, Petar Kirov [ZombineDev]
wrote:
out result > 0 // perhaps the best
How would you handle things like this:
T minimum(T)(RedBlackTree!T tree)
in (!tree.empty)
out result in (tree)
{
return tree.front;
}
That could either mean
On Sunday, 11 June 2017 at 19:17:36 UTC, Andrei Alexandrescu
wrote:
Instead of an error, I get a no-op result that looks like
success. How can that situation be converted to an error?
That makefile target is poorly written.
It was probably intended to have a dependency on the directory
On Monday, 29 May 2017 at 19:07:03 UTC, H. S. Teoh wrote:
So, recently in one of my pet projects I have a bit of code
that takes a string, fills in a code template, invokes the D
compiler to create a shared object, then loads the object with
dlopen() and calls dlsym() to get the entry point
On Monday, 22 May 2017 at 13:20:41 UTC, Stefan Koch wrote:
type inference is not magic, it's a search for a pattern over
the syntax (sub)tree.
Hence it can have quadratic time/memory complexity.
Well, the type system of Scala is turing complete, hence it can
take arbitrarily long:
On Sunday, 14 May 2017 at 09:42:05 UTC, Patrick Schluter wrote:
But completely removing the code when one encounters for
example: if(val+1 == INT_MIN) is simply nuts.
Removing such code is precisely what dmd does:
https://issues.dlang.org/show_bug.cgi?id=16268
On Wednesday, 10 May 2017 at 01:19:08 UTC, Nick Sabalausky
(Abscissa) wrote:
The moral of this story: Sometimes, breaking people's code is
GOOD! ;)
I don't get the hate that compiler warnings get in the D
community.
Sure you can disable them if you don't care, but then don't
complain about
On Wednesday, 10 May 2017 at 05:26:11 UTC, H. S. Teoh wrote:
int myfunc(blah_t *blah, bleh_t *bleh, bluh_t *bluh) {
void *resource1, *resource2, *resource3;
int ret = RET_ERROR;
/* Vet arguments */
if (!blah || !bleh ||
On Tuesday, 9 May 2017 at 16:55:54 UTC, H. S. Teoh wrote:
Ouch. Haha, even I forgot about this particularly lovely
aspect of C. Hooray, freely call functions without declaring
them, and "obviously" they return int! Why not?
To be fair, most of your complaints can be fixed by enabling
On Tuesday, 9 May 2017 at 03:06:37 UTC, Timon Gehr wrote:
If you are interested in static foreach making it into the
language, please play with the implementation and tell me how
to break it.
Code:
void main() {
void f() { idonotexist(); }
static foreach(j;0..0) {
On Monday, 12 December 2016 at 15:51:07 UTC, Andrei Alexandrescu
wrote:
I think all Errors should be singletons - multiple objects in
that hierarchy arguably make no sense.
With that logic, why does Throwable have the field "next"?
On Sunday, 11 December 2016 at 21:39:26 UTC, Timothee Cour wrote:
is there a way to pass linker flags?
dmd -Wl=comma_separated_linker_flags
eg:
dmd -Wl=-lbar,-Ldir,--export-dynamic,-pie
(same functionality as clang++
-Wl,-lbar,-Ldir,--export-dynamic,-pie)
If not could we support it? Would
On Thursday, 27 October 2016 at 19:59:09 UTC, Steven
Schveighoffer wrote:
You create a large meta-template library called footMassage,
which then ends up via compiler inference compiling into a gun
instead.
Accidentally compiling a massage into a gun is not a high
priority bug. In order to
On Saturday, 1 October 2016 at 19:51:05 UTC, Dicebot wrote:
I think that is OK but only if actual file inside the dir is
created with `mktemp --tmpdir=/tmp/.dmd-test-run/` (or using a
similar technique).
This is not sufficient. Any user can create a symlink from
/tmp/.dmd-test-run/ to e.g.
On Saturday, 1 October 2016 at 16:46:56 UTC, Guillaume Boucher
wrote:
On Saturday, 1 October 2016 at 16:43:29 UTC, Stefan Koch wrote:
On Saturday, 1 October 2016 at 16:05:25 UTC, Andrei
Alexandrescu wrote:
https://issues.dlang.org/show_bug.cgi?id=16568
TIA! -- Andrei
Please post some
On Saturday, 1 October 2016 at 16:43:29 UTC, Stefan Koch wrote:
On Saturday, 1 October 2016 at 16:05:25 UTC, Andrei
Alexandrescu wrote:
https://issues.dlang.org/show_bug.cgi?id=16568
TIA! -- Andrei
Please post some code/instructions to reproduce the issue.
The fix for this will be quite
On Wednesday, 28 September 2016 at 14:27:58 UTC, Chris Wright
wrote:
Increment, decrement, and
test for equality is sufficient mathematically, but we want
programs that
terminate in our lifetimes.
Only for BigInts you need those three. For ints decrement is not
needed. And for most other
On Monday, 5 September 2016 at 23:50:33 UTC, Timon Gehr wrote:
One hacky way is to provide a mixin template to create a
wrapper type within each module that needs it, with
std.typecons.Proxy. Proxy picks up UFCS functions in addition
to member functions and turns them into member functions.
On Sunday, 3 July 2016 at 09:08:14 UTC, Ola Fosheim Grøstad wrote:
On Saturday, 2 July 2016 at 20:17:59 UTC, Andrei Alexandrescu
wrote:
So what's the fastest way to figure that an integral is
convertible to a floating point value precisely (i.e. no other
integral converts to the same floating
On Saturday, 2 July 2016 at 15:15:39 UTC, Guillaume Boucher wrote:
E.g. opCast!(int, ubyte) should not require any checks.
Or opCast!(long, int) and opCast!(int, int).
On Saturday, 2 July 2016 at 12:26:34 UTC, Andrei Alexandrescu
wrote:
How would you reshape this? It's important that the call to
hook is physically at the end of the function and issued just
in that place, and that the code does not do any redundant work.
Your function does redundant work.
On Friday, 24 June 2016 at 20:43:38 UTC, deadalnix wrote:
Most reasonable is
numerator = quotient * divisor + remainder
Which means it can be negative.
Depends on the definition.
If division truncates towards negative infinity, the remainder
will always be nonegative (in case of a positive
I was referring to this diff in the pull linked request:
-private size_t _alignUp(size_t alignment)(size_t n)
+private uintptr_t _alignUp(uintptr_t alignment)(uintptr_t n)
size_t is the correct type. There is no reason to change it.
On Tuesday, 14 June 2016 at 21:59:32 UTC, Walter Bright wrote:
A related issue is I see much code of the form:
cast(size_t)ptr & 3
to check alignment. A better (possibly faster) method is:
cast(uint)ptr & 3
because even 64 bit CPUs often operate faster with 32 bit
operations (thanks
On Sunday, 12 June 2016 at 12:16:11 UTC, Dicebot wrote:
On 06/09/2016 01:12 AM, Walter Bright wrote:
On 6/8/2016 1:47 PM, Dicebot wrote:
I will finish description for proposed process this weekend
and send
it to
dmd-internal mail list.
Cool!
On Tuesday, 24 May 2016 at 20:16:32 UTC, Walter Bright wrote:
On 5/24/2016 9:22 AM, Timon Gehr wrote:
Yes, it does. The compiler does not use exponential space to
store the AST.
BTW, all types in dmd have a 'deco' string which is the AST
linearized as a string. This string is also used to
On Monday, 23 May 2016 at 20:34:19 UTC, Walter Bright wrote:
On 5/23/2016 12:32 PM, Timon Gehr wrote:
Isn't it enough to create
references to previously embedded mangled symbols (i-th symbol
already mangled)
while generating the mangled string?
That's been covered upthread, and VC++/g++ do
On Saturday, 21 May 2016 at 22:07:27 UTC, Walter Bright wrote:
As mentioned elsewhere, the C++ mangling scheme has a primitive
and ineffective LZ77 scheme built in, so I wouldn't waste time
on that.
Sorry if I didn't memorize everything in this forum from the last
20 years, can you give a
On Saturday, 21 May 2016 at 18:25:46 UTC, Walter Bright wrote:
On 5/20/2016 11:18 PM, poliklosio wrote:
foo!(boo!(bar!(baz!(int))), #1, #2)
Where #1 and #2 are special symbols that refer to stuff that
was **already in
the name**, particularly:
#1: bar!(baz!(int))
#2: baz!(int)
This is what
44 matches
Mail list logo
