D classes are distinct from structs because they are intended to
be bound to a reference (pointer) and not addressed as a value
(inline/copying).
But for efficiency reasons, scoped classes can stack-allocate,
but my understanding is that the compiler can still allocate it
on the GC heap? So
On Wednesday, 2 June 2021 at 10:17:52 UTC, drug wrote:
Usually 1 million of items aren't visible at once. Also there
is opinion that total redrawing can be more efficient than
caching because of making a decision what to cache and what not
can be very complex.
Depends on the application.
My
On Wednesday, 2 June 2021 at 09:37:10 UTC, drug wrote:
02.06.2021 00:47, Ola Fosheim Grøstad пишет:
I tried retained and immediate GUI, both fail (imho) for my use
case - large data set of 1M+ heterogeneous items.
Depends on the data, I guess, if they are all visible at once
then you
On Wednesday, 2 June 2021 at 01:29:51 UTC, cc wrote:
It's 2021 and I'm still waiting for parent selectors. Even
:has() isn't implemented by anything yet.
I think that is because :has() is Selectors Level 4, which is a
working draft, so not a standard yet.
On Tuesday, 1 June 2021 at 23:42:58 UTC, someone wrote:
On Tuesday, 1 June 2021 at 23:16:04 UTC, Ola Fosheim Grøstad
wrote:
Possibly. Yet, Skia release notes keep mentioning hardware
related themes. I guess that could be your canary (wait until
release notes no longer list hardware related
On Tuesday, 1 June 2021 at 22:52:41 UTC, Adam D. Ruppe wrote:
On Tuesday, 1 June 2021 at 22:39:08 UTC, Ola Fosheim Grøstad
wrote:
Yes, it does. You get lots of graphic context switches and
poor render-caching performance.
no not really.
you'd have to be really incompetent to do it this
On Tuesday, 1 June 2021 at 22:50:49 UTC, someone wrote:
I noticed and struck me was the responsiveness of the GUI:
snappy as hell compared to the usual Windows 7 machines we
dealt with at the time, and, I mean snappy as hell **without**
customizing it disabling animations and the like, this
On Tuesday, 1 June 2021 at 22:13:08 UTC, Adam D. Ruppe wrote:
On Tuesday, 1 June 2021 at 21:47:38 UTC, Ola Fosheim Grøstad
wrote:
Right now, drag-and-drop is not as easily supported in browser
UIs though. That is an argument for using native UI.
eh web drag and drop isn't half bad at all.
On Tuesday, 1 June 2021 at 20:56:05 UTC, someone wrote:
Now think for a instant, that you choose D for performance so
you expect it to be fast, and you write the hello world app to
begin with, and you fire-up a full-framework like Electron or
the like just to give you basic GUI controls.
On Tuesday, 1 June 2021 at 20:20:34 UTC, Ola Fosheim Grøstad
wrote:
Web components are becoming a reality, it essentially means
Turns out Microsoft has a UI component library for browsers,
looks interesting:
https://www.fast.design/
On Tuesday, 1 June 2021 at 16:40:22 UTC, IGotD- wrote:
This is also my observation. Browser UI is on the way to take
over. Advantages are that they are easy to remote, meaning if
you have network connection you can run it on another device.
Yes, browsers are making X11 obsolete...
You can
On Tuesday, 1 June 2021 at 15:38:51 UTC, someone wrote:
It is a mature field, they peaked in the late 90s early 00s.
What came afterwards was mainly decoration/cosmetics because
the hardware evolved to being able to handle it. But the
concepts, what a combo-box is, how it works, etc, remained
On Tuesday, 1 June 2021 at 03:16:05 UTC, someone wrote:
Skia developed by google for C++ using openGL
I think it uses Metal, OpenGL ES, translation layer to OpenGL and
Direct X, backend for Vulkan (but Vulkan hardware drivers
apparently tend to be buggy). Also a build for webassembly.
It
On Tuesday, 1 June 2021 at 10:11:25 UTC, evilrat wrote:
Another issue is that these hobby projects are not state of the
art solutions, they stuck in early 90's (ok, maybe late 90's),
where the rest of the world using different architectures and
approaches that was evolved several times from
On Sunday, 30 May 2021 at 17:46:16 UTC, btiffin wrote:
21 Pilots, Outside
https://www.youtube.com/watch?v=m2w6GkV3U6Q
On note, "Kids'll try to take my vibes. Or am I on the
outside?"
Outro: "Little did they know, they can't touch me. I'm VIBIN',
VIBIN'."
*Sigrid* : **«Don't Kill My
On Sunday, 30 May 2021 at 12:09:22 UTC, cc wrote:
This is overkill for any reasonable application, but I've
always wanted to design a whole UI framework in OpenGL, just
for the novelty of it. I always end up having to reinvent the
wheel for UI elements in my projects anyway.
On Thursday, 27 May 2021 at 19:39:15 UTC, Ozan Sueel wrote:
Hi
I think about writing apps vor ChromeOS, but before running in
a death end, I ask by myself, is D a good choice for this
approach?
I gather it is exactly the same situation as for Android, or?
On Tuesday, 25 May 2021 at 17:55:17 UTC, Ola Fosheim Grostad
wrote:
Is it possible to use a template to write a "function" that
provides initialized stack allocated memory (alloca)? Maybe I
would have to use mixin?
Nevermind, I've realized that I only need a way to force a
function to be
On Saturday, 22 May 2021 at 13:26:38 UTC, sighoya wrote:
But the more general problem in D are not features per se, but
how they are composed of.
For instance: Why no AST macros instead of string mixins,
templates, mixin templates and alias?
All these forms could be special ast macros.
I
On Tuesday, 4 May 2021 at 14:18:30 UTC, Ola Fosheim Grøstad wrote:
On Tuesday, 4 May 2021 at 13:58:59 UTC, Steven Schveighoffer
wrote:
Yeah, I wasn't aware of the more general usage, I thought it
was always a pointer adjustment. But I also am not steeped in
the terminology, just parroting what
On Tuesday, 4 May 2021 at 13:58:59 UTC, Steven Schveighoffer
wrote:
Yeah, I wasn't aware of the more general usage, I thought it
was always a pointer adjustment. But I also am not steeped in
the terminology, just parroting what I've heard.
My understanding is that a thunk is the code object
On Saturday, 1 May 2021 at 16:06:05 UTC, Steven Schveighoffer
wrote:
An interface cast involves a thunk (constant pointer
adjustment) to get to the interface/object
Yes, but it isn't a https://en.wikipedia.org/wiki/Thunk ?
On Tuesday, 4 May 2021 at 01:20:15 UTC, Q. Schroll wrote:
On Saturday, 1 May 2021 at 06:17:36 UTC, Mike Parker wrote:
On Saturday, 1 May 2021 at 04:55:10 UTC, frame wrote:
I always thought as long as an object implements an
interface, it should be able to cast it from a void* if it
really
On Wednesday, 27 January 2021 at 20:21:02 UTC, Kagamin wrote:
You can define a symbol that will conflict with GC and prevent
linking with it.
That was an interesting thought! Maybe that could be a first step.
It didn't occur to me that I could sabotage the usage of GC. :-D
On Tuesday, 26 January 2021 at 16:08:15 UTC, Steven Schveighoffer
wrote:
std.traits.hasAliasing?
I guess, but it will limit me too much. I should accept Element
types that manage their own memory and has pointers to sub-ojects
that don't point to GC memory. But I guess that would require a
On Tuesday, 26 January 2021 at 15:30:09 UTC, Steven Schveighoffer
wrote:
The only way to ensure the GC isn't used is with betterC. Even
with @nogc tag on main, the GC could be used in static ctors,
and casting function pointers/etc.
Yes, @nogc is not strong enough... It is for a container
Is there some way for library authors to test whether a GC is
present at compile time? @nogc just means that my code does not
depend on a GC, but it doesn't tell the compiler that my code is
incompatible with GC.
I want to compute pointers in a way that is not scannable by a
conservative
On Tuesday, 19 January 2021 at 13:41:33 UTC, ddcovery wrote:
(so I really don't understand your somewhat over-acted
answer... maybe I need to read all the threads to understand
your discomfort. In any case, accept my forgiveness if I have
been able to bother you).
Forgot to answer, maybe I
On Tuesday, 19 January 2021 at 13:41:33 UTC, ddcovery wrote:
That you want GC to work efficiently seems great to me... but
at least we agree that D memory management is (and must be) GC
based (so I really don't understand your somewhat over-acted
answer... maybe I need to read all the threads
On Tuesday, 19 January 2021 at 10:43:45 UTC, Ola Fosheim Grøstad
wrote:
On Tuesday, 19 January 2021 at 10:36:13 UTC, ddcovery wrote:
GC if D is not enough for you), but think about the thousands
of experienced developers that where looking for something
mature to work with and found that D was
On Tuesday, 19 January 2021 at 10:36:13 UTC, ddcovery wrote:
GC if D is not enough for you), but think about the thousands
of experienced developers that where looking for something
mature to work with and found that D was not an option.
And that's the point. The vast majority of
On Tuesday, 19 January 2021 at 06:14:52 UTC, Imperatorn wrote:
What adjustments to the language would be needed in your
opinion?
I've mentioned them in connection with various approaches I've
suggested. Depends on what area you want to improve.
In short (off the top of my head, maybe more
On Monday, 18 January 2021 at 15:18:40 UTC, aberba wrote:
1). You're not a minority at all. System programming is also
vast so having a GC (especially D's special kind of GC) is
nothing alien in System programming. If you look out there,
This is not true, and you know it.
There is nothing
On Monday, 18 January 2021 at 13:14:16 UTC, Arafel wrote:
I must be in the minority here because one of the reasons why I
started using D was precisely because it HAS a GC with full
support. I wouldn't even have considered it if it hadn't.
You are probably not in a minority among those that
On Monday, 18 January 2021 at 12:17:24 UTC, aberba wrote:
If you read the Origin of D book, you would see that the GC was
a desire thing when D was designed probably due to how useful
it is for ... as said, 90% or so of software development. So at
this point, fighting the GC isn't (in my
On Monday, 18 January 2021 at 11:43:20 UTC, aberba wrote:
Nevertheless, GC in D isn't going anywhere. And if the approach
for writing nogc code in D doesn't cut it, then I'm not what
else will.
As long as that attitude prevails, D will be going nowhere as
well.
On Saturday, 16 January 2021 at 00:20:16 UTC, Guillaume Piolat
wrote:
It's certainly true that in team dynamics, without any reward,
efficiency can be victim to a tragedy of commons.
Well, any software invariant is harder to hold if the
shareholders don't care.
(be it "being fast", or "being
On Friday, 15 January 2021 at 22:13:01 UTC, Max Haughton wrote:
I think the way forward is some robust move semantics and
analysis like Rust. I suppose ideally we would have some kind
of hidden ARC behind the scenes but I don't know how that would
play with structs.
If they are heap
On Friday, 15 January 2021 at 21:18:55 UTC, aberba wrote:
TL;DR:
In summation, the garbage collection system is a robust part
of Unreal Engine that affords C++ programmers a lot of safety
from memory leaks, as well as convenience. With this
high-level discussion, I was aiming to introduce
On Friday, 15 January 2021 at 21:15:29 UTC, aberba wrote:
Isn't it more theoretical/imaginary/hypothetical than something
really measured from a real-world use case? Almost all large
software use cases I've seen used mix and match.
No?! Chrome has a garbage collector because JavaScript
On Friday, 15 January 2021 at 19:37:12 UTC, Guillaume Piolat
wrote:
A small GC heap is sufficient.
There is this blog post where there was a quantitative measure
of the sub-1ms D GC heap size.
That's ok for a small game, but not for applications that grow
over time or projects where the
On Friday, 15 January 2021 at 18:43:44 UTC, Guillaume Piolat
wrote:
Calling collect() isn't very good, it's way better to ensure
the GC heap is relatively small, hence easy to traverse.
You can use -gc=profile for this (noting that things that can't
contain pointer, such as ubyte[], scan way
On Friday, 15 January 2021 at 16:26:59 UTC, Guillaume Piolat
wrote:
Until someone can describe a strategy that works for a full
application, e.g. an animation-editor or something like that,
it is really difficult to understand what is meant by it.
Personal examples:
- The game Vibrant uses
On Friday, 15 January 2021 at 16:21:43 UTC, jmh530 wrote:
On Friday, 15 January 2021 at 15:36:37 UTC, Ola Fosheim Grøstad
wrote:
The library smart pointers would make it difficult to interact
with existing D GC code though.
Yes. So it would be better to do it automatically in the compiler
On Friday, 15 January 2021 at 15:50:59 UTC, Guillaume Piolat
wrote:
On Friday, 15 January 2021 at 11:11:14 UTC, Mike Parker wrote:
That's the whole point of being able to mix and match. Anyone
avoiding the GC completely is missing it (unless they really,
really, must be GC-less).
+1
mix
On Friday, 15 January 2021 at 15:48:07 UTC, welkam wrote:
On Friday, 15 January 2021 at 14:35:55 UTC, Ola Fosheim Grøstad
wrote:
improved with precise collection
Precise GC is slower than default GC.
D does not have a fully precise GC. The "precise" collector still
scans things
On Friday, 15 January 2021 at 15:20:05 UTC, jmh530 wrote:
Hypothetically, would it be possible for users to supply their
own garbage collector that uses write barriers?
Yes. You could translate Google Chrome's Oilpan to D. It uses
library smart pointers for dirty-marking. But it requires you
On Friday, 15 January 2021 at 15:18:31 UTC, IGotD- wrote:
Bump the pointer is a very fast way to allocate memory but what
is more interesting is what happens when you return the memory.
What does the allocator do with chunks of free memory? Does it
put it in a free list, does it merge chunks?
On Friday, 15 January 2021 at 14:59:18 UTC, Ola Fosheim Grøstad
wrote:
On Friday, 15 January 2021 at 14:50:00 UTC, welkam wrote:
avoid redundant pointers. For instance, a type for telling the
compiler that a pointer is non-owning.
I guess "non-owning" is the wrong term. I mean pointers that
On Friday, 15 January 2021 at 14:50:00 UTC, welkam wrote:
The reasoning of why we do not implement write barriers is that
it will hurt low level programming. But I feel like if we drew
a ven diagram of people who rely on GC and those who do a lot
of writes trough a pointer we would get almost
On Friday, 15 January 2021 at 14:24:40 UTC, welkam wrote:
You can use GC with D compiler by passing -lowmem flag. I didnt
measure but I heard it can increase compilation time by 3x.
Thanks for the info. 3x is a lot though, maybe it could be
improved with precise collection, but I assume that
On Friday, 15 January 2021 at 11:11:14 UTC, Mike Parker wrote:
That's the whole point of being able to mix and match. Anyone
avoiding the GC completely is missing it (unless they really,
really, must be GC-less).
Has DMD switched to using the GC as the default?
On Friday, 15 January 2021 at 07:35:00 UTC, H. S. Teoh wrote:
To be fair, the GC *has* improved over the years. Just not as
quickly as people would like, but it *has* improved.
It cannot improve enough as a global collector without write
barriers. No language has been able to do this.
On Thursday, 14 January 2021 at 18:10:43 UTC, mw wrote:
Python's `del` isn't guaranteed to free the memory, that's what
Fair point, but I was thinking of the C interop interface. You
can create your own wrapper (e.g. numpy) and do manual memory
management, but it isn't something people want
On Thursday, 14 January 2021 at 13:05:31 UTC, sighoya wrote:
But this is already the case for C++ and Rust. Remembering the
days back developing in C++ there were a huge amount of memory
deallocation side effects because opencv's memory management
differs from qt's memory management.
The
On Thursday, 14 January 2021 at 13:16:16 UTC, Ola Fosheim Grøstad
wrote:
1. Use "shared" to prevent GC allocated memory from entering
other threads and switch to thread local GC. Then use ARC for
shared.
2. Redefine language semantics/type system for a different GC
model. This will break
On Thursday, 14 January 2021 at 13:10:14 UTC, sighoya wrote:
On Thursday, 14 January 2021 at 13:08:06 UTC, Ola Fosheim
Grøstad wrote:
Because Java has a well defined virtual machine with lots of
restrictions.
So you're insisting this isn't possible in D?
It isn't possible in a meaningful
On Thursday, 14 January 2021 at 13:01:04 UTC, sighoya wrote:
Why not offering more than one just as it is the case in Java?
The advantage hereby is to adapt the GC algorithm after the
program was compiled, so you can reuse the same program with
different GC algorithms.
Because Java has a
On Thursday, 14 January 2021 at 10:28:13 UTC, Basile B. wrote:
Semi serious answer:
In the domain of hoby-ism and small companies programmers that
work with statically typed languages all believe that they are
super hero in the domain of memory managment. When they see
"GC" they think that
On Thursday, 14 January 2021 at 10:05:51 UTC, Guillaume Piolat
wrote:
On Wednesday, 13 January 2021 at 18:58:56 UTC, Marcone wrote:
I've always heard programmers complain about Garbage Collector
GC. But I never understood why they complain. What's bad about
GC?
Languages where the GC usage
On Thursday, 14 January 2021 at 00:37:29 UTC, mw wrote:
ok, what I really mean is:
... in other "(more popular) languages (than D, and directly
supported by the language & std library only)" ...
Well, even Python supports both, if you want to, so... I suppose
you mean system level
On Wednesday, 13 January 2021 at 21:56:58 UTC, mw wrote:
I think this flexibility to mix GC & manual memory management
is very unique in D. Actually I'm not sure if it can be done in
other languages at all.
It sure can. Most AOT languages that provide GC also provide
C-interfaces and manual
On Wednesday, 13 January 2021 at 18:58:56 UTC, Marcone wrote:
I've always heard programmers complain about Garbage Collector
GC. But I never understood why they complain. What's bad about
GC?
tsbockman gave a good answer.
In short:
- You need to design the language for GC for it to be a
On Tuesday, 12 January 2021 at 21:38:59 UTC, sighoya wrote:
What about this?
No magic, but I don't know the performance impact.
```
import std.meta;
import std.conv;
template same(Types...)
{
static if (Types.length >= 2)
{
static if (is(Types[0] == Types[$ - 1]))
{
Ok, so I now have this, but I think maybe the switch could be
turned into a static array by an reinterpret cast of
"[0]"? I would assume the layout would typically be
"expand_field_0, expand_field_1 etc...
template Tuple(Types...){
template same(){
static foreach (i, dummy;
On Monday, 11 January 2021 at 20:52:25 UTC, Paul Backus wrote:
All of what you're saying applies equally well to any struct
type as it does to tuples.
Sure.
It sounds like what you really want is for D *in general* to
have head-const, for all types. So there's no reason to force
it on
On Monday, 11 January 2021 at 19:25:06 UTC, Paul Backus wrote:
I agree that immutability has benefits, but I don't see why
tuples should be singled out for special treatment in this
regard.
Oh, and another reason is that scalars can usually be passed by
value with impunity, but you might
On Monday, 11 January 2021 at 19:25:06 UTC, Paul Backus wrote:
On Monday, 11 January 2021 at 18:02:19 UTC, Ola Fosheim Grøstad
wrote:
On Monday, 11 January 2021 at 17:48:13 UTC, Paul Backus wrote:
Why? I'd say that an `immutable(Tuple)` should be immutable,
and a `Tuple` should be mutable, as
On Monday, 11 January 2021 at 17:48:13 UTC, Paul Backus wrote:
Why? I'd say that an `immutable(Tuple)` should be immutable,
and a `Tuple` should be mutable, as is the case with literally
every other type in D.
Tuples are usually immutable, it brings more correctness.
On Monday, 11 January 2021 at 16:40:53 UTC, Ali Çehreli wrote:
Yes. Earlier C++ string implementations used reference
counting, which caused multi-threading complications; so, many
implementations switched to copying.
Ah, I guess I've never used std::string for anything that
requires speed.
On Monday, 11 January 2021 at 14:53:08 UTC, Ola Fosheim Grøstad
wrote:
On Monday, 11 January 2021 at 14:51:29 UTC, Ola Fosheim Grøstad
wrote:
On Monday, 11 January 2021 at 14:03:39 UTC, Paul Backus wrote:
alias expand this;
Hm... this does not allow me protect the fields from being
On Monday, 11 January 2021 at 15:23:23 UTC, Ola Fosheim Grøstad
wrote:
On Monday, 11 January 2021 at 14:12:57 UTC, zack wrote:
A beginner question: How to pass strings properly to functions
in D?
Is there any allocation going on if just use a function as
"myPrint"? In C++ I have often seen
On Monday, 11 January 2021 at 14:12:57 UTC, zack wrote:
A beginner question: How to pass strings properly to functions
in D?
Is there any allocation going on if just use a function as
"myPrint"? In C++ I have often seen calls where one just passes
a reference/const reference to a string to
On Monday, 11 January 2021 at 14:03:39 UTC, Paul Backus wrote:
alias expand this;
Hm... this does not allow me protect the fields from being
changed. I also cannot use const since it is transitive and would
make it impossible to return two references to mutable objects?
Basically, the
On Monday, 11 January 2021 at 14:51:29 UTC, Ola Fosheim Grøstad
wrote:
On Monday, 11 January 2021 at 14:03:39 UTC, Paul Backus wrote:
alias expand this;
Hm... this does not allow me protect the fields from being
changed. I also cannot use const since it is transitive and
would make it
On Monday, 11 January 2021 at 14:03:39 UTC, Paul Backus wrote:
On Monday, 11 January 2021 at 09:42:39 UTC, Ola Fosheim Grøstad
wrote:
On Monday, 11 January 2021 at 05:59:03 UTC, Paul Backus wrote:
You can just fall back to `alias expand this` like Phobos's
Tuple does in this case. No compiler
On Monday, 11 January 2021 at 09:42:39 UTC, Ola Fosheim Grøstad
wrote:
I though maybe it would be nice in general to be able to create
static indexed type by having a special field name pattern, but
I will have a another look at staticMap (I don't really want
the full staticMap into object.d
On Monday, 11 January 2021 at 05:59:03 UTC, Paul Backus wrote:
static if (allSameType) {
auto opIndex(size_t i) {
switch (i) {
static foreach (j; 0 .. Types.length) {
case j: return this.expand[j];
}
default: assert(0); // or throw
I want to create my own Tuple type, and I don't like the messy
implementation of the one in D's standard lib, or the one in
Clang++'s standard lib. The concept is very simple so it is
disheartening if it cannot be done in a simple way that does not
impact compile times... :-/
The
On Wednesday, 6 January 2021 at 21:27:59 UTC, H. S. Teoh wrote:
It must be unique because different functions may return
different sets of error codes. If these sets overlap, then once
the error propagates up the call stack it becomes ambiguous
which error it is.
I don't think this is the
On Tuesday, 5 January 2021 at 21:46:46 UTC, H. S. Teoh wrote:
implemented, rather than the concept of exceptions itself. If
we implement Sutter's proposal, or something similar suitably
adapted to D, it would eliminate the runtime overhead, solve
the @nogc exceptions issue, and still support
On Tuesday, 5 January 2021 at 22:01:08 UTC, Ola Fosheim Grøstad
wrote:
Also, I think this is better determined using whole program
optimization, the chosen integer bit pattern used for
propagating errors has performance implications. The most
freguently thrown/tested value should be the one
On Tuesday, 5 January 2021 at 18:23:25 UTC, sighoya wrote:
No error handling model was the HIT and will never be,
therefore I would recommend to leave things as they are and to
develop alternatives and not to replace existing ones.
Or implement C++ exceptions, so that D can catch C++
On Friday, 1 January 2021 at 18:00:57 UTC, SealabJaster wrote:
Meanwhile I believe C++ (keep in mind I very rarely touch or
look at C++) already has a standard allocator interface that
parts of the STL (and I assume libraries, when/if they care)
are able to use? I'm unaware of the issues it
On Friday, 1 January 2021 at 16:23:45 UTC, SealabJaster wrote:
Slightly off but also on topic but, has there been any general
consensus yet around standard pointer types (e.g. shared_ptr)
and standard allocator-aware data structures, or just in
general any discussions around non-GC memory
On Friday, 1 January 2021 at 15:01:15 UTC, RSY wrote:
one big move would be to finally put the allocators out of
std.experimental, and finally embrace this everywhere (just
like ziglang)
I am bit torn on this, the less the compiler knows about
allocation strategies, the less opportunity
On Thursday, 31 December 2020 at 19:27:23 UTC, Sebastiaan Koppe
wrote:
On Thursday, 31 December 2020 at 16:03:54 UTC, Ola Fosheim
Grøstad wrote:
What would you like to see?
For shared to mean something.
Stackless coroutines.
Compile-time lifetime management, i.e. better ways to define
On Thursday, 31 December 2020 at 18:13:40 UTC, Imperatorn wrote:
I was a bit unclear. I meant features as in built in language
constructs etc, not necessarily like keywords and so on.
You mean like associative arrays and dynamic arrays? If so then I
guess people have different taste, I think
On Thursday, 31 December 2020 at 14:56:37 UTC, Sebastiaan Koppe
wrote:
It could take a few years indeed, but what will D do in that
same time window?
What would you like to see?
On Wednesday, 30 December 2020 at 21:17:25 UTC, sighoya wrote:
On Wednesday, 30 December 2020 at 21:12:43 UTC, Ola Fosheim
Grøstad wrote:
(which does not work, but maybe there is some other
way to express it?):
See:
https://forum.dlang.org/thread/ooxzbrmbrzpsefiro...@forum.dlang.org?page=1
On Wednesday, 30 December 2020 at 20:42:49 UTC, jmh530 wrote:
You mean like this
struct Foo(T)
{
T x;
}
void foo(T : Foo!V, V)(T x) {
Not quite, "Foo" would be a template parameter, so something like
this (which does not work, but maybe there is some other way to
express it?):
On Wednesday, 30 December 2020 at 19:24:19 UTC, sighoya wrote:
In my eyes, adding proper support for opImplicitCoercion
enables the reuse of interfaces as typeclasses, yielding more
potential for idiomatic development than utilizing C++ concepts
alone.
Not sure what you mean? A D interface
On Wednesday, 30 December 2020 at 18:24:41 UTC, sighoya wrote:
On Wednesday, 30 December 2020 at 14:41:28 UTC, Ola Fosheim
Grøstad wrote:
Most of the statements are wrong too...
"4732 features, but not a single one you actually want": wrong
again, C++20 has features that people would like to
On Wednesday, 30 December 2020 at 14:17:38 UTC, Rekel wrote:
On Tuesday, 29 December 2020 at 16:13:50 UTC, Imperatorn wrote:
https://ibb.co/syQRs9v
I hope I'm not the only one that thinks 'designers and std lib
writers unable to name anything correctly' is kind of ironic.
And don't get me
On Sunday, 6 December 2020 at 14:45:21 UTC, Bruce Carneal wrote:
Well, you could in theory avoid putting owning pointers on the
stack/globals or require that they are registered as gc roots.
Then you don't have to scan the stack. All you need then is
write barriers. IIRC
'shared' with teeth?
On Tuesday, 17 November 2020 at 13:24:03 UTC, Kagamin wrote:
On Saturday, 14 November 2020 at 23:30:58 UTC, Adam D. Ruppe
wrote:
On Saturday, 14 November 2020 at 23:20:55 UTC, Martin wrote:
Is this intentional?
In the current language design, yes.
It's a bug, it breaks data sharing
On Wednesday, 11 November 2020 at 13:30:16 UTC, Simen Kjærås
wrote:
The short answer is 'because that's how we've chosen to define
it'. A more involved answer is that changing every reference is
prohibitively expensive - it would require the equivalent of a
GC collection on every reallocation,
On Tuesday, 10 November 2020 at 01:00:50 UTC, Mark wrote:
I haven't looked into the newest C++. In theory, they might
have added something helpful in the past years.
I guess you could say that the latest version of C++ allows you
to write code that is a little bit less verbose than before.
On Tuesday, 10 November 2020 at 20:32:40 UTC, Paul Backus wrote:
The compiler infers pure, @nogc, nothrow etc. for template
functions automatically. It's actually better if you don't add
them by hand.
Ok, thanks :-).
On Tuesday, 10 November 2020 at 17:09:00 UTC, Paul Backus wrote:
bool between(Value, Bound)(auto ref Value value, auto ref Bound
low, auto ref Bound high)
{
return (low < value) && (value < high);
}
You need `auto ref` because either Bound or Value may have
copying disabled. Because the
101 - 200 of 382 matches
Mail list logo
