On Friday, 14 September 2018 at 23:08:34 UTC, Nicholas Wilson
wrote:
On Friday, 14 September 2018 at 13:41:40 UTC, Mike Parker wrote:
DIP 1015, "Deprecation and removal of implicit conversion from
integer and character literals to bool", is now ready for
Final Review. This is a last chance for
On Saturday, 15 September 2018 at 20:07:06 UTC, Steven
Schveighoffer wrote:
Looks pretty good to me. The only question I have is on this
part:
enum YesNo : bool { no, yes } // Existing implementation: OK
// After stage 1: Deprecation
warning
On Wednesday, 5 September 2018 at 07:00:49 UTC, Joakim wrote:
The D foundation is planning to add a way for us to pay for
changes we'd like to see in D and its ecosystem, rather than
having to code everything we need ourselves or find and hire a
D dev to do it:
"[W]e’re going to add a page to
On Thursday, 6 September 2018 at 01:24:35 UTC, Laeeth Isharc
wrote:
$500.00 to fix these three together - they may well be
essentially the same bug:
https://issues.dlang.org/show_bug.cgi?id=19179
https://issues.dlang.org/show_bug.cgi?id=5570
https://issues.dlang.org/show_bug.cgi?id=13957
Ac
On Wednesday, 5 September 2018 at 18:41:15 UTC, Jacob Carlborg
wrote:
On 2018-09-04 06:03, Mike Franklin wrote:
For that it needs to support all the features as classes do
today. In that case, what would be the difference compared to
classes?
Indeed, the idea is that structs, with a few add
On Tuesday, 4 September 2018 at 03:38:41 UTC, Nick Sabalausky
(Abscissa) wrote:
We have classes and structs:
Classes:
- Default Storage: GC Heap
- Indirection Overhead: Yes
- Semantics: Reference
- Passed By: Copying the Data's Address
Structs:
- Default Storage: Stack
- Indirection Overhead: N
On Friday, 24 August 2018 at 22:52:07 UTC, Steven Schveighoffer
wrote:
I really don't want to see dlang have to maintain posix system
calls on all supported OSes when that's already being done for
us.
Windows makes this simpler -- the system calls are separate
from the C runtime. It would b
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 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 the
On Friday, 24 August 2018 at 06:41:35 UTC, Jonathan Marler wrote:
One idea is we could add this template to `object.d`. This
would allow it to be used from any module that uses druntime
without having to import it first. The template itself is also
very friendly to "bloat" because it only ha
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 I'm
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 hel
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&q=%22import+core.stdc%22&type=Code
I know. They should get that from
https://github.com/D-Programming-Deimos/libc or perhaps
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* st
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 D_
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 23:36:07 UTC, Chris M. wrote:
Heck, now that I'm looking at it, DIP25 seems like a more
restricted form of Rust's lifetimes. Let me know if I'm just
completely wrong about this, but
I think DIP 25 is analogous to Problem #3 for Rust's Non-Lexical
Lifetimes:
h
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
https://theartofmachi
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, 23 August 2018 at 03:50:44 UTC, Shachar Shemesh
wrote:
And it's not just Weka. I've had a chance to talk in private to
some other developers. Quite a lot have serious, fundamental
issues with the language. You will notice none of them speaks
up on this thread.
They don't see th
On Saturday, 18 August 2018 at 13:33:43 UTC, Andrei Alexandrescu
wrote:
where are the best leverage points in making the D language
more successful.
I'm still internalizing the article and thinking about how it
applies to the "D system", but I've always thought facilitating
the incorporatio
On Wednesday, 22 August 2018 at 11:02:00 UTC, Seb wrote:
No, it's behind a flag, so you can't really say that we're
shipping it as "production ready release".
The changes to Phobos are not behind a flag. We're making
changes to Phobos in the release branch to accommodate a
draft/experimenta
On Wednesday, 22 August 2018 at 09:23:26 UTC, Walter Bright wrote:
dip1000 has been around for two years, and its predecessor
dip25 several years now. Plenty of time for anyone to comment
and/or propose something better.
Part of the problem is that the implementation keeps changing
without k
On Wednesday, 22 August 2018 at 09:23:26 UTC, Walter Bright wrote:
I want to ensure Atila is successful with this. But that means
Phobos has to compile with dip1000. So I need to make it work.
There's a good chance you'll get your PR merged when it's
documented and vetted, then you'll be able
On Wednesday, 22 August 2018 at 09:23:26 UTC, Walter Bright 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...)
On Wednesday, 22 August 2018 at 05:39:05 UTC, Mike Franklin wrote:
I understand that Walter's DIPs have been put through the
process just like the others, but with regard to the specific
issue in this thread
(https://issues.dlang.org/show_bug.cgi?id=19097), the
accompanying PR (https://github
On Wednesday, 22 August 2018 at 05:04:25 UTC, Mike Parker wrote:
Whatever the status of DIP 1000, I would point out that that
one of Walter's DIPs is in Community Review right now after
sitting in the PR queue in Draft Review for a while. Once this
review stage is done, it will go back into th
On Wednesday, 22 August 2018 at 04:49:15 UTC, Mike Franklin wrote:
It is hypocritical an arrogant to believe that only our ideas
have flaws and require scrutiny.
Sorry, that was poorly stated and conveyed the wrong intent. It
should read:
It is hypocritical an arrogant to believe that only
On Wednesday, 22 August 2018 at 04:23:52 UTC, Jonathan M Davis
wrote:
The reality of the matter is that the DIP system is a formal
way to propose language changes in order to convince Walter and
Andrei that those changes should be implemented, whereas if
Walter or Andrei writes the DIP, they'
On Wednesday, 22 August 2018 at 01:07:28 UTC, Mike Franklin wrote:
But what bothers me the most...
Something else that rubs me the wrong way is that DIP 1000 is
currently in a status of `DRAFT`:
https://github.com/dlang/DIPs/blob/master/DIPs/README.md
What the heck is going on here? We'r
On Tuesday, 21 August 2018 at 21:17:25 UTC, Atila Neves wrote:
I don't have merge rights. I took a look anyway and it mostly
looks ok, but I'm not familiar enough with that part of the
codebase.
It's not the implementation that's preventing it from being
merged. It's the idea itself, weak r
On Friday, 17 August 2018 at 16:42:08 UTC, Martin Nowak wrote:
- help to test, debug, and fix the experimental lld/mingw
toolchain
(https://dlang.org/changelog/2.079.0.html#lld_mingw)
I'd be happy to test this, but where are the instructions for
using it?Do I need to uninstall Visual S
On Friday, 17 August 2018 at 16:42:08 UTC, Martin Nowak wrote:
On 08/17/2018 01:24 AM, Mike Franklin wrote:
Well from my point of view the most important outstanding
Windows tasks are:
[...]
Thanks. I'm currently working on getting build.d to work on
Windows.
https://github.com/dlang/dm
On Friday, 17 August 2018 at 16:00:26 UTC, 12345swordy wrote:
On Friday, 17 August 2018 at 15:27:22 UTC, Mike Franklin wrote:
I actually started writing a DIP for this about a year ago,
but I need to pick my battles.
Mike
Is it on github?
Alex
No,but here are some notes I found in my file
On Friday, 17 August 2018 at 14:26:07 UTC, H. S. Teoh wrote:
On Fri, Aug 17, 2018 at 01:50:32AM -0600, Jonathan M Davis via
Digitalmars-d wrote: [...]
Honestly, the reality of the matter is that @safe is probably
always going to be somewhat broken, because it's implemented
via blacklisting rath
On Friday, 17 August 2018 at 07:50:32 UTC, 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
On Thursday, 16 August 2018 at 17:06:27 UTC, Martin Nowak wrote:
A review would be helpful.
It looks fine to me, though, that's not saying much. If you need
someone to test something, contact me on Slack.
And more Windows dev-volunteers for upcoming features.
To do what exactly?
Mike
On Wednesday, 15 August 2018 at 06:21:39 UTC, Rel wrote:
There are other ways to do minimalist programming in D without
-betterC. See
https://dlang.org/changelog/2.079.0.html#minimal_runtime
Well, what would be the difference between betterC and writing
my own minimal runtime?
It depend on
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?
-betterC currently expects the C standard library, and
consequently the C runtime. Under the hood DMD calls `
On Tuesday, 14 August 2018 at 07:05:12 UTC, Joakim wrote:
if you have a bug ...
This is not about me:
Sorry, I mean the plural "you", as in anyone reading this thread.
Mike
On Monday, 13 August 2018 at 09:50:29 UTC, Joakim wrote:
Announced last week, the Nim team will be adding two full-time
paid devs and setting up grants for needed projects with this
new funding:
:jealous:
However, there are other ways to raise funds. Companies using D
could use the existing
On Monday, 13 August 2018 at 18:48:21 UTC, Seb wrote:
Feedback is welcome ;-)
Thanks a lot for doing this. Honestly, I think this small
change, if we can keep it maintained, will make a significant
impact in users' perception of D.
I don't think the issue is actually with the DMD executab
On Sunday, 12 August 2018 at 06:35:17 UTC, Eugene Wissner wrote:
P.S. In the last weeks I had thoughts to split low-level stuff
from tanya and put it into a separate library, kind of native,
gc-free x86-64 (and maybe aarch64) Linux runtime for D.
Probably I should go for it :)
In recent mont
On Sunday, 12 August 2018 at 06:44:37 UTC, Aruna Maurya wrote:
Also what about other implementations like memset or memcmp.
Have they been implemented or require work from scratch?
I don't know of any D implementations of these other than the
trivial and naive. I think it's a lot of work for
On Sunday, 12 August 2018 at 07:00:30 UTC, Eugene Wissner wrote:
Also what about other implementations like memset or memcmp.
Have they been implemented or require work from scratch?
These functions are still mostly implemented in asm, so I'm not
sure there is an "idiomatic D" way. I would on
On Sunday, 12 August 2018 at 07:00:30 UTC, Eugene Wissner wrote:
Also what about other implementations like memset or memcmp.
Have they been implemented or require work from scratch?
These functions are still mostly implemented in asm, so I'm not
sure there is an "idiomatic D" way. I would on
On Sunday, 12 August 2018 at 04:16:24 UTC, Aruna Maurya wrote:
So there are essentially two requirements here. Building the
memory management functionalities from scratch in idiomatic D
and implementing the existing runtime hooks as templates. The
latter isn't quite a part of the idea as menti
On Saturday, 11 August 2018 at 18:59:00 UTC, Aruna Maurya wrote:
1. If it would have been C++, the above can be implemented by
using the mmap() syscall to allocate memory
from the heap. However, something that I am not able to
understand in the idea description is 'runtime hoo
On Tuesday, 7 August 2018 at 17:47:45 UTC, Venu Vardhan Reddy
Tekula wrote:
Hello everyone, as I said before here,
https://forum.dlang.org/post/dbmottqhsyxdizfkg...@forum.dlang.org, I am interested in "Automate the collection and publishing of data for monitoring D's progress as a software develo
On Saturday, 4 August 2018 at 18:24:28 UTC, B Krishnan Iyer wrote:
I had some questions regarding the project and also needed some
pointers to get started with the project. Also, more it would
be great if more description of the project statement can be
provided.
The idea is to create someth
On Monday, 30 July 2018 at 21:02:56 UTC, Steven Schveighoffer
wrote:
Does it make sense?
It is also nice for domains like embedded systems. It is common
for embedded systems to only dynamically allocate during system
initialization (depending on the application of course).
Avoiding the a
On Monday, 30 July 2018 at 21:02:56 UTC, Steven Schveighoffer
wrote:
In this case, D allocates a pointer on the heap to hold "x",
and then return a delegate which uses the pointer to read x,
and then return that plus 10.
Yeah, that seems like such a disproportionately heavy cost.
Does it m
On Tuesday, 31 July 2018 at 19:54:20 UTC, Steven Schveighoffer
wrote:
If anything makes sense, it would be to remove the
compiler-dependencies out of druntime into a smaller runtime
library that is included in the dmd project. Most of druntime
is dependencies for the platform, not the compile
On Tuesday, 31 July 2018 at 07:17:34 UTC, Shachar Shemesh wrote:
I'm trying to figure out what's the signature of the built-in
assert. It does not seem that I can define a similar function
myself.
Help??
I'm not sure why you want a different assert, but you can
consider these options.
1)
On Tuesday, 31 July 2018 at 02:30:12 UTC, Walter Bright wrote:
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?
From https://www.gdcproject.org/
The GNU D Compiler (GDC) project was originally started b
On Sunday, 29 July 2018 at 14:21:20 UTC, Seb wrote:
Phobos has recently gotten a primitive way to run betterC tests
(https://github.com/dlang/phobos/pull/6640).
Now, it would be really cool if we can annotate existing tests
with e.g. `@betterCTest` and thus ensure that those tests work
with -
On Wednesday, 17 January 2018 at 13:24:37 UTC, Andre Pany wrote:
On Wednesday, 17 January 2018 at 12:06:23 UTC, Rel wrote:
Well, to be completely honest with you the only one
thing I like about the Go programming language is the
ability to easily cross-compile your Go program from
any supported
On Friday, 27 July 2018 at 11:03:50 UTC, Seb wrote:
What do you think?
--
Also, is there any other compelling reasons besides the test
dependency problem to motivate merging the two repositories?
What other benefits would it provide, if any?
Mike
On Friday, 27 July 2018 at 11:03:50 UTC, Seb wrote:
- Do you have a better suggestion?
Do we have a rich enough CI API to recognize dependencies between
repositories? For example, if I create a local branch in my dmd
repository named `fix_bug` and a local branch in my druntime
repository a
On Wednesday, 25 July 2018 at 15:24:50 UTC, Alexander Nicholi
wrote:
Is there a way to change this to use our own handlers with the
D runtime?
You can provide your own implementations of the runtime hooks at
https://github.com/dlang/druntime/blob/cb5efa9854775c5a72acd6870083b16e5ebba369/src/co
On Wednesday, 25 July 2018 at 08:57:41 UTC, Zheng (Vic) Luo wrote:
gcc and clang provides an option "-ffreestanding" to bypass
optimizations that need libc support. Although we can hack
around this issue by making our implementation complicated
enough/using assembly to bypass the optimizer, it
On Wednesday, 25 July 2018 at 08:27:25 UTC, Rel wrote:
To be exact as a "HEUR:Trojan-Downloader.Win32.Agent.gen".
Few other AV software does the same:
https://www.virustotal.com/#/file/0aa364c5cb90630a5757aacc0c3c05a2273f5fdb88e14e2b80d4c19ee5b16d10/detection
I think, we should do something abou
On Friday, 20 July 2018 at 00:26:43 UTC, Mr.Bingo wrote:
[...]
I didn't read through all of that, but just so you are aware, a
*multiple alias this* DIP was already approved. You can find it
at https://wiki.dlang.org/DIP66
The implementation is already started and you can find it at
https
On Wednesday, 23 May 2018 at 01:59:50 UTC, sarn wrote:
(I'm referring to Scott's 2014 DConf talk:
https://www.youtube.com/watch?v=KAWA1DuvCnQ)
I was actually preparing a DIP about this when Manu posted to
the forums about his own related problems with C++ interop.
I traced a bug in some of m
On Friday, 29 June 2018 at 09:25:08 UTC, Mike Franklin wrote:
He shows the following (probably inaccurate) matrix.
Sorry, I messed up typing out that matrix. Here are a few
corrections, but you can just see the real think the video here:
https://youtu.be/cDFSrVhnZKo?t=260
Lang| Mem S
On Friday, 29 June 2018 at 09:03:19 UTC, 鲜卑拓跋枫 wrote:
How about set up DConf Asia every year?
I doubt there'd be any problem have DConf anywhere in the world
as long is it is properly funded. Who in Asia would be willing
to sponsor it?
Mike
Please allow me to bring your attention to an interesting
presentation about choosing a modern programming language for
writing operating systems:
https://www.youtube.com/watch?v=cDFSrVhnZKo
It's a good talk and probably worth your time if you're
interested in bare-metal systems programming.
On Tuesday, 26 June 2018 at 07:05:44 UTC, Vasniktel wrote:
Hello everyone.
I am wondering about `update` and `require` properties of AAs
which are mentioned to be present here:
https://dlang.org/spec/hash-map.html#properties
However, this code doesn't compile:
```
import std.stdio;
void main()
On Saturday, 23 June 2018 at 10:18:04 UTC, Mike Franklin wrote:
The DIP states "integer and character literals that evaluate to
0 and 1".
But I see that in the "Description" it uses `0` and `1`, so I'll
remedy that with my next round of edits.
Thanks for the feedback.
Mike
On Saturday, 23 June 2018 at 08:03:40 UTC, Jacob Carlborg wrote:
I read that as only the 0 and 1 literals would be affected by
this proposal, i.e. the integer literals. But the examples are
mentioning character literals as well. But if the character
literals are evaluated to 0 or 1, perhaps ev
On Thursday, 21 June 2018 at 17:48:11 UTC, Basile B. wrote:
The case of `assert(0, "this should not happen");` is not
covered. Is this it allowed ?
That will not be affected by this DIP. I've updated the DIP to
clarify at
https://github.com/dlang/DIPs/pull/127/files
Thanks for the feedback.
On Thursday, 21 June 2018 at 17:11:07 UTC, Steven Schveighoffer
wrote:
I agree with everything, but one thing that is not specified
here is when integers are used as conditionals.
In other words, this still has to compile:
if(1) ...
enum a = 1;
if(a) ...
Although I would prefer it if suc
On Saturday, 16 June 2018 at 13:52:37 UTC, Jacob Shtokolov wrote:
Is it possible to introduce a new parameter/flag to the
compiler, to force all functions be @safe by default on a
per-module basis?
Forgive me if you're already aware of this, but to ensure your
entire program is `@safe` (assu
On Monday, 11 June 2018 at 18:34:58 UTC, Johannes Pfau wrote:
I understand that you actually need to reimplement memcpy, as
in your microcontroller usecase you don't want to have any C
runtime. So you'll basically have to rewrite the C runtime
parts D depends on.
However, I think for memcpy
On Monday, 11 June 2018 at 12:38:33 UTC, Luís Marques wrote:
Just to check. If you have a piece of code like "foo.bar.baz",
you can get the full hierarchy, for instance with stringof:
static assert(foo.bar.baz.stringof == "foo.bar.bar");
Are you looking for this:
https://dlang.org/pho
On Monday, 11 June 2018 at 10:38:30 UTC, Mike Franklin wrote:
On Monday, 11 June 2018 at 10:07:39 UTC, Walter Bright wrote:
I think there might also be optimization opportunities using
templates, metaprogramming, and type introspection, that are
not currently possible with the current design.
On Monday, 11 June 2018 at 10:07:39 UTC, Walter Bright wrote:
I think there might also be optimization opportunities using
templates, metaprogramming, and type introspection, that are
not currently possible with the current design.
Just making it a template doesn't automatically enable any of
On Monday, 11 June 2018 at 10:07:39 UTC, Walter Bright wrote:
We have no design for this function that doesn't rely on the
GC, and the GC needs TypeInfo. This function is not usable with
betterC with or without the TypeInfo argument.
I understand that. I was using `_d_arraysetlengthT` as an
On Monday, 11 June 2018 at 08:05:14 UTC, Walter Bright wrote:
On 6/10/2018 8:34 PM, Basile B. wrote:
- default win32 OMF:
https://github.com/DigitalMars/dmc/blob/master/src/core/MEMCCPY.C
I think you mean:
https://github.com/DigitalMars/dmc/blob/master/src/CORE32/MEMCPY.ASM
Cool! and it's e
On Monday, 11 June 2018 at 08:00:10 UTC, Walter Bright wrote:
Making it a template is not really necessary. The compiler
knows if there is the possibility of it throwing based on the
type, it doesn't need to infer it.
There are other reasons to make it a template, though. For
example, if it
On Monday, 11 June 2018 at 03:31:05 UTC, Walter Bright wrote:
On 6/10/2018 7:49 PM, Mike Franklin wrote:
On Sunday, 10 June 2018 at 15:12:27 UTC, Kagamin wrote:
If the compiler can't get it right then who can?
The compiler implementation is faulty. It rewrites the
expressions to an `extern(C)
On Monday, 11 June 2018 at 02:49:00 UTC, Mike Franklin wrote:
The compiler implementation is faulty. It rewrites the
expressions to an `extern(C)` runtime implementation that is
not @safe, nothrow, or pure:
https://github.com/dlang/druntime/blob/706081f3cb23f4c597cc487ce16ad3d2ed021053/src/r
On Sunday, 10 June 2018 at 15:12:27 UTC, Kagamin wrote:
On Sunday, 10 June 2018 at 12:49:31 UTC, Mike Franklin wrote:
There are many reasons to do this, one of which is to leverage
information available at compile-time and in D's type system
(type sizes, alignment, etc...) in order to optimize
I've modified the test based on the feedback so far, so here's
what it looks like now:
import std.datetime.stopwatch;
import std.stdio;
import core.stdc.string;
import std.random;
import std.algorithm;
enum length = 4096 * 2;
void init(ref ubyte[] a)
{
a.length = length;
for(int i = 0
On Sunday, 10 June 2018 at 13:16:21 UTC, Adam D. Ruppe wrote:
arr1[] = arr2[]; // the compiler makes this memcpy, the
optimzer can further do its magic
void memcpyD()
{
dst = src.dup;
}
void memcpyD2()
{
dst[] = src[];
}
-
memcpyD: 1 ms, 725 μs, and 1 hnsec
memcpyD2: 587 μs and 5
On Sunday, 10 June 2018 at 13:17:53 UTC, Guillaume Piolat wrote:
Please make one that guarantee the usage of the corresponding
backend intrinsic, for example on LLVM.
I tested with ldc and got similar results. I thought the
implementation in C forwarded to the backend intrinsic. I think
ev
On Sunday, 10 June 2018 at 13:16:21 UTC, Adam D. Ruppe wrote:
And D already has it built in as well for @safe etc:
arr1[] = arr2[]; // the compiler makes this memcpy, the
optimzer can further do its magic
so be sure to check against that too.
My intent is to use the D implementation in the
On Sunday, 10 June 2018 at 13:05:33 UTC, Nicholas Wilson wrote:
On Sunday, 10 June 2018 at 12:49:31 UTC, Mike Franklin wrote:
I'm exploring the possibility of implementing some of the
basic software building blocks (memcpy, memcmp, memmove,
etc...) that D utilizes from the C library with D
imp
I'm exploring the possibility of implementing some of the basic
software building blocks (memcpy, memcmp, memmove, etc...) that D
utilizes from the C library with D implementations. There are
many reasons to do this, one of which is to leverage information
available at compile-time and in D's
On Saturday, 9 June 2018 at 07:26:02 UTC, Walter Bright wrote:
Your time is valuable, too, and while I'm not going to tell you
want to work on, I'd prefer something more important.
If that's how you feel then I clearly don't share your values.
To me, cleaning up the unimplemented, half-imple
On Saturday, 9 June 2018 at 05:00:29 UTC, Walter Bright wrote:
My goal in the short term is that Phobos is going to compile
successfully with dip1000 the way it is now. It has already
been deferred and deferred and deferred.
I understand that, and while you're doing that I can begin
implemen
On Saturday, 9 June 2018 at 02:13:00 UTC, Walter Bright wrote:
'in' is supposed to mean 'scope const'. But it was never
enforced, meaning that suddenly enforcing it is just going to
break code left and right.
I think the breakage would be simple to mitigate. Anywhere `in`
is used we display
See https://dlang.org/spec/function.html#parameters
I also noticed Walter removed `in` in this PR:
https://github.com/dlang/phobos/pull/6561
Should it be deprecated (not necessarily removed) to guide users
towards a more consistent and idiomatic usage of the language?
Also, if there are fe
On Friday, 8 June 2018 at 11:27:14 UTC, Seb wrote:
The point is to dis-encourage new uses of the deprecated symbol.
The deprecation warning from the compiler and annotating the
documentation with a deprecation notice will already accomplish
that.
Mike
On Thursday, 7 June 2018 at 06:22:04 UTC, Mike Parker wrote:
@@@DEPRECATED_[version]@@@
This is still ambiguous to me. Deprecations are done in stages.
For example:
Stage 1 (version 2.081) - Compiler emits deprecation warning
Stage 2 (version 2.086 = 2.081 + 5) - Compiler emits error
Stag
On Wednesday, 6 June 2018 at 01:34:13 UTC, Arun Chandrasekaran
wrote:
I'm more interested in no/minimal runtime[1] than -betterC for
my use cases.
I think it will be good to have the document mention if the
function is supported without the druntime and/or with
-betterC. This documentation ca
On Tuesday, 5 June 2018 at 10:11:49 UTC, Ethan wrote:
Exhibit A: https://run.dlang.io/is/a85Lbq
[..snip..]
I submitted a bug with the above code, and it was "helpfully"
shut down with a link to the documentation and workaround.
This looks like the bug report you are referring to:
https://i
On Friday, 1 June 2018 at 03:14:11 UTC, Walter Bright wrote:
On 5/30/2018 2:45 PM, John Colvin wrote:
https://run.dlang.io/is/oMe7KQ
Less elegant, but solves the problem of accidental argument
adding (CallerFile acts as a barrier). Unfortunately, while it
works in theory, in practice the comp
On Thursday, 31 May 2018 at 01:49:42 UTC, DigitalDesigns wrote:
https://dpaste.dzfl.pl/6c6e614b58ac
The problem given in the list, is that a ref getter is used
when a setter does not exist. Why have a setter then?
One problem is that if the setter has different behavior than
the getter there
On Sunday, 27 May 2018 at 16:06:21 UTC, 12345swordy wrote:
You are replacing runtime typeinfo with compiletime templates.
Unless you can guarantee that the type information won't change
during runtime, you are going to have a hard time.
Read this thread for context
https://forum.dlang.org/po
1 - 100 of 217 matches
Mail list logo
