On Monday, 28 October 2019 at 19:23:30 UTC, jmh530 wrote:
they are all const. That there is only one mutable way to
access data sounds like restrict to me.
Well, if you add the constraint that there also is no const way
to access the data.
But unique ownership is stricter than «restrict»,
On Monday, 28 October 2019 at 21:53:50 UTC, Walter Bright wrote:
I've always known it was a bad idea (not just me, it was common
knowledge). People have a hard time understanding restrict, and
are guaranteed to use it wrong. Let alone errors using it from
people who do understand it.
On 10/28/2019 2:38 PM, Ben Jones wrote:
Just for context, here's a paper arguing restrict without tooling is a bad idea:
http://people.cs.pitt.edu/~mock/papers/clei2004.pdf . Having the compiler
enforce it changes the game substantially, I think.
I've always known it was a bad idea (not just
On Monday, 28 October 2019 at 20:23:50 UTC, Walter Bright wrote:
On 10/28/2019 12:23 PM, jmh530 wrote:
Is there a connection between this DIP and the restrict
qualifier in C? This DIP basically ensures that in @safe code,
if a piece of data is accessed only through scope pointers,
then there
On 10/28/2019 12:23 PM, jmh530 wrote:
Is there a connection between this DIP and the restrict qualifier in C? This DIP
basically ensures that in @safe code, if a piece of data is accessed only
through scope pointers, then there must be only one mutable pointer to said data
or they are all
On Sunday, 20 October 2019 at 12:31:23 UTC, Mike Parker wrote:
DIP 1021, "Argument Ownership and Function Calls", has been
formally accepted with minor revision. It was updated to make
clear that the proposal is one piece of a bigger plan.
On Wednesday, 23 October 2019 at 16:54:36 UTC, 12345swordy wrote:
"“But D has a GC!”, I hear you exclaim.
No body said that. Funny how you chose the simplest argument to
argue against.
Yes, but it’s also a
systems programming language with value types and pointers,
meaning that today, D
On Wednesday, 23 October 2019 at 15:31:24 UTC, Exil wrote:
D isn't a systems programming language
"“But D has a GC!”, I hear you exclaim. Yes, but it’s also a
systems programming language with value types and pointers,
meaning that today, D isn’t memory safe. DIP1000 was a step in
the
On Wednesday, 23 October 2019 at 04:53:55 UTC, Mike Parker wrote:
On Wednesday, 23 October 2019 at 04:20:19 UTC, Exil wrote:
it's a bad idea. Why have two community reviews? Those are
made with the assumption that the DIP will actually change
between the reviews.
No, that's not the
On Wednesday, 23 October 2019 at 04:49:52 UTC, Mike Parker wrote:
On Wednesday, 23 October 2019 at 04:20:19 UTC, Exil wrote:
Should create a DIPW process then, duck the foundation and any
formalities. Which stands for DIPWalter, which simply consists
of a single step where a single topic
On Wednesday, 23 October 2019 at 15:10:23 UTC, 12345swordy wrote:
On Wednesday, 23 October 2019 at 04:20:19 UTC, Exil wrote:
Not to mention the problem is actually solved just by using
the GC.
The d language is marked as a system programming language. The
GC is not going to cut it to a lot
On Wednesday, 23 October 2019 at 04:20:19 UTC, Exil wrote:
Not to mention the problem is actually solved just by using the
GC.
The d language is marked as a system programming language. The GC
is not going to cut it to a lot of people.(Did you forget the
whole betterC flag?)
-Alex
On Wednesday, 23 October 2019 at 04:20:19 UTC, Exil wrote:
it's a bad idea. Why have two community reviews? Those are made
with the assumption that the DIP will actually change between
the reviews.
No, that's not the assumption. You're conflating Community Review
with Final Review. There
On Wednesday, 23 October 2019 at 04:20:19 UTC, Exil wrote:
Should create a DIPW process then, duck the foundation and any
formalities. Which stands for DIPWalter, which simply consists
of a single step where a single topic tries to convince Walter
it's a bad idea. Why have two community
On Wednesday, 23 October 2019 at 00:03:35 UTC, Jonathan M Davis
wrote:
On Monday, October 21, 2019 6:59:21 AM MDT Exil via
Digitalmars-d-announce wrote:
> This proposal is one step toward a larger goal outlined in
> the
>
> blog post ['Ownership and Borrowing in
>
On Monday, October 21, 2019 6:59:21 AM MDT Exil via Digitalmars-d-announce
wrote:
> > This proposal is one step toward a larger goal outlined in the
> >
> > blog post ['Ownership and Borrowing in
> > D'](https://dlang.org/blog/2019/07/15/ownership-and-borrowing-in-d/).
>
> That's the only line
This proposal is one step toward a larger goal outlined in the
blog post ['Ownership and Borrowing in
D'](https://dlang.org/blog/2019/07/15/ownership-and-borrowing-in-d/).
That's the only line that was added, no other changes were made
to the core DIP from the first revision to the last. Big
DIP 1021, "Argument Ownership and Function Calls", has been
formally accepted with minor revision. It was updated to make
clear that the proposal is one piece of a bigger plan.
https://github.com/dlang/DIPs/blob/master/DIPs/accepted/DIP1021.md
18 matches
Mail list logo
