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 02/25/2019 03:41 PM, Paolo Invernizzi wrote:
On Monday, 25 February 2019 at 20:23:58 UTC, Andrei Alexandrescu wrote:
On 2/25/19 3:23 PM, Jacob Carlborg wrote:
On 2019-02-25 20:24, Mike Parker wrote:
From the process document:
“the DIP Manager or the Language Maintainers may allow for
exc
On Tuesday, 26 February 2019 at 05:38:01 UTC, Manu wrote:
I'm talking about this DIP. Allowing a mutable copy argument
feels super weird.
The problem was out of place mutation, which can't happen with
copy constructor, because initialization from rvalue is a move,
so the copy constructor won'
On 2/27/2019 3:27 AM, Jacob Carlborg wrote:
[...]
Please start another thread.
On 2019-02-26 12:07, Walter Bright wrote:
It hasn't been approved yet, and please start another thread if you want
to discuss it.
You have approved the pull request.
--
/Jacob Carlborg
On Tuesday, 26 February 2019 at 03:56:27 UTC, Walter Bright wrote:
On 2/25/2019 7:45 AM, Atila Neves wrote:
I have no idea what people are talking about when they mention
on this forum that D's const is useless. Nearly every function
parameter in my code is `in`. Nearly every variable
declarat
On 2/26/2019 2:32 AM, Jacob Carlborg wrote:
What about the __mutable proposal [1]?
[1] https://github.com/dlang/dmd/pull/8315
It hasn't been approved yet, and please start another thread if you want to
discuss it.
On 2019-02-25 01:38, Walter Bright wrote:
D's const has teeth. Nothing can be modified through T.
What about the __mutable proposal [1]?
[1] https://github.com/dlang/dmd/pull/8315
--
/Jacob Carlborg
On 2019-02-25 21:23, Andrei Alexandrescu wrote:
Jacob, are there amends you need to make to the DIP?
No, I'm talking about the process in general.
--
/Jacob Carlborg
On Monday, 25 February 2019 at 02:29:40 UTC, Manu wrote:
On Sun, Feb 24, 2019 at 4:25 PM Walter Bright via
Digitalmars-d-announce
wrote:
Thanks for letting me know you're abandoning the rvalue ref
DIP.
It's not an "rvalue ref" DIP (which I think has confused a lot
of
people), it's an rva
On Sunday, 24 February 2019 at 10:46:37 UTC, Mike Parker wrote:
Walter and Andrei have requested the Final Review round be
dropped for DIP 1018, "The Copy Constructor", and have given it
their formal approval. They consider copy constructors a
critical feature for the language.
Walter provide
On Tuesday, 26 February 2019 at 02:51:54 UTC, Andrei Alexandrescu
wrote:
On 2/25/19 7:23 PM, Nicholas Wilson wrote:
I've said before that that comparison is weak and not
particularly useful, irrespective of its intention.
That you've said it before does not make it any more correct.
You're
On Mon, Feb 25, 2019 at 9:30 PM Walter Bright via
Digitalmars-d-announce wrote:
>
> On 2/25/2019 7:17 PM, Manu wrote:
> > break my DIP
>
> The review process is not about "why not add this feature" , but "why should
> we
> have this feature".
>
> Additionally, it is most assuredly about finding f
On 2/25/2019 7:17 PM, Manu wrote:
break my DIP
The review process is not about "why not add this feature" , but "why should we
have this feature".
Additionally, it is most assuredly about finding flaws in it. Isn't it best to
find out the flaws before going further with it than finding them
On 2/25/2019 7:17 PM, Manu wrote:
I'm literally astonished that it's been agreed it's fine that
a copy constructor can mutate the source... and I can't help but draw
contrast to the exact same sorts of arguments that people were using
to break my DIP,
Mutating the lvalue ref was not the issue,
On Mon, Feb 25, 2019 at 8:10 PM Donald via Digitalmars-d-announce
wrote:
>
> On Tuesday, 26 February 2019 at 03:17:53 UTC, Manu wrote:
> > ...
>
> It's funny that you keep wasting time posting/replying instead of
> fixing your DIP.
An hour typing rubbish on the forum is nothing compared to reboot
On Tuesday, 26 February 2019 at 03:17:53 UTC, Manu wrote:
...
It's funny that you keep wasting time posting/replying instead of
fixing your DIP.
By the way like the other guy, I found disrespectful (With
RazvanN7) use this topic as argument for your rejected DIP,
instead to debate about wh
On 2/25/2019 3:05 PM, Olivier FAURE wrote:
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 share
On 2/25/2019 10:44 AM, Andrei Alexandrescu wrote:
On 2/25/19 1:39 PM, Jacob Carlborg wrote:
On 2019-02-25 17:31, Andrei Alexandrescu wrote:
The proposers (Razvan and myself) and Walter (the reviewer) do not know how
to make DIP 1018 better.
That shouldn't justify accepting a DIP that might c
On 2/25/2019 6:55 PM, Andrei Alexandrescu wrote:
If there's something else I can do to atone, please let me know.
Pistols at dawn?
Or better yet, why don't I buy both of you a beer at DConf?
On 2/25/2019 8:22 AM, H. S. Teoh wrote:
I disagree. Logical const means the outside world can't tell that the
object has changed, because only a constant value is ever seen from
outside. This is the basis of lazy initialization (which is part of the
concept of lazy evaluation), an important fea
On 2/25/2019 7:45 AM, Atila Neves wrote:
I have no idea what people are talking about when they mention on this forum
that D's const is useless. Nearly every function parameter in my code is `in`.
Nearly every variable declaration uses `const` instead of `auto`, the main
exception being when a
On 2/25/2019 3:09 PM, Olivier FAURE wrote:
Yes, this DIP was fast-tracked. Yes, this can feel unfair. And yet, it makes
sense that it was fast-tracked, because it fits a priority of the project owners
(C++ interoperability + reference counting) and project owners are allowed to
have priorities.
On 2/25/2019 6:26 PM, Andrei Alexandrescu wrote:
I haven't heard the final decision from Walter yet, but I proposed that in the
interest of quality, we will go through the customary two weeks reviews with DIP
1018.
I approved it.
On Mon, Feb 25, 2019 at 3:10 PM Olivier FAURE via
Digitalmars-d-announce wrote:
>
> 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
On 2/25/19 9:26 PM, Manu wrote:
On Mon, Feb 25, 2019 at 12:20 PM Andrei Alexandrescu via
Digitalmars-d-announce wrote:
On 2/25/19 2:41 PM, bachmeier wrote:
On Monday, 25 February 2019 at 19:24:55 UTC, Mike Parker wrote:
From the process document:
“the DIP Manager or the Language Maintaine
On 2/25/19 7:23 PM, Nicholas Wilson wrote:
There are similarities and differences between our DIP process and
paper submission reviews at conferences and journals everywhere; one
key similarity is that the submitters are on hook for providing
convincing submissions, whereas reviewers are not re
On 2/25/19 6:09 PM, Olivier FAURE wrote:
Yes, this DIP was fast-tracked. Yes, this can feel unfair. And yet, it
makes sense that it was fast-tracked, because it fits a priority of the
project owners (C++ interoperability + reference counting) and project
owners are allowed to have priorities. I
On Mon, Feb 25, 2019 at 12:20 PM Andrei Alexandrescu via
Digitalmars-d-announce wrote:
>
> On 2/25/19 2:41 PM, bachmeier wrote:
> > On Monday, 25 February 2019 at 19:24:55 UTC, Mike Parker wrote:
> >
> >> From the process document:
> >>
> >> “the DIP Manager or the Language Maintainers may allow f
On Tuesday, 26 February 2019 at 00:23:19 UTC, Nicholas Wilson
wrote:
On Monday, 25 February 2019 at 16:00:54 UTC, Andrei
Alexandrescu wrote:
* etc. etc. etc.
That is a good start, though I suspect that the list is not
complete given the last item.
Oh, it keeps going.
On Monday, 25 February 2019 at 20:23:58 UTC, Andrei Alexandrescu
wrote:
On 2/25/19 3:23 PM, Jacob Carlborg wrote:
On 2019-02-25 20:24, Mike Parker wrote:
From the process document:
“the DIP Manager or the Language Maintainers may allow for
exceptions which waive requirements or responsibili
On Monday, 25 February 2019 at 16:00:54 UTC, Andrei Alexandrescu
wrote:
On 2/25/19 1:06 AM, Nicholas Wilson wrote:
On Monday, 25 February 2019 at 02:56:13 UTC, Walter Bright
wrote:
Your DIP, and nobody else is going to do it, so it falls to
me.
It will be reviewed at Dconf, please make sure y
On Monday, February 25, 2019 4:09:55 PM MST Olivier FAURE via Digitalmars-d-
announce wrote:
> Yes, this DIP was fast-tracked. Yes, this can feel unfair. And
> yet, it makes sense that it was fast-tracked, because it fits a
> priority of the project owners (C++ interoperability + reference
> counti
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 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 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 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
Because D's const is transitive, you can't copy-const
On 2/25/19 3:41 PM, Paolo Invernizzi wrote:
On Monday, 25 February 2019 at 20:23:58 UTC, Andrei Alexandrescu wrote:
On 2/25/19 3:23 PM, Jacob Carlborg wrote:
On 2019-02-25 20:24, Mike Parker wrote:
From the process document:
“the DIP Manager or the Language Maintainers may allow for
except
On Monday, 25 February 2019 at 20:23:58 UTC, Andrei Alexandrescu
wrote:
On 2/25/19 3:23 PM, Jacob Carlborg wrote:
On 2019-02-25 20:24, Mike Parker wrote:
From the process document:
“the DIP Manager or the Language Maintainers may allow for
exceptions which waive requirements or responsibili
On 2019-02-25 20:24, Mike Parker wrote:
From the process document:
“the DIP Manager or the Language Maintainers may allow for exceptions
which waive requirements or responsibilities at their discretion.”
Having it documented doesn't make it less flawed.
--
/Jacob Carlborg
On 2/25/19 3:23 PM, Jacob Carlborg wrote:
On 2019-02-25 20:24, Mike Parker wrote:
From the process document:
“the DIP Manager or the Language Maintainers may allow for exceptions
which waive requirements or responsibilities at their discretion.”
Having it documented doesn't make it less fl
On 2/25/19 2:41 PM, bachmeier wrote:
On Monday, 25 February 2019 at 19:24:55 UTC, Mike Parker wrote:
From the process document:
“the DIP Manager or the Language Maintainers may allow for exceptions
which waive requirements or responsibilities at their discretion.”
If you were to write a DIP
On Monday, 25 February 2019 at 19:24:55 UTC, Mike Parker wrote:
From the process document:
“the DIP Manager or the Language Maintainers may allow for
exceptions which waive requirements or responsibilities at
their discretion.”
If you were to write a DIP for a feature they think important
On 2/25/19 2:24 PM, Mike Parker wrote:
On Monday, 25 February 2019 at 18:51:17 UTC, Jacob Carlborg wrote:
On 2019-02-24 11:46, Mike Parker wrote:
Walter and Andrei have requested the Final Review round be dropped
for DIP 1018, "The Copy Constructor", and have given it their formal
approval. Th
On Monday, 25 February 2019 at 18:51:17 UTC, Jacob Carlborg wrote:
On 2019-02-24 11:46, Mike Parker wrote:
Walter and Andrei have requested the Final Review round be
dropped for DIP 1018, "The Copy Constructor", and have given
it their formal approval. They consider copy constructors a
critica
On 2019-02-24 11:46, Mike Parker wrote:
Walter and Andrei have requested the Final Review round be dropped for
DIP 1018, "The Copy Constructor", and have given it their formal
approval. They consider copy constructors a critical feature for the
language.
Walter provided feedback on Razvan's i
On 2/25/19 1:39 PM, Jacob Carlborg wrote:
On 2019-02-25 17:31, Andrei Alexandrescu wrote:
The proposers (Razvan and myself) and Walter (the reviewer) do not
know how to make DIP 1018 better.
That shouldn't justify accepting a DIP that might contain problems.
Definitely.
But of course, if
On 2019-02-25 17:31, Andrei Alexandrescu wrote:
The proposers (Razvan and myself) and Walter (the reviewer) do not know how
to make DIP 1018 better.
That shouldn't justify accepting a DIP that might contain problems. But
of course, if you don't think there are any problems.
--
/Jacob Carlbo
On 2/24/19 4:02 PM, Manu wrote:
On Sun, Feb 24, 2019 at 2:50 AM Mike Parker via Digitalmars-d-announce
wrote:
Walter and Andrei have requested the Final Review round be
dropped for DIP 1018, "The Copy Constructor", and have given it
their formal approval. They consider copy constructors a crit
On Sun, Feb 24, 2019 at 08:59:49PM -0800, Walter Bright via
Digitalmars-d-announce wrote:
[...]
> An interesting manifestation of this uselessness in C++ is the notion
> of "logical const", where a supposedly "const" value is lazily set to
> a value upon first use. I.e. it isn't const, it's just p
On 2/25/19 10:45 AM, Atila Neves wrote:
The *only* problem I have with const in D is that const values can't be
copied, which is silly. I'd expect DIP1018 to fix that.
Affirmative. It was tricky.
On 2/25/19 1:06 AM, Nicholas Wilson wrote:
On Monday, 25 February 2019 at 02:56:13 UTC, Walter Bright wrote:
Your DIP, and nobody else is going to do it, so it falls to me.
It will be reviewed at Dconf, please make sure you have an _accurate_
summary of your criticisms of the DIP ready for th
On Monday, 25 February 2019 at 00:38:02 UTC, Walter Bright wrote:
The problem with C++ const is it only goes one level, i.e. what
I call "head-const". If you pass a T to a const parameter,
anything T references remains mutable. It's more of a
suggestion than anything reliable or enforceable. It
On Monday, 25 February 2019 at 02:56:13 UTC, Walter Bright wrote:
Your DIP, and nobody else is going to do it, so it falls to me.
It will be reviewed at Dconf, please make sure you have an
_accurate_ summary of your criticisms of the DIP ready for then.
BTW, everyone should expect the DIP p
On 2/24/2019 8:04 PM, Manu wrote:
1. make code easier to understand?
const code is self documenting and protective against modification by
issuing the user helpful error messages.
I've had many people tell me they mean transitive const when they use const in
C++. That is not self documentati
On Sun, Feb 24, 2019 at 6:35 PM Walter Bright via
Digitalmars-d-announce wrote:
>
> I agree with your point that C++ const can be used in a lot more places than D
> const. Absolutely true.
>
> Missing from the post, however, is an explanation of what value C++ const
> semantics have. How does it:
Your DIP, and nobody else is going to do it, so it falls to me.
BTW, everyone should expect the DIP process to be brutal. It has to be, we're
long past the stage where we can allow misshapen stuff to get into the language.
Nobody was very kind with my bottom type DIP :-)
You should read the d
I agree with your point that C++ const can be used in a lot more places than D
const. Absolutely true.
Missing from the post, however, is an explanation of what value C++ const
semantics have. How does it:
1. make code easier to understand?
2. prevent common programming bugs?
3. help with mul
On Sun, Feb 24, 2019 at 4:25 PM Walter Bright via
Digitalmars-d-announce wrote:
>
> Thanks for letting me know you're abandoning the rvalue ref DIP.
It's not an "rvalue ref" DIP (which I think has confused a lot of
people), it's an rvalue *by-ref* DIP.
In my head, an "rvalue ref" DIP is something
On Sun, Feb 24, 2019 at 4:40 PM Walter Bright via
Digitalmars-d-announce wrote:
>
> The problem with C++ const is it only goes one level, i.e. what I call
> "head-const". If you pass a T to a const parameter, anything T references
> remains mutable. It's more of a suggestion than anything reliable
On 25/02/2019 10:22 AM, Walter Bright wrote:
I think we need to throw in the towel, C++'s const is right, and D's
const is just wrong, and no amount of pretending that's not true will
resolve the endless stream of issues.
Where's the DIP to migrate to C++-style const? That is the predicate
for ba
On Sunday, 24 February 2019 at 21:22:33 UTC, Walter Bright wrote:
On 2/24/2019 1:02 PM, Manu wrote:
I mean like, my DIP was almost violently rejected,
I thought it was clear what was needed to be done with it, and
I thought you were going to rewrite it. Was I mistaken?
Absolutely no, no. Ye
The problem with C++ const is it only goes one level, i.e. what I call
"head-const". If you pass a T to a const parameter, anything T references
remains mutable. It's more of a suggestion than anything reliable or
enforceable. It only works if your data structures are simple aggregates, not
gra
Thanks for letting me know you're abandoning the rvalue ref DIP. I had held off
working on it because I didn't want to duplicate efforts; we're short-staffed
enough as it is.
On Sun, Feb 24, 2019 at 1:25 PM Walter Bright via
Digitalmars-d-announce wrote:
>
> On 2/24/2019 1:02 PM, Manu wrote:
> > I mean like, my DIP was almost violently rejected,
>
> I thought it was clear what was needed to be done with it,
To be fair, initial criticism was 75% just plain wrong (like
On 2/24/2019 1:02 PM, Manu wrote:
I mean like, my DIP was almost violently rejected,
If it makes you feel any better, Razvan had to endure major rewrites of both the
dip and the implementation.
On 2/24/2019 1:02 PM, Manu wrote:
I mean like, my DIP was almost violently rejected,
I thought it was clear what was needed to be done with it, and I thought you
were going to rewrite it. Was I mistaken?
but in here there's text like this:
"The parameter of the copy constructor is passed
On Sun, Feb 24, 2019 at 2:50 AM Mike Parker via Digitalmars-d-announce
wrote:
>
> Walter and Andrei have requested the Final Review round be
> dropped for DIP 1018, "The Copy Constructor", and have given it
> their formal approval. They consider copy constructors a critical
> feature for the langu
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 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 proposal" [1] which Andrei
says the DIP process is supposed to avo
On Sunday, 24 February 2019 at 10:46:37 UTC, 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.
The DIP:
https://github.com/dlang/DIPs/blob/master/DIPs/accepted/DIP1018.md
Yay! C
Walter and Andrei have requested the Final Review round be
dropped for DIP 1018, "The Copy Constructor", and have given it
their formal approval. They consider copy constructors a critical
feature for the language.
Walter provided feedback on Razvan's implementation. When it
reached a state w
72 matches
Mail list logo
