Re: Copy Constructor DIP
On Tuesday, 17 July 2018 at 14:41:06 UTC, ag0aep6g wrote: On 07/17/2018 03:03 PM, aliak00 wrote: [...] In a UDA `@implicit`, `implicit` is just a normal symbol. So the normal lookup rules apply. In particular, you can shadow an imported `implicit` with a local one: [...] Ah, gotcha! Thank you!
Re: Copy Constructor DIP
On Saturday, 14 July 2018 at 00:57:14 UTC, Andrei Alexandrescu
wrote:
[...]
chucklesomely profligate and ridiculously baroque.
Andrei
Hahaha this sentence... amazing! :D
I was going to propose auto this(ref A other) {} but nevermind :p
Cheers,
- Ali
Re: DIP 1014--Hooking D's struct move semantics--Final Review
On Thursday, 12 July 2018 at 10:24:40 UTC, Shachar Shemesh wrote: On 29/06/18 15:35, aliak wrote: On Wednesday, 27 June 2018 at 07:24:05 UTC, Mike Parker wrote: On Wednesday, 27 June 2018 at 07:13:14 UTC, Mike Parker wrote: Thanks in advance for your participation. For those of you using the NNTP or mailing list interfaces, this is the thread to respond in. Thanks! Alo! This is great! Just a clarification about the last paragraph phrasing The last line: "We can further reduce this problem by calling the function opPostMove." seemed to imply that an alternate name to opPostMove would be mentioned, but am I correct in understanding that it is just saying that "naming this second function as op* will keep code breakage to a minimum" ? This is a left over from a previous draft, where the operator was called "opMove". It should be removed. Also, what should happen if someone defines an opPostMove for a class. Compile error or? Should something about that be mentioned? I think nothing should happen. The function would be ignored, just like it is today. I am open to hear other ideas, however. I'm not sure whether it should be explicitly mentioned or not. Shachar A postblit on a class issues a compiler error. And an identity opAssign on a class also issues a compiler error. So I'm not sure how this would be different. And the page In https://dlang.org/spec/operatoroverloading.html also explicitly mentions differences between ops on classes or structs. Cheers, - Ali
Re: Copy Constructor DIP
On Tuesday, 17 July 2018 at 04:04:33 UTC, Manu wrote: On Mon., 16 Jul. 2018, 6:00 pm docandrew via Digitalmars-d, < digitalmars-d@puremagic.com> wrote: On Saturday, 14 July 2018 at 10:53:17 UTC, Andrei Alexandrescu wrote: > On 7/14/18 5:03 AM, Luís Marques wrote: >> If there is "no other meaning of @implicit" (other than the >> intersection of those two properties) why don't you just >> call it something like @copyctor? > > I'm totally cool with giving the attribute a more obscure > name such as @copyctor or anything people want really. > > (What follows is a personal opinion. > > I think it's better to choose a more general attribute name > with reduced initial applicability. Then application of said > attribute can be extended to other functions with ease. In > contrast, an obscure attribute name is sure to be followed > by more obscure attribute names. And don't get me started > about inventing new syntax. > > Regarding the hand-wringing over generality: we have an > exceedingly poor record of paralysis of analysis, whereby > we'd worry that every design decision potentially locks us > out from all other as-of-yet-unchosen design decisions. If > history is any indication, this sudden worry about > vaguely-promising green pastures of the future is a sign of > malady. We want copy construction. Conflating this with a > very general schemata for implicit conversion would not be a > wise decision in my opinion. I now deeply regret ever > telling Razvan to mention future possible directions. This > DIP must do implicit copy constructors and do it well, > nothing less and nothing more.) > > > Andrei I think in this case, a more obscure name like @copyctor is more descriptive. I fear that at some point, a more general attribute like "@implicit" will turn into the next "static". To me, @implicit smells like one of those keywords that will grow to carry many different meanings in different contexts and just end up overly-broad. But that's the point, and the key advantage of the name ;) Aye! And in this case it really is implicit copy construction. With this attribute in the compiler I can also see a future DIP that deprecates implicit construction and requires an explicit @implicit be added to constructors! Which also sounds like a win :D It's not ideal that the implicit attribute does not have a larger discussion around it. But it is nice to something in D where the default is the conservative approach and the more liberal has to be explicitly asked for. And at the same time, at this point it really is an attribute that is only applicable to copy constructors. So how much expansion on that would be enough I wonder? Cheers, - Ali
Re: Copy Constructor DIP
On Tuesday, 17 July 2018 at 07:27:32 UTC, Jacob Carlborg wrote: On Tuesday, 17 July 2018 at 00:04:12 UTC, Andrei Alexandrescu wrote: Then "negative" :o). In brief @implicit follows the same implementation as @safe and @nogc/ Why? This is a breaking change. Why not go with an approach that does not cause any breaking changes, which is just as easy to do? It also doesn't required any special casing in the parser. This is how @selector is implemented. -- /Jacob Carlborg Can you explain a bit more here? How does having implicit as a compiler recognized UDA avoid breaking changes as opposed to it being implemented like @nogc/@safe (how are those implemented differently anyway?) Cheers, - Ali
Re: REPL semantics
On Thursday, 12 July 2018 at 22:17:29 UTC, Luís Marques wrote:
On Thursday, 12 July 2018 at 21:51:18 UTC, aliak wrote:
Cool, is there on going work to sprucing up the D repl in the
dlang-community repo or is this a new attempt? Either way if
something is happening here then awesome!
Ah, that explains why my clone of drepl didn't compile: it was
the Martin Novak's repo, not the D community one. Although on
macOS it still doesn't compile, because of the lack of
_rt_loadLibrary.
Regarding your question: I was investigating this as part of my
own D-related compiler efforts (DHDL stuff), but it won't
materialize into a D repl anytime soon. I actually never tried
the existing REPLs, what are your issues with them?
Ah I see. Last I remember it was just too buggy to use so it
caused more pain than pleasure :p I don't remember the exact
details though sorry.
As for your question, hard to say me thinks. On the one hand,
being able to do this is nice:
const int i = 3;
const int j = 4;
void complexCalculation() { use i and j }
complexCalculation() // uses 3 and 4
const int j = 5;
complexCalculation // uses the new j
On the other hand being able to redefine the name "j" as some
other type to use in some other computation without having
`complexCalculation` get messed up is also nice :)
I hadn't even considered *redefining* symbols, only
overloading. cling doesn't support redefining. Mmmm...
Which is how the swift repl works:
1> func f(_ a: Float) { print("f") }
2> f(3)
f
3> func f(_ a: Int) { print("i") }
4> f(3)
i
5> func foo(_ a: Float) { print("f") }
6> func bar() { print(foo(3)) }
7> bar()
f
8> func foo(_ a: Int) { print("i") }
9> bar()
f
Yeah, I had tried basically the same Swift example. But my
point stands: I think that behavior can be explained by ease of
implementation. Finding an example of the alternative would be
much more interesting. Lacking that we are going to have to
actually *think* about the problem ;-)
The examples with the dynamic languages are less relevant.
We can try and think:
So if we think of adding an overload as "redefining a name" then
is it fair to generalize the question to: "should redefining
symbol A affect any previously defined symbol B that was
dependent on the previous definition of A?"
And then I'd say that defining an overload of symbol A is
technically a redefining of A - i.e. it's semantics change.
Redefinition affects:
+ Can change functionality of B without having to redefine all of
it
- Can cause things to stop working silently (think a tree of
hidden dependencies)
Redefinition does not affect:
+ The last defined symbol works "as expected"
- Must redefine symbols if you want them to use redefined
dependent definitions.
I think changing the value of a variable should affect any
dependent definitions, while redefining a variable should not
affect dependent symbols - an appeal to predicability is what I'm
going for.
And I think defining an overload falls under redefining a symbol.
Or you can also have the best of both worlds if you allow a
special repl annotation before any definitinons - @dynamic on
symbol A can mean that redefining it will affect dependent
Symbols for e.g.
Haskell's GHCi repl does the same as swift (with redefining
symbols at least, don't think it supports overloading in the
imperative language sense of the term). Though I think that makes
the most sense for haskell being a pure language.
Cheers,
- Ali
