On Friday, 17 May 2019 at 20:04:42 UTC, Walter Bright wrote:
Dip1000 is key to enable containers to control access to
pointers to their innards that they expose.
I haven't looked at the subject for a while, but every time I did
the takeaway was the same: dip1000 works great for containers
unt
On Saturday, 18 May 2019 at 19:44:37 UTC, Walter Bright wrote:
If all access to internals is returned by ref, those lifetimes
are restricted to the current expression.
Oh my god, I try my best to be open-minded, but talking about
dip1000 design with you is like pulling teeth *at best*.
Yes,
On Wednesday, 26 June 2019 at 10:51:33 UTC, Mike Parker wrote:
https://github.com/dlang/DIPs/pull/158
I'm going to be candid here:
Based on past experience, I'm worried that:
- This DIP will generate a lot of negative feedback.
- Walter will ignore most of that feedback, or cherry-pick a few
On Monday, 15 July 2019 at 14:58:55 UTC, Mike Parker wrote:
some folks asked for some information about the bigger picture.
As one of the folks that asked for that information, thank you
Walter for posting this :)
The system described is a little rough around the edges, but it's
really help
On Tuesday, 16 July 2019 at 06:12:42 UTC, Walter Bright wrote:
Now I just have to deliver the goods!
Lately, I've been thinking about the possibility of an
alternative ownership system for D, one that would be radically
different from what you're considering, but still aim for the
same featu
On Wednesday, 17 July 2019 at 20:59:27 UTC, Walter Bright wrote:
I'm interested to see your design. But I suggest you move
quickly, as I've suggested people who talked about this propose
a design for the last 10 years, nothing has happened, and we
can't wait any longer.
For the record, I've b
On Tuesday, 23 July 2019 at 14:18:27 UTC, Timon Gehr wrote:
I think tying ownership/borrowing semantics to pointers instead
of structs makes no sense; it's not necessary and it's not
sufficient. Your use case illustrates why it is not sufficient.
That's as good a time as any to plug my own pro
On Tuesday, 23 July 2019 at 22:01:56 UTC, Sebastiaan Koppe wrote:
So in a nutshell, a variable with the unique qualifier ensures
that there are no other references to that data during the
lifetime of said variable? In other words, you can only take 1
addressOf/ref at a time?
Does it prevent m
On Saturday, 28 January 2017 at 03:40:43 UTC, Walter Bright wrote:
If you've got a case, make it. If you see problems, explain. If
you want to help, please do.
For what it's worth, here are my problems with 'return scope':
- As far as I can tell, it's not properly documented. The github
page
On Saturday, 28 January 2017 at 22:31:23 UTC, Walter Bright wrote:
It only addresses cases where a reference might be escaped
through a
single return value; it doesn't address escaping through 'out'
parameters,
Yes it does (the general case is storing a value into any data
structure pointed
Continuing on a new thread because this is getting kinda
off-topic.
http://forum.dlang.org/post/jhtvuvhxsayjatsdb...@forum.dlang.org
On Friday, 2 June 2017 at 14:17:10 UTC, Mike Parker wrote:
https://github.com/dlang/DIPs/blob/master/DIPs/DIP1003.md
The "See the previous version" link at the end of the document is
currently broken and leads to a 404.
Thank you for your efforts and congratulations to Jared Hanson!
On Sunday, 16 December 2018 at 00:17:55 UTC, Paul Backus wrote:
There's something important you're glossing over here, which is
that, in the general case, there's no single obvious or natural
way to compose two DAGs together.
For example: suppose project A's DAG has two "output" vertices
(i.e
On Friday, 25 January 2019 at 11:56:58 UTC, Walter Bright wrote:
All that criticism aside, I'd like to see rvalue references in
D. But the DIP needs significant work.
I haven't participated to writing this DIP, but I personally
appreciate this level of feedback.
I think it would have been mo
On Monday, 28 January 2019 at 17:23:51 UTC, Andrei Alexandrescu
wrote:
* Regarding the argument "why not make this an iterative
process where concerns are raised and incrementally addressed?"
We modeled the DIP process after similar processes - conference
papers, journal papers, proposals in ot
On Thursday, 31 January 2019 at 02:10:05 UTC, Manu wrote:
I still can't see a truck-sized hole.
I don't know if it's truck-sized, but here's another corner case:
int doubleMyValue(ref int x) {
x *= 2;
return x;
}
Point pt;
pt.x = 5;
pt.y = foobar();
do
On Thursday, 31 January 2019 at 16:38:42 UTC, Steven
Schveighoffer wrote:
Yeah, that's already a thing that ref in D doesn't protect
against:
It took me a while to understand what the compiler was doing.
This really feels like something that shouldn't compile.
On Thursday, 31 January 2019 at 18:31:22 UTC, Steven
Schveighoffer wrote:
BTW, the DIP discusses how to annotate these rare situations:
int doubleMyValue(ref int x) { ... }
@disable int doubleMyValue(int x);
-Steve
I don't think that's a solution. The problem is in the getter
method, not in
On Thursday, 31 January 2019 at 21:44:53 UTC, jmh530 wrote:
It doesn't compile with dip1000 without first giving the getter
functions a return attribute for this.
But it still compiles with -dip1000 once you give x() and y()
return attributes, even though what's happening is clearly
different
On Thursday, 31 January 2019 at 21:57:21 UTC, Steven
Schveighoffer wrote:
That being said, you can look at the fact that most people
don't even know about this problem, even seasoned veterans, as
a sign that it's really not a big problem.
Isn't it a recurring theme on this forum that D is real
On Thursday, 31 January 2019 at 21:50:32 UTC, Steven
Schveighoffer wrote:
How is the problem not in doubleMyValue? It's sole purpose is
to update an lvalue. It is the perfect candidate to mark with
@disable for rvalues.
But right now, updating an rvalue is what ref is supposed to be
used for.
On Friday, 1 February 2019 at 09:10:15 UTC, aliak wrote:
Shouldn't doubleMyValue(pt.x) be a compiler error if pt.x is a
getter? For it not to be a compile error pt.x should also have
a setter, in which case the code needs to be lowered to
something else:
The thing is, D doesn't really differe
On Sunday, 24 February 2019 at 12:57:06 UTC, ag0aep6g wrote:
On 24.02.19 11:46, Mike Parker wrote:
Walter provided feedback on Razvan's implementation. When it
reached a state with which he was satisfied, he gave the green
light for acceptance.
Sounds like it might be a "worst acceptable prop
On Monday, 25 February 2019 at 20:41:58 UTC, Paolo Invernizzi
wrote:
Honestly, I've not understood the rationale or the covered use
case in letting the copy ctor mutate the ref source
parameters...
Sincerely, without polemical intent.
- P
For the same reason C++'s std::shared_pointer uses a
On Monday, 25 February 2019 at 16:00:54 UTC, Andrei Alexandrescu
wrote:
Thorough feedback has been given, likely more so than for any
other submission. A summary for the recommended steps to take
can be found here:
https://forum.dlang.org/post/q2u429$1cmg$1...@digitalmars.com
It is not desira
On Monday, 25 February 2019 at 22:45:38 UTC, Olivier FAURE wrote:
For the same reason C++'s std::shared_pointer uses a non-const
copy constructor.
Wait, no, I just checked, std::shared_pointer's copy constructor
is const, even though it changes shared data. Ugh, that's just
wrong.
(I kind o
On Thursday, 28 February 2019 at 12:24:27 UTC, Mike Parker wrote:
The Blog:
https://dlang.org/blog/2019/02/28/project-highlight-spasm/
Reddit:
https://www.reddit.com/r/programming/comments/avqioi/spasm_d_to_webassembly_for_single_page_apps/
I've seen spasm around quite a few times, but reading
On Friday, 1 March 2019 at 14:27:36 UTC, Sebastiaan Koppe wrote:
That would be awesome. I initially tried very hard to stick to
React/JSX functional rendering. I could not find a way to make
it a zero-cost abstraction, but maybe you have more success!
I'll create an issue once I've written dow
On Thursday, 28 February 2019 at 01:42:13 UTC, Andrei
Alexandrescu wrote:
Such sharing of resources across objects is a common
occurrence, which would be impeded by forcing `const` on the
right-hand side of a copy. (An inferior workaround would be to
selectively cast `const` away inside the cop
On Thursday, 7 March 2019 at 14:24:29 UTC, Mike Parker wrote:
The implementation supersedes the DIP.
I think the question a lot of people have in mind is "Is there
any plan to formally organize a discussion about the future of
scoped pointers?"
More specifically, are you planning a new DIP
30 matches
Mail list logo
