Thanks for the list! This is good stuff.
On 8/26/2018 5:40 PM, Manu wrote:
By contrast, another colleague tried writing a small game in his own
time. His feedback was that it felt 'fine', but he didn't encounter
anything that made it "simpler than C++", and claimed readability
improvements were tenuous.
He wouldn't show us his code.
On 8/26/2018 1:55 PM, Walter Bright wrote:
I will tiresomely ask again, do you have a list of each and every aspect of the
poor integration?
I know you don't like filing bug reports. I'll make it easy for you.
Every time someone you work with says:
"I can't use D because ..."
"
On 8/26/2018 8:43 AM, Chris wrote:
I wanted to get rid of autodecode and I even offered to test it on my string
heavy code to see what breaks (and maybe write guidelines for the transition),
but somehow the whole idea of getting rid of autodecode was silently abandoned.
What more could I do?
On 8/26/2018 12:34 PM, Manu wrote:
I work at a company with a thousand engineers, all VS users, D could
find home there if some rough edges were polished, but they
*absolutely must be polished* before it would be taken seriously.
It is consistently expressed that poor VS integration is an
On 8/25/2018 5:52 PM, David Nadlinger wrote:
On Saturday, 25 August 2018 at 22:53:44 UTC, Walter Bright wrote:
On 8/25/2018 2:46 PM, David Nadlinger wrote:
At least for the transition period, I'd have attributes only apply to the
user-specified code and infer them for the actual full
On 8/25/2018 2:46 PM, David Nadlinger wrote:
On Saturday, 25 August 2018 at 20:52:06 UTC, Walter Bright wrote:
If I fix the bug, I break existing code, and apparently a substantial amount
of existing code. What's your advice on how to proceed with this?
At least for the transition period, I'd
On 8/25/2018 3:52 AM, Chris wrote:
On Friday, 24 August 2018 at 19:26:40 UTC, Walter Bright wrote:
Every programmer who says this also demands new (and breaking) features.
"Every programmer who..." Really?
You want to remove autodecoding (so do I) and that will break just abo
On 8/25/2018 7:37 AM, Jonathan M Davis wrote:
In general, any place where D was
designed around the idea that something would _always_ be there (e.g. init
values and default initialization) but we've then later added the ability to
get around it (e.g. void initialization or @disable) has tended
On 8/25/2018 6:32 AM, Timon Gehr wrote:
(Or at least, not wrong. Using e.g. `void*`
instead of an incompatible type would already be an improvement.)
Making it void* is a reasonable idea.
On 8/25/2018 6:33 AM, Shachar Shemesh wrote:
If you allow a feature to be disabled, you really need to keep in mind that
feature might be well and truly disabled.
Disabling default initializations is not @safe, and that means taking
responsibility for it not being default initialized.
It's
On 8/24/2018 6:34 AM, Shachar Shemesh wrote:
No, unlike what I suggest, that doesn't work without carefully reviewing every
single place you put it to see whether the constructor actually supports
destructing a partially constructed object.
All D objects are default-initialized before the
On 8/23/2018 5:58 PM, Chris M. wrote:
Seems to be more of a warning of what issues we may face if DIP25/DIP1000 are
finally implemented. It would be good to consider NLLs as well before D is
committed. No point in repeating issues that have already been studied.
DIP25 waqs "finally
On 8/23/2018 6:32 AM, Steven Schveighoffer wrote:
Furthermore any member function (or UFCS function for that matter) REQUIRES the
first parameter to be the aggregate. How do you make a member function that
stuffs the return into a different parameter properly typecheck?
What I propose is that
On 8/23/2018 8:14 AM, Steven Schveighoffer wrote:
If I had to design a specific way to allow the common case to be easy, but still
provide a mechanism for the uncommon cases, I would say:
1. define a compiler-recognized attribute (e.g. @__sink).
2. If @__sink is applied to any parameter, that
On 8/24/2018 4:22 PM, tide wrote:
struct SomeStruct
{
void foo() {
// use SomeStruct
}
}
void broken()
{
void function() foo =
foo(); // runtime error, isn't actually safe uses wrong calling convention
as well
}
Not really lack of feature so much as there
On 8/24/2018 12:42 PM, tide wrote:
Some problems require new features like how taking the address of a member
function without an object returns a function pointer, but requires a delegate
where C++ has member function pointers, D just has broken unusable code. Or old
features that were
On 8/24/2018 6:04 AM, Chris wrote:
For about a year I've had the feeling that D is moving too fast and going
nowhere at the same time. D has to slow down and get stable. D is past the
experimental stage. Too many people use it for real world programming and
programmers value and _need_ both
On 8/23/2018 6:57 PM, Shachar Shemesh wrote:
At this point I can either use the work-around I already have and (try to,
obviously unsuccessfully) forget about it, file a bug report that will be
(justifiably) ignored because no-one else can reproduce it, or spend an unknown
amount of time (two
On 8/23/2018 5:02 PM, Nicholas Wilson wrote:
am currently up against a ~thousand headed hydra~ thousand
line function .
Good times :-)
On 8/24/2018 12:31 AM, Shachar Shemesh wrote:
If you're willing to have an error raised by a destructor abort the whole
program, isn't the C++ solution preferable (abort the program only on double
errors, which hardly ever happens)?
C++ has changed:
On 8/24/2018 1:45 AM, Trass3r wrote:
Are you referring to http://wg21.link/P0709 ?
Yes. (please don't use link shorteners, they tend to go poof)
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0709r1.pdf
On 8/23/2018 7:33 PM, Jonathan M Davis wrote:
Wow. I'm surprised by this. I definitely agree with David on this one.
Without being able to throw from a constructor, you can't really have it
fail, and there are times when it needs to be able to fail. Not being able
to have throwing constructors
On 8/22/2018 4:01 AM, Mihails wrote:
In my opinion, this functionality _should_ be part of
compiler itself, similar to .di generation.
This is not a bad idea.
On 8/21/2018 2:41 PM, tide wrote:
What about if you accidentially press a button that posts the comment?
That's really up to your NNTP client's design, which we didn't implement. There
are lots of NNTP clients to choose from.
Why can't syntax formatting be implemented, does anyone disagree
On 8/23/2018 3:20 PM, David Nadlinger wrote:
Not to put too fine a point on this, but I don't think I've ever said I couldn't
fix the bug; although I probably did mention it would be better to fix in the
upstream DMD frontend than in LDC.
I would be happy to have a look at it for Weka at this
One takeaway from this is despite my loathing of throwing constructors, they are
a part of D and I need to make them work properly.
I.e. I am not dictating everything in D based on my personal opinions. I try to
pick my battles.
On 8/23/2018 3:12 PM, David Nadlinger wrote:
On Thursday, 23 August 2018 at 21:31:41 UTC, Walter Bright wrote:
My personal opinion is that constructors that throw are an execrable
programming practice, and I've wanted to ban them. (Andrei, while sympathetic
to the idea, felt that too many
On 8/23/2018 9:19 AM, Jonathan M Davis wrote:
D was designed to have RAII, and it does. It's just that the implementation
is buggy (which is obviously a serious problem), so depending on what your
program is doing, it's not going to work correctly. It's not like we opted
to not have RAII in D,
On 8/23/2018 11:29 AM, Steven Schveighoffer wrote:
What this simply means is your identification of the problem is simply wrong --
it's not that you can't make subtypes with structs (you can), it's that you
can't accept rvalues by reference, and accepting by reference is required for
On 8/23/2018 9:22 AM, Shachar Shemesh wrote:
So telling me to keep filing them is simply a non-starter. I've got bugs that
simply don't reproduce in watered down examples. I will not spend two days just
to create a test case that demonstrates the bug outside the Weka code base. If
nothing
On 8/23/2018 6:22 AM, Shachar Shemesh wrote:
(we used to file bugs in Bugzilla. We stopped doing that because we saw nothing
happens with them)
Quite a number of Weka filed bugs have been fixed.
Here's the 2.080 list of 46 bugs fixed:
https://dlang.org/changelog/2.080.0.html#bugfix-list
The
On 8/23/2018 5:55 AM, Steven Schveighoffer wrote:
If front() returns by ref, then no copying happens. If front() returns by
value, then a copy is made. This should not be surprising behavior.
I think he means, if the range ITSELF doesn't allow copying, it won't work with
foreach (because
On 8/23/2018 4:31 AM, Shachar Shemesh wrote:
None of that continues to work once delegates are involved. I am yet to see a
library that can accept a delegate and correctly create a function around it
that matches its attributes.
And yes, I do include Mecca in this. I tried. It is too
On 8/23/2018 2:09 AM, Shachar Shemesh wrote:
On 23/08/18 09:58, Joakim wrote:
Because you've not listed any here, which makes you no better than some noob
Here's one: the forum does not respond well to criticism.
Not sure what you mean by that.
* Features not playing well together.
On 8/22/2018 6:50 AM, Steven Schveighoffer wrote:
What about:
size_t put(sink, parameters...)
Does this qualify as the sink being the "return" type? Obviously the real return
can't contain any references, so it trivially can be ruled out as the
destination of any escaping parameters.
Your
On 8/22/2018 3:52 AM, Atila Neves wrote:
On Wednesday, 22 August 2018 at 09:05:13 UTC, Walter Bright wrote:
On 8/21/2018 8:58 PM, Nicholas Wilson wrote:
On Tuesday, 21 August 2018 at 14:31:02 UTC, Atila Neves wrote:
The problem is that the code we write doesn't deal directly with pointers
On 8/22/2018 10:28 AM, H. S. Teoh wrote:
I don't argue against the usefulness of the features that github
provides, but I'm also wary of the fact that it's basically a walled
garden -- there's no simple way I know of to extract data like pull
requests, comments, cross-references, etc.. I mean,
On 8/21/2018 6:07 PM, Mike Franklin wrote:
The proposed idea wants to make the first parameter, if it's `ref`, special.
This is because Phobos is written with functions of the form:
void put(sink, parameters...)
which corresponds to:
sink.put(parameters...)
The two forms are fairly
On 8/21/2018 8:58 PM, Nicholas Wilson wrote:
On Tuesday, 21 August 2018 at 14:31:02 UTC, Atila Neves wrote:
The problem is that the code we write doesn't deal directly with pointers -
see the recent confusion in this forum over where `scope` on the left applies
to the `this` pointer or the one
On 8/21/2018 2:17 PM, Atila Neves wrote:
Well, no. The syntax isn't the same for member functions. The examples from the
actual DIP don't compile. There it says:
---
scope can be applied to function return values (even though it is not a type
qualifier). It must be applied to the left of
On 8/21/2018 7:31 AM, Atila Neves wrote:
The problem is that the code we write doesn't deal directly with pointers - see
the recent confusion in this forum over where `scope` on the left applies to the
`this` pointer or the one returned by the member function.
That's what I was saying :-)
On 8/21/2018 7:18 AM, Seb wrote:
some rely on stackoverflow, some have an active wiki
There are a few good points to move D.learn to Stack Overflow and that's
actually one thing that we have talked about a few times and somehow never has
happened. In the D survey there was a 2:1 "consensus"
On 8/20/2018 8:42 PM, Ali wrote:
Many of those new comers who ask about the forum software .. they never stick,
they dont complain, or question, or try to change for the better, they simply leave
Ask 10 people, and you'll get 10 different answers on what a better forum would
be. If people
On 8/20/2018 6:46 AM, Steven Schveighoffer wrote:
I would, but I have no idea how dip1000 is supposed to work. I think only you
understand it. Even looking at the PR that you have been citing over and over, I
can't make heads or tails of what it does or what it allows.
The way to understand
On 8/20/2018 6:08 AM, Atila Neves wrote:
As mentioned in my other thread, I went to file one and it was declared not a
bug:
https://issues.dlang.org/show_bug.cgi?id=17927
I'll look at it again.
On 8/18/2018 8:55 AM, David Nadlinger wrote:
On Saturday, 18 August 2018 at 07:50:04 UTC, Dukc wrote:
What's HOPL?
https://hopl4.sigplan.org, presumably. —David
That's right.
On 8/18/2018 9:59 AM, Jonathan Marler wrote:
In your mind, what defines the D language's level of success?
It no longer needs me or Andrei.
On 8/17/2018 5:30 AM, Atila Neves wrote:
It's not easy though. You have to either be building your own phobos
Not really. You only have to be able to import phobos files. You don't have to
compile something that will link.
I.e. just copy the phobos source tree, add @safe to it, and point
On 8/17/2018 11:17 AM, bachmeier wrote:
This is a good example of D needing to evolve or fizzle out. I don't see
evidence that the community has yet figured out how to evolve the language. If
it had, these problems would not be around for so many years.
We deprecate features of D all the
On 8/17/2018 4:33 AM, Atila Neves wrote:
I've been using -dip1000 a lot lately.
Great news!
I hit two bugs yesterday.
In D? or in your code?
When it works, it's great, _except_:
. @safe isn't default
. -dip1000 isn't default
. Good luck figuring out why your template functions aren't
On 8/17/2018 3:01 AM, Jonathan M Davis wrote:
we still don't have a real plan as to how we're going to make
-dip1000 the default.
We do have a plan. Get Phobos to compile with -dip1000. As to why that hasn't
happened yet, see:
https://github.com/dlang/dmd/pull/8504
On 8/17/2018 12:50 AM, Jonathan M Davis wrote:
> That particular bug is a duplicate of
> https://issues.dlang.org/show_bug.cgi?id=8838, which was closed as fixed
> based on the fact that -dip1000 fixes the problem by treating marking the
> slice of a static array with scope. It's still quite
On 8/14/2018 6:37 AM, Rel wrote:
On Tuesday, 14 August 2018 at 13:11:57 UTC, Rel wrote:
Can I or is it even possible to remove the CRT (C's runtime library)
completely from my executables compiled with betterC flag?
Okey, it seems I figure out how to do it with MinGW linker:
import
On 8/13/2018 11:48 AM, Seb wrote:
Feedback is welcome ;-)
Thank you!
On 8/8/2018 2:01 PM, Steven Schveighoffer wrote:
Here's where I'm struggling -- because a string provides indexing, slicing,
length, etc. but Phobos ignores that. I can't make a new type that does the same
thing. Not only that, but I'm finding the specializations of algorithms only
work on the
On 8/6/2018 6:57 AM, Steven Schveighoffer wrote:
But I'm not sure if the performance is going to be the
same, since now it will likely FORCE autodecoding on the algorithms that have
specialized versions to AVOID autodecoding (I think).
Autodecoding is expensive which is why the algorithms
On 8/7/2018 3:49 AM, Atila Neves wrote:
Yes, I've already implemented it.
Wonderful!
I'm not sure what the impact will be with nested namespaces in real headers. I
guess we'll have to see.
Yes.
On 8/7/2018 12:08 AM, Nicholas Wilson wrote:
I don't see what making an alias to a namespace has to do with it.
That was your suggested workaround, was it not?
No, it was not. It was about making an alias to the members of the namespace.
On 8/7/2018 1:13 AM, Walter Bright wrote:
On 8/7/2018 12:08 AM, Nicholas Wilson wrote:
I don't see what making an alias to a namespace has to do with it.
That was your suggested workaround, was it not?
No, it was not. It was about making an alias to the members of the namespace.
BTW
On 8/6/2018 8:14 PM, Nicholas Wilson wrote:
Yes, but only for a single instance of the namespace.
In the general case no, see the first reply in
https://forum.dlang.org/post/xdaedmlbbqtztiqcw...@forum.dlang.org
The idea is to not have a namespace, I don't see what making an alias to a
Let's see if we can find some common ground.
The boilerplate I suggested seems to enable DPP to generate working code that
behaves "as if" the namespace scope is not there, even for nested namespaces.
Is this correct?
On 8/5/2018 9:53 PM, Manu wrote:
If we produce a DIP to fix this, will you reject it in principle?
Producing a DIP is a good idea, it provides an anchor point for any future
discussion of the topic, rather than the tangle and noise that is this thread.
It is an ample opportunity to put the
On 8/6/2018 3:19 PM, tide wrote:
That's just a deflection,
1. I'm only here to help, and am not interested in scoring debate points.
2. To bring up other topics, please start a new thread. Especially since this
one is quite voluminous.
On 8/6/2018 11:26 AM, tide wrote:
What's your crossplatform workaround if I have a namespace named "version" or
"package" ?
See my reply to Rick Cattermole.
https://digitalmars.com/d/archives/digitalmars/D/Is_there_any_good_reason_why_C_namespaces_are_closed_in_D_317277.html#N317507
You also
On 8/2/2018 5:23 PM, rikki cattermole wrote:
Because it will affect mangling only, do we have any examples of c/c++ code that
appends _'s to it that is used by the D community?
The __ scheme won't break existing code, and we don't need a survey to show
that.
On 8/4/2018 12:45 AM, Manu wrote:
[...]
I get it, Manu, you don't find my arguments compelling. You've put these forth
before, and I could repeat myself rebutting each. I expect we're at a dead end
with that.
But the fact remains, I've shown both you and Atila how to make things work for
On 8/3/2018 3:58 AM, Atila Neves wrote:
With your mixin template technique everything ends up in the global namespace of
the moduel making the C++ declarations.
Right, but that's what you wanted!
I would only be able to alias a nested
namespace once, since the code below obviously won't
On 8/2/2018 2:26 AM, Daniel N wrote:
Personally I would never *bind* to two different namespaces in a single file,
You'd be amazed at what people do and then set their entire store based on it.
If the language spec allows it, people will do it. People will even design their
code to require
On 8/2/2018 9:58 AM, Manu wrote:
Have you ever tried the alias method I proposed?
Of course, it's the only tool we have here, and a major source of my
frustration!
Why is it frustrating?
On 8/2/2018 2:05 AM, rikki cattermole wrote:
8. if any identifier starts with a keyword and ends with at minimum one _, one _
from the end of the identifier will be removed for mangling (but not e.g. lookup).
This will break existing code. A double underscore prefix is reserved for the
On 8/1/2018 11:08 PM, Manu wrote:
We have demonstrated consistent ongoing issues and frustration for 6
years.
Have you ever tried the alias method I proposed?
On 8/1/2018 11:08 PM, Manu wrote:
I think implementing the string alternative is the only robust way
forward, because that also solves the additional problem of being able
to name C++ namespaces that are invalid D keywords, which has bitten
me in at least 2 particularly noteworthy occasions.
On 8/1/2018 10:06 PM, Johannes Pfau wrote:
I guess that would be acceptable if there is a real benefit, but I have
not seen a single argument for the current behavior in this thread.
Please read my postings in this thread, then.
On 8/1/2018 12:01 PM, Manu wrote:
You've never justified the design
complexity and the baggage it carries.
Don't confuse you not agreeing with it with I never justified it.
And please don't confuse me not listening to you with me not agreeing with you.
It *is* possible for reasonable people
On 8/1/2018 7:09 PM, Rubn wrote:
On Wednesday, 1 August 2018 at 23:04:01 UTC, Walter Bright wrote:
An example of silent hijacking:
extern (C++, "ab") void foo(long); // original code
... lots of code ...
extern (C++, "cd") void foo(int); // added later by inte
Thanks!
On 7/31/2018 1:47 AM, Atila Neves wrote:
The only good way (I don't think the mixin template and struct solutions count)
to link to any of that today would be to have one enormous D file with
_everything_ in it, including nested namespaces.
Why doesn't it count? The user doesn't need to write
On 8/1/2018 10:24 AM, Jonathan M Davis wrote:
Not to say that that can't work, but I have to say that it seems pretty ugly
if using extern(C++, NS) requires a bunch of aliases just to use symbols
normally.
What is normal is a slippery concept, especially when one is comparing different
lookup
On 7/31/2018 1:12 AM, Manu wrote:
Given your favourite example:
module a;
extern(C++, ns) void foo();
module b;
extern(C++, ns) void foo();
-
module c;
import a, b;
foo(); // error: ambiguous
ns.foo(); // error, ambiguous (obviously)
a.ns.foo(); // naturally, this works... it's the
On 7/31/2018 1:43 AM, Atila Neves wrote:
It's not the same - if I want to link to std::vector and std::string, I'd expect
them to be used in D as std.vector and std.string, not std.vector and
HackyDThing0.std.string.
Calling them std.string will already cause problems, because there's an
On 7/31/2018 3:34 PM, Laeeth Isharc wrote:
On Saturday, 28 July 2018 at 01:03:10 UTC, Walter Bright wrote:
On 7/27/2018 4:15 PM, Laeeth Isharc wrote:
Can you think of a pragmatic solution to Atila's problem?
One way is for the C++ => D translator to gather all the members of a
namesp
On 7/31/2018 11:24 AM, Walter Bright wrote:
On 7/27/2018 4:03 AM, Seb wrote:
This a thread to explore whether it would be feasible to do so.
Since DMD and Druntime require each other, it is the right thing to do.
Perhaps my judgement is premature. There are a lot of good points raised
On 7/31/2018 12:07 PM, Iain Buclaw wrote:
On 31 July 2018 at 20:40, Walter Bright via Digitalmars-d
wrote:
What's the difference between:
DLI
GDMD
DGCC
?
DLI: From what I recall, an independent project that just simply
ported DMD front-end to Linux. I don't
On 7/31/2018 2:16 PM, PaperBoy wrote:
The author has possibly passed away on May 3 :
https://necrocanada.com/obituaries-2018/burton-radons-2018/
That makes me sad. I was just reading some of his posts last night. He was still
young, too.
Thanks!
What's the difference between:
DLI
GDMD
DGCC
?
On 7/27/2018 4:03 AM, Seb wrote:
This a thread to explore whether it would be feasible to do so.
Since DMD and Druntime require each other, it is the right thing to do.
Mike and Iain - yay, this is just what I was looking for. Thanks!
What I'm doing is preparing a submission to HOPL on the origins of D. There's an
emphasis on accuracy, references, correct dates, correct attributions, and
correct credit to the right people.
There'll be more questions from me
My issue is you're presenting solutions. But I have no idea what the problem is,
because every time I present a solution to the examples you give, you say it's
no good, because your problem is something else.
I cannot reverse engineer what the issue is from your proposed solution.
My second
On 7/30/2018 2:12 PM, Manu wrote:
We're all happy with the D
module system, that's how we want to organise our code. Please let us
organise our code using the D module system.
I have literally no idea what you mean. That's why I suggest you show what your
C++ code looks like, and what you
I'm trying to pin down an accurate timeline of D:
* When was the gdc project started, when was its first release, and who gets the
credit?
* When was the ldc project started, when was its first release, and who gets the
credit?
On 7/30/2018 9:45 AM, Manu wrote:
Sure it 'works', but it's an annoying point of friction, and it
doesn't need to be that way.
You can reduce it to:
mixin(cppNamespace("ns", "void foo();"));
You haven't explained why you can't just move the namespace ns declarations in
one file
On 7/30/2018 6:48 AM, Atila Neves wrote:
This doesn't work for templates. If it did I wouldn't have an issue since
libclang tells me what the mangling is.
You're right.
On 7/30/2018 5:07 AM, Daniel N wrote:
I tried that but it mangles wrong.. it includes "S1" which is not what you want,
You're right, and I fixed that in a reply to Atila.
On 7/30/2018 7:20 AM, Atila Neves wrote:
--
extern (C++, ns) { int foo() { return 1; } }
mixin template X()
{
extern (C++, ns) { int bar() { return 2; } }
}
mixin X!() x;
---
void main() {
pragma(msg, __traits(allMembers, ns));
foo;
bar;
}
$ dmd foo.d
tuple("foo")
On 7/30/2018 1:05 PM, Walter Bright wrote:
I'll look into this.
Check this:
---
extern (C++, ns) { int foo(); }
mixin template X() { extern (C++, ns) int bar(); }
mixin X!() x;
alias bar = x.ns.bar;
void main() {
foo();
bar();
pragma(msg, foo.mangleof);
pragma(msg
On 7/30/2018 6:45 AM, Atila Neves wrote:
On Friday, 27 July 2018 at 22:50:20 UTC, Walter Bright wrote:
On 7/27/2018 10:28 AM, Atila Neves wrote:
But all I'm trying to do here is tell the D compiler how to mangle symbols.
Namespaces have semantic implications, too, such as overload
On 7/30/2018 6:47 AM, Atila Neves wrote:
As mentioned in the original post, the gathering is going to be incredibly
annoying
If you did it manually, sure. But altering the translator to do it?
and I suspect I'll run into problems with macros.
I thought you were running the preprocessor
On 7/29/2018 8:05 PM, Manu wrote:
ab.d
--
module ab;
extern(C++, "ab") void foo();
cd.d
--
module cd;
extern(C++, "cd") void foo();
Perfect!
extern(C++, ab) void foo();
extern(C++, cd) void foo();
Perfect!
struct S1 { extern(C++, ns) void foo(); } alias foo = S1.ns.foo;
601 - 700 of 15506 matches
Mail list logo
