On Friday, 24 August 2018 at 13:21:25 UTC, Jonathan M Davis wrote:
I honestly don't see how attempting to divorce druntime from
libc does anything but increase the amount of work that we have
to do and increase the likelihood that basic OS functionality
is going to be buggy, since we will
On Friday, 24 August 2018 at 13:21:25 UTC, Jonathan M Davis wrote:
I think that you're crazy.
No, I just see more potential in D than you do.
Mike
On 24/08/18 13:43, nkm1 wrote:
I think Walter was talking more about "scope (failure) destroy(this)" at
the top of all your structs? I don't know if it has some gotchas, though
(as I don't use RAII in D...).
No, unlike what I suggest, that doesn't work without carefully reviewing
every
On Friday, August 24, 2018 6:05:40 AM MDT Mike Franklin via Digitalmars-d
wrote:
> > You're basically trying to bypass the OS' public API if you're
> > trying to bypass libc.
>
> No I'm trying to bypass libc and use the OS API directly.
And my point is that most OSes consider libc to be their OS
On Friday, 24 August 2018 at 09:52:20 UTC, Walter Bright wrote:
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
I expect it
On Friday, 24 August 2018 at 11:15:21 UTC, Jonathan M Davis wrote:
Linux is the only OS I'm aware of that considers the syscall
layer to be something that anything outside the OS would
normally call.
I think Linux considers system calls the OS API.
Other OSes consider libc to be part of
On Friday, 24 August 2018 at 09:46:08 UTC, Jonathan M Davis wrote:
On Friday, August 24, 2018 2:46:06 AM MDT Dave Jones via
Digitalmars-d wrote:
On Friday, 24 August 2018 at 04:50:34 UTC, Mike Franklin wrote:
> On Friday, 24 August 2018 at 04:12:42 UTC, Jonathan M Davis
> wrote:
>
>
> It's
On Friday, August 24, 2018 4:08:52 AM MDT Shachar Shemesh via Digitalmars-d
wrote:
> On 24/08/18 10:43, FeepingCreature wrote:
> > Have you tried to use the excellent Dustmite tool? It's never failed to
> > reduce a bug for me.
>
> Dustmite might be excellent. I wouldn't know. It cannot swallow
On Friday, August 24, 2018 4:18:31 AM MDT Mike Franklin via Digitalmars-d
wrote:
> On Friday, 24 August 2018 at 09:46:08 UTC, Jonathan M Davis wrote:
> > For any kind of normal operating system, you _have_ to use
> > libc. It's part of the OS. Some pieces could be done without
> > it, but on the
On Friday, 24 August 2018 at 10:16:34 UTC, Shachar Shemesh wrote:
On 23/08/18 15:03, Walter Bright wrote:
So you will excuse me, but I don't think this bug is being
taken as seriously as I think it should.
It is a serious problem. (There are workarounds available,
like using scope(failure).)
On Friday, 24 August 2018 at 09:46:08 UTC, Jonathan M Davis wrote:
For any kind of normal operating system, you _have_ to use
libc. It's part of the OS. Some pieces could be done without
it, but on the whole, you use libc if you want to talk to the
OS. That's just life. The only exceptions
On 23/08/18 15:03, Walter Bright wrote:
So you will excuse me, but I don't think this bug is being taken as
seriously as I think it should.
It is a serious problem. (There are workarounds available, like using
scope(failure).)
I don't think you understand how unworkable this workaround is.
On Friday, 24 August 2018 at 09:58:13 UTC, Walter Bright wrote:
On 8/23/2018 5:02 PM, Nicholas Wilson wrote:
am currently up against a ~thousand headed hydra~ thousand
line function .
Good times :-)
Tell me about it. I'm now wading through its carcass in review. I
will split it up but it
On 24/08/18 10:43, FeepingCreature wrote:
Have you tried to use the excellent Dustmite tool? It's never failed to
reduce a bug for me.
Dustmite might be excellent. I wouldn't know. It cannot swallow the Weka
code base.
Shachar
On Friday, 24 August 2018 at 01:50:53 UTC, Jon Degenhardt wrote:
quality, consistency, completeness
My point is that it's more important to have useful, easy to
change, messy libraries.
If you restrict yourself to whatever is in Phobos then the burden
on core developers is only ever
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 Friday, August 24, 2018 2:46:06 AM MDT Dave Jones via Digitalmars-d
wrote:
> On Friday, 24 August 2018 at 04:50:34 UTC, Mike Franklin wrote:
> > On Friday, 24 August 2018 at 04:12:42 UTC, Jonathan M Davis
> > wrote:
> >
> >
> > It's not a problem for Phobos to depend on the C standard
> >
On Friday, August 24, 2018 1:31:21 AM MDT Shachar Shemesh via Digitalmars-d
wrote:
> > Yeah. We probably should have required that destructors be nothrow and
> > force destructor failures to be treated as Errors.
>
> I'm sorry, but I'm not following your logic.
>
> If you're willing to have an
On Friday, 24 August 2018 at 04:50:34 UTC, Mike Franklin wrote:
On Friday, 24 August 2018 at 04:12:42 UTC, Jonathan M Davis
wrote:
It's not a problem for Phobos to depend on the C standard
library. My goals have to do with making D, the language,
freestanding (a.k.a nimble-D).
If the
On Thursday, 23 August 2018 at 23:27:51 UTC, Walter Bright wrote:
Back to throwing constructors.
1) They are expensive, adding considerable hidden bloat in the
form of finally blocks, one for each constructing field. These
unwinding frames defeat optimization. The concept of "zero-cost
On Friday, 24 August 2018 at 01:57:03 UTC, Shachar Shemesh wrote:
That's strange. Why didn't Shachar just do?
_trustedData[diskIdx] &= NotBitmap(toDistrust);
Answer: Because the compiler decided that it needs to call
_trustedData.opIndexAssign, and then failed the compilation
because
On 24/08/18 05:33, Jonathan M Davis wrote:
Yeah. I've used RAII plenty in D without problems, but the fact remains that
certain uses of it are very broken right now thanks to the constructor
issue. I suspect that Shachar's as negative about this as he is in part
because having RAII go wrong
On Thursday, 23 August 2018 at 06:34:04 UTC, Shachar Shemesh
wrote:
Here's the interesting question, though: is this *going* to
happen?
I didn't know about the issue until you recently brought it up.
--
/Jacob Carlborg
On Friday, 24 August 2018 at 04:12:42 UTC, Jonathan M Davis wrote:
Unless you're trying to argue for folks dropping Phobos, that's
just not going to fly. Phobos uses libc heavily, and it really
can't do what it needs to do without it (e.g. file operations).
Divorcing druntime from libc may
On Thursday, August 23, 2018 7:01:41 PM MDT Mike Franklin via Digitalmars-d
wrote:
> On Friday, 24 August 2018 at 00:58:35 UTC, Guillaume Piolat wrote:
> > D programs tend to use the C runtime directly, and quite a lot
> > of it:
> > https://github.com/search?l=D=%22import+core.stdc%22=Code
>
> I
On Thursday, 23 August 2018 at 23:06:00 UTC, Ethan wrote:
Is that actually true, or would handling exceptions within the
constructor allow one to initialise the object to an invalid
state and thus still follow RAII paradigms correctly?
If you end up needing to check for that uninitialised
On Thursday, 23 August 2018 at 23:27:51 UTC, Walter Bright wrote:
D deals with it via "chained exceptions", which is terrifyingly
difficult to understand. If you believe it is understandable,
just try to understand the various devious test cases in the
test suite.
I don't think that
On 24/08/2018 1:57 PM, Shachar Shemesh wrote:
Consider the following line from the weka code base:
_trustedData.opIndex(diskIdx) &= NotBitmap(toDistrust);
That's strange. Why didn't Shachar just do?
_trustedData[diskIdx] &= NotBitmap(toDistrust);
Answer: Because the
On Friday, 24 August 2018 at 01:57:03 UTC, 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
On Thursday, August 23, 2018 3:31:41 PM MDT Walter Bright via Digitalmars-d
wrote:
> 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
On 23/08/18 23:46, Walter Bright wrote:
In my experience with debugging code, if drilling down to find the cause
of the problem is not done, there is no way to conclude whether whether
it is a compiler bug or a user bug.
(Of course, compiler internal errors are always compiler bugs.)
On Friday, 24 August 2018 at 00:46:14 UTC, Mike Franklin wrote:
It seems, from someone without much historical perspective,
that Phobos was intended to be something like the .Net
Framework for D. Perhaps there are a few fundamentals
(std.algorithm, std.allocator, etc.) to keep, but for the
On Friday, 24 August 2018 at 00:58:35 UTC, Guillaume Piolat wrote:
D programs tend to use the C runtime directly, and quite a lot
of it:
https://github.com/search?l=D=%22import+core.stdc%22=Code
I know. They should get that from
https://github.com/D-Programming-Deimos/libc or perhaps even
On Friday, 24 August 2018 at 00:56:10 UTC, Mike Franklin wrote:
On Friday, 24 August 2018 at 00:53:20 UTC, Guillaume Piolat
wrote:
Do you also mean to reimplement everything related to FILE*?
floating-point parsing and conversion to string?
multithreaded malloc?
Only what's need for
On Friday, 24 August 2018 at 00:53:20 UTC, Guillaume Piolat wrote:
Do you also mean to reimplement everything related to FILE*?
floating-point parsing and conversion to string?
multithreaded malloc?
Only what's need for druntime. That would include multi-threaded
malloc, but not the FILE*
On Friday, 24 August 2018 at 00:47:18 UTC, Mike Franklin wrote:
On Friday, 24 August 2018 at 00:46:14 UTC, Mike Franklin wrote:
But I need it to implement `memcpy` and `memcmp` in D, so we
can remove the dependency on the D standard library :-)
Gah! What a typo. I mean the C standard
On Friday, 24 August 2018 at 00:32:59 UTC, Guillaume Piolat wrote:
For example: why implement AVX in DMD backend? Who are the
users that will be delighted by that? Those interested in
performance already use some other back-end, it's imo a
completely useless development since _no one_ use
On Friday, 24 August 2018 at 00:46:14 UTC, Mike Franklin wrote:
But I need it to implement `memcpy` and `memcmp` in D, so we
can remove the dependency on the D standard library :-)
Gah! What a typo. I mean the C standard library.
On Thursday, 23 August 2018 at 04:46:25 UTC, Eugene Wissner wrote:
But this kind of development doesn't work anymore that well for
commercial customers that aren't (only) interested in research.
From this perspective D becomes over-complicated, half-finished
language. And nobody can tell what
On Thursday, 23 August 2018 at 17:02:12 UTC, Shachar Shemesh
wrote:
How much time or money exactly has Weka spent on getting this
issue and other "critical" bugs fixed?
Weka is paying prominent D developers as contractors. We've had
David Nadlinger and currently employ Johan Engelen. Both
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 08/23/2018 10:11 PM, Walter Bright wrote:
On 8/23/2018 5:55 AM, Steven Schveighoffer wrote:
[...]
I think he means, if the range ITSELF doesn't allow copying, it won't
work with foreach (because foreach makes a copy), but it will work
with opApply.
foreach (ref v; collection)
does
On Thursday, 23 August 2018 at 22:12:17 UTC, David Nadlinger
wrote:
Throwing constructors are fundamental for making RAII work in a
composable fashion.
Is that actually true, or would handling exceptions within the
constructor allow one to initialise the object to an invalid
state and thus
On Thursday, 23 August 2018 at 03:50:44 UTC, Shachar Shemesh
wrote:
On 22/08/18 21:34, Ali wrote:
On Wednesday, 22 August 2018 at 17:42:56 UTC, Joakim wrote:
Pretty positive overall, and the negatives he mentions are
fairly obvious to anyone paying attention.
Yea, I agree, the negatives are
On Thursday, 23 August 2018 at 17:02:12 UTC, Shachar Shemesh
wrote:
On 23/08/18 18:35, Joakim wrote:
[…]
How much time or money exactly has Weka spent on getting this
issue and other "critical" bugs fixed?
Weka is paying prominent D developers as contractors. We've had
David Nadlinger and
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
people relied on it.) I won't allow throwing
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
dding new
'features'.". It may or may not be relevant here.
BTW. on the offtopic note - the thread title doesn't look too
good. Imagine being a newcomer, and the first thread you see on
the forum is titled "D is dead".
Not sure about your taxonomy. There are quite a few peopl
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 Thursday, 23 August 2018 at 10:41:03 UTC, Jonathan M Davis
wrote:
D does have a problem in general of having a lot of great
features that work really well in isolation but don't
necessarily work well in concert (and it doesn't help that some
features have really never been properly
On 8/23/18 12:22 PM, Shachar Shemesh wrote:
On 23/08/18 17:01, Steven Schveighoffer wrote:
I'm not saying all bugs you file will be fixed, but all bugs you
*don't* file will definitely not be fixed.
So far, my experience is that it has about the same chances of being
fixed both ways, and not
On 8/23/18 12:27 PM, Shachar Shemesh wrote:
On 23/08/18 17:01, Steven Schveighoffer wrote:
So interestingly, you are accepting the sockaddr by VALUE.
Indeed. The reason is that I cannot accept them by reference, as then
you wouldn't be able to pass lvalues* in. Another controversial decision
On Thursday, 23 August 2018 at 17:52:54 UTC, bachmeier wrote:
On Thursday, 23 August 2018 at 17:19:41 UTC, Ali wrote:
On Thursday, 23 August 2018 at 16:22:54 UTC, Shachar Shemesh
wrote:
On 23/08/18 17:01, Steven Schveighoffer wrote:
My main job is to develop for Weka, not develop D itself.
On Thu, Aug 23, 2018 at 09:05:53PM +0300, Shachar Shemesh via Digitalmars-d
wrote:
> On 23/08/18 20:57, bachmeier wrote:
> > On Thursday, 23 August 2018 at 17:02:12 UTC, Shachar Shemesh wrote:
> >
> > > If you can, feel free to contact me off-list, and I'm fairly sure
> > > we can get the budget
On Thursday, 23 August 2018 at 18:05:53 UTC, Shachar Shemesh
wrote:
On 23/08/18 20:57, bachmeier wrote:
On Thursday, 23 August 2018 at 17:02:12 UTC, Shachar Shemesh
wrote:
If you can, feel free to contact me off-list, and I'm fairly
sure we can get the budget for you to work on it. The same
On Thursday, August 23, 2018 12:05:53 PM MDT Shachar Shemesh via
Digitalmars-d wrote:
> On 23/08/18 20:57, bachmeier wrote:
> > On Thursday, 23 August 2018 at 17:02:12 UTC, Shachar Shemesh wrote:
> >> If you can, feel free to contact me off-list, and I'm fairly sure we
> >> can get the budget for
On 23/08/18 20:57, bachmeier wrote:
On Thursday, 23 August 2018 at 17:02:12 UTC, Shachar Shemesh wrote:
If you can, feel free to contact me off-list, and I'm fairly sure we
can get the budget for you to work on it. The same goes for anyone
else on this list.
I don't think Kenji will see
On 23/08/18 20:52, bachmeier wrote:
On Thursday, 23 August 2018 at 17:19:41 UTC, Ali wrote:
On Thursday, 23 August 2018 at 16:22:54 UTC, Shachar Shemesh wrote:
On 23/08/18 17:01, Steven Schveighoffer wrote:
My main job is to develop for Weka, not develop D itself.
Weka, at some point, made
On Thursday, 23 August 2018 at 17:02:12 UTC, Shachar Shemesh
wrote:
If you can, feel free to contact me off-list, and I'm fairly
sure we can get the budget for you to work on it. The same goes
for anyone else on this list.
I don't think Kenji will see your message, but he may be able to
On 23/08/18 19:58, RhyS wrote:
A quick question, if Weka did not have the current 300k backlog of code,
what language of choice is more likely to be picked by the team at Weka?
I don't know. Like I said, while the feeling that D has completely lost
its way is fairly universal, the claim
On Thursday, 23 August 2018 at 17:19:41 UTC, Ali wrote:
On Thursday, 23 August 2018 at 16:22:54 UTC, Shachar Shemesh
wrote:
On 23/08/18 17:01, Steven Schveighoffer wrote:
My main job is to develop for Weka, not develop D itself.
Weka, at some point, made the strategic decision to use a non
On Thursday, 23 August 2018 at 17:19:41 UTC, Ali wrote:
On Thursday, 23 August 2018 at 16:22:54 UTC, Shachar Shemesh
wrote:
On 23/08/18 17:01, Steven Schveighoffer wrote:
My main job is to develop for Weka, not develop D itself.
Weka, at some point, made the strategic decision to use a non
On Thursday, 23 August 2018 at 17:02:12 UTC, Shachar Shemesh
wrote:
On 23/08/18 18:35, Joakim wrote:
So your example of a fatal flaw is that D could be 100X faster
at compilation instead of just 10X than most every other
native language out there?! C'mon.
Have you tried Stephan's example
On Thursday, 23 August 2018 at 16:22:54 UTC, Shachar Shemesh
wrote:
On 23/08/18 17:01, Steven Schveighoffer wrote:
My main job is to develop for Weka, not develop D itself.
Weka, at some point, made the strategic decision to use a non
mainstream language
I dont think Weka, have a choice,
On 23/08/18 18:35, Joakim wrote:
So your example of a fatal flaw is that D could be 100X faster at
compilation instead of just 10X than most every other native language
out there?! C'mon.
Have you tried Stephan's example yet?
static foreach(i; 0..16384) {}
Do give it a shot, tell me
On Thursday, 23 August 2018 at 16:22:54 UTC, Shachar Shemesh
wrote:
Waiting for the community to fix a bug in D that is blocking
Weka will get Weka kicked out of the market. There is no value
proposition. We simply have to work faster than that.
Oh, and our code base over 300,000 lines. Don't
On 23/08/18 17:01, Steven Schveighoffer wrote:
So interestingly, you are accepting the sockaddr by VALUE.
Indeed. The reason is that I cannot accept them by reference, as then
you wouldn't be able to pass lvalues in. Another controversial decision
by D.
Had that been C++, I'd definitely
On 23/08/18 17:01, Steven Schveighoffer wrote:
If they are blocking
your work, complain about them loudly, every day. But not filing them
doesn't help anyone.
The economics don't add up.
If a bug is blocking my work, there are two options:
1. I work around it, at which point it is no longer
On Thursday, August 23, 2018 9:03:24 AM MDT Ali via Digitalmars-d wrote:
> RAII is nowadays described as C++ nicest , more important and
> most powerful feature
> D again, missed the opportunity on that one
D was designed to have RAII, and it does. It's just that the implementation
is buggy
On Thursday, 23 August 2018 at 09:26:46 UTC, rikki cattermole
wrote:
On 23/08/2018 9:09 PM, Shachar Shemesh wrote:
functions may be @safe, nothrow, @nogc, pure. If it's a method
it might also be const/inout/immutable, static. The number of
libraries that support all combinations is exactly
On Thursday, 23 August 2018 at 07:37:07 UTC, Iain Buclaw wrote:
On Thursday, 23 August 2018 at 06:58:13 UTC, Joakim wrote:
On Thursday, 23 August 2018 at 03:50:44 UTC, Shachar Shemesh
wrote:
On 22/08/18 21:34, Ali wrote:
On Wednesday, 22 August 2018 at 17:42:56 UTC, Joakim wrote:
Pretty
On Thursday, 23 August 2018 at 09:09:40 UTC, 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.
Well, I'm D hobbyist and of course it's not a perfect
On Thursday, 23 August 2018 at 06:34:01 UTC, nkm1 wrote:
The only real problem with D is that it's a language designed
with
GC in mind, yet there are numerous attempts to use it without
GC.
Also, supporting GC-less programming gets in the way of
improving
D's GC (which is pretty damn bad by
On Thursday, 23 August 2018 at 03:50:44 UTC, Shachar Shemesh
wrote:
To sum it up: fatal flaws + no path to fixing + no push from
the community = inevitable eventual death.
With great regrets,
Shachar
I want to jump in for the sake of someone from the outside coming
in and reading this to
On Thursday, 23 August 2018 at 13:22:45 UTC, Shachar Shemesh
wrote:
Because in D, structs can't inherit,
Forgive me if I'm not helping, but if you are willing to create a
little infrastructure, I think you can create polymorphic structs
with the technique described at
On 8/23/18 9:22 AM, Shachar Shemesh wrote:
On the other hand, look at ConnectedSocket.connect:
https://weka-io.github.io/mecca/docs/mecca/reactor/io/fd/ConnectedSocket.connect.html
Why do I need two forms? What good is that? Why is the second form a
template? Answer: Because in D, structs
On Thursday, 23 August 2018 at 12:03:59 UTC, Walter Bright wrote:
I'd appreciate a list of bugzilla issues you regard as critical
to your operations.
Sorry to weasle in, but
https://issues.dlang.org/show_bug.cgi?id=2043
Sorry for childish behaviour in bugzilla (my last comment), but
this bug
On 24/08/2018 1:22 AM, Shachar Shemesh wrote:
Except what I'd _really_ like to do is for them to be the same thing.
I'd like inheritance. Except I can't do that for structs, and if I
defined SockAddr as a class, I'd mandate allocating it on the GC,
violating the whole point behind writing
On 23/08/18 15:55, Steven Schveighoffer wrote:
This whole thread seems very gloomy and final, but I feel like the tone
does not match in my mind how D is progressing. "Every single one of the
people [at Weka] rushing to defend D at the time has since come around."
Seems like you all have
On 24/08/2018 12:55 AM, Steven Schveighoffer wrote:
I do feel that we need, in general, more developers working on the
compiler itself. So many of the problems need compiler changes, and the
learning curve to me just seems so high to get into it.
It depends, some parts are very easy to get
On 8/23/18 8:03 AM, Walter Bright wrote:
On 8/23/2018 4:31 AM, Shachar Shemesh wrote:
This is in the language spec:
How many people know that without resorting to the specs.
This is a little unfair. It's plainly stated in the documentation for
foreach. Heck, I wrote a C compiler and the
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 23/08/18 14:02, Walter Bright wrote:
On 8/23/2018 2:09 AM, Shachar Shemesh wrote:
functions may be @safe, nothrow, @nogc, pure. If it's a method it
might also be const/inout/immutable, static. The number of libraries
that support all combinations is exactly zero (e.g. - when passing a
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 Thursday, 23 August 2018 at 10:41:03 UTC, Jonathan M Davis
wrote:
Languages pretty much always get more complicated over time,
and unless we're willing to get rid of more stuff, it's
guaranteed to just become more complicated over time rather
than less.
"A designer knows he has achieved
On Thursday, August 23, 2018 3:26:46 AM MDT rikki cattermole via
Digitalmars-d wrote:
> > * Language complexity
> >
> > Raise your hand if you know how a class with both opApply and the
> > get/next/end functions behaves when you pass it to foreach. How about a
> > struct? Does it matter if it
On Thursday, 23 August 2018 at 07:37:07 UTC, Iain Buclaw wrote:
Possible Solution: Make all globals hidden by default unless
'export'.
Same mess as in C++. But there you have -fvisibility=hidden at
least to fix it.
Side effects: Everyone will be spending weeks to months fixing
their
On 23/08/2018 9:09 PM, 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.
Here's an incredibly partial list:
* Features not playing well together.
On Thursday, 23 August 2018 at 07:00:01 UTC, Iain Buclaw wrote:
On Thursday, 23 August 2018 at 06:34:04 UTC, Shachar Shemesh
wrote:
On 23/08/18 09:17, Jacob Carlborg wrote:
I don't see why we just can't add support for scoped lazy
parameters. It's already in the language just with a
different
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.
Here's an incredibly partial list:
* Features not playing well together.
Despite what Joakim seems to think, I've
On 23/08/2018 7:47 PM, Eugene Wissner wrote:
You can probably solve it like haskell does: Export all symbols by default.
So this module exports everything:
---
module MyModule where
-- My code goes here
---
this one not:
---
module MyModule (symbol1, symbol2) where
On Thursday, 23 August 2018 at 07:37:07 UTC, Iain Buclaw wrote:
Symptom: The compiler can't discard unused symbols at compile
time, and so it will spend a lot of time pointlessly optimising
code.
Problem: D has no notion of symbol visibility.
Possible Solution: Make all globals hidden by
101 - 200 of 243 matches
Mail list logo
