Re: Blog post: What D got wrong
On Thu, 20 Dec 2018 14:19:33 +0100, Daniel Kozak wrote: > default(attributes..) is no needed. You can already do this by: > > pure @safe: > // your code That doesn't work if you have any member functions, and Walter says it's unlikely that that will ever change, even with a DIP. default(pure) would be new syntax with no existing code broken.
Re: Blog post: What D got wrong
On 12/19/18 2:58 PM, Neia Neutuladh wrote:
On Wed, 19 Dec 2018 17:28:01 +, Vijay Nayar wrote:
Could you please elaborate a little bit more on this? In the linked
program, I had expected that "ref" would return a reference to "a" that
would behave similar to a pointer.
They work like pointers that automatically dereference when assigning to
the base type.
Only three things in D can be ref:
* A function parameter
* A function return value
* A foreach variable (since that's either going to be a function return
value, a function parameter, or a pointer, depending on what you're
iterating over)
So when the compiler sees something like:
ref int foo();
auto a = foo();
It sees that the type of 'a' has to be the same as the return type of
'foo'. Except that's not possible, so it uses the nearest equivalent type:
int.
I would say it a little bit differently -- the return *type* of foo is
int. In D, ref is not part of the type at all.
For example, even when it *could* use ref, it doesn't:
int x;
ref int foo() { return x; }
void bar(Args...)(Args args)
{
pragma(msg, __traits(isRef, args[0]));
}
bar(foo()); // outputs false at compile time
The storage class is completely separate from the type. Which is
different from C++, where it's like a storage class but is really a type
constructor, hence Walter's post.
-Steve
Re: Blog post: What D got wrong
On Wednesday, 19 December 2018 at 23:10:34 UTC, Rubn wrote: On Wednesday, 19 December 2018 at 19:58:53 UTC, Neia Neutuladh wrote: [...] To be fair even in c++ this won't be a reference. int& foo(); auto a = foo(); // a == int auto& a = foo(); // a == int& So it shouldn't be that surprising. decltype(auto) a = foo(); // a == int& And you can explicitly declare `auto&` in C++, which you can't do in D.
Re: Blog post: What D got wrong
default(attributes..) is no needed. You can already do this by:
pure @safe:
// your code
But what is needed is some way to disable those attributes. As you
mentioned one way could be done by allowing this:
pure(false) or pure!false or @disable(pure,@nogc...)
>From implementation point of view it is not hard. I have already
implemented this before. I have even write some old DIP. But there is new
DIP process so someone need to write a new one and need to be able to get
it throw new DIP process. And I do not feel I have enough strength to do
this right now.
čt 20. 12. 2018 8:50 odesílatel Dgame via Digitalmars-d-announce <
digitalmars-d-announce@puremagic.com> napsal:
> On Thursday, 13 December 2018 at 18:29:39 UTC, Adam D. Ruppe
> wrote:
> > The attribute spam is almost longer than the function itself.
>
> I often wished for something like
>
>
> module foo.bar;
>
> default(@safe, pure);
>
> function foo() { } // is annotated with @safe & pure
>
> @deny(pure) // or pure(false) as I suggested a long time ago
> function bar() { } // is annotated only with @safe
>
>
> That would IMO lighten the burden.
>
Re: Blog post: What D got wrong
On Thursday, 13 December 2018 at 18:29:39 UTC, Adam D. Ruppe
wrote:
The attribute spam is almost longer than the function itself.
I often wished for something like
module foo.bar;
default(@safe, pure);
function foo() { } // is annotated with @safe & pure
@deny(pure) // or pure(false) as I suggested a long time ago
function bar() { } // is annotated only with @safe
That would IMO lighten the burden.
Re: Blog post: What D got wrong
On 12/13/2018 10:29 AM, Adam D. Ruppe wrote: The attribute spam is almost longer than the function itself. Attributes only start to matter when creating code that will be around for a long time (such as reusable libraries). It's a waste of effort for short term code.
Re: Blog post: What D got wrong
On Wednesday, 19 December 2018 at 19:58:53 UTC, Neia Neutuladh wrote: On Wed, 19 Dec 2018 17:28:01 +, Vijay Nayar wrote: Could you please elaborate a little bit more on this? In the linked program, I had expected that "ref" would return a reference to "a" that would behave similar to a pointer. They work like pointers that automatically dereference when assigning to the base type. Only three things in D can be ref: * A function parameter * A function return value * A foreach variable (since that's either going to be a function return value, a function parameter, or a pointer, depending on what you're iterating over) So when the compiler sees something like: ref int foo(); auto a = foo(); It sees that the type of 'a' has to be the same as the return type of 'foo'. Except that's not possible, so it uses the nearest equivalent type: int. And if you have: ref int foo(); int a = foo(); That obviously converts by copying the value. To be fair even in c++ this won't be a reference. int& foo(); auto a = foo(); // a == int auto& a = foo(); // a == int& So it shouldn't be that surprising.
Re: Blog post: What D got wrong
On Wed, 19 Dec 2018 17:28:01 +, Vijay Nayar wrote: > Could you please elaborate a little bit more on this? In the linked > program, I had expected that "ref" would return a reference to "a" that > would behave similar to a pointer. They work like pointers that automatically dereference when assigning to the base type. Only three things in D can be ref: * A function parameter * A function return value * A foreach variable (since that's either going to be a function return value, a function parameter, or a pointer, depending on what you're iterating over) So when the compiler sees something like: ref int foo(); auto a = foo(); It sees that the type of 'a' has to be the same as the return type of 'foo'. Except that's not possible, so it uses the nearest equivalent type: int. And if you have: ref int foo(); int a = foo(); That obviously converts by copying the value.
Re: Blog post: What D got wrong
On Wednesday, 12 December 2018 at 07:44:12 UTC, Walter Bright wrote: On 12/11/2018 4:51 AM, Nicholas Wilson wrote: > Returning a reference Wow, thats f*ck'n stupid! https://run.dlang.io/is/SAplYw It's quite deliberate. ref in C++ is a type constructor, but it's so special-cased to behave like a storage class, it might as well be one. In D it is. (For example, ref in C++ can only appear at the top level. There are no "pointers to refs".) refs exist so the lifetime of them can be controlled for memory safety. Treating them as flexibly as pointers would make that pretty difficult. refs are the primary way a memory safe container can expose pointers to its contents. Could you please elaborate a little bit more on this? In the linked program, I had expected that "ref" would return a reference to "a" that would behave similar to a pointer. But when that reference is assigned to "b", and "b" is modified, "a" appears to retain its original value, implying that "b" is a copy. When was the copy of "a" made? Was it during the assignment to "b"? I use ref regularly, especially when I have to port C++ code that does exactly that, exposing modifiable references to its members. And in my experience it works quite well, especially for array types and classes. So what is the best way to understand this program and know why a copy of "a" is made?
Re: Blog post: What D got wrong
On Wed, 2018-12-19 at 01:45 +, Neia Neutuladh via Digitalmars-d-announce wrote: > On Wed, 19 Dec 2018 01:04:24 +, Nathan S. wrote: > > On Saturday, 15 December 2018 at 19:53:06 UTC, Atila Neves wrote: > > > Not the case in Rust, not the case in how I write D. TBH it's not such > > > a big deal because something has to be typed, I just default to const > > > now anyway instead of auto. @safe and pure though... > > > > I'd be interested in seeing some of that Rust code. My impression from > > Clojure is that an all-immutable style requires leaning heavily on the > > garbage collector and as far as I know Rust has none. Rust is garbage collector free. This is why it is appealing to the C (and C++) people who think garbage collectors are anathema. Rust has let and let mut to introduce new bindings and variables respectively, you have to type less for immutable, which his the right way round. If you want mutability, you have to say so explicitly. Single assignment rocks. :-) > It is greatly simplified by automatic memory management. Rust doesn't have > a GC, but it has a complex ownership system instead, and that's the basis > of its memory management. When that's insufficient, you use reference > counting. With Rust (as with most languages) you have to separate stack and heap allocation. The Rust borrow checker carefully tracks all stack usage and (caveat unsafe activity) will not compile code that has any memory problems that the borrow checker can find. For the heap, Rust provides reference counted pointers which work a lot better than the equivalents in C++: std::shared_ptr and std::unique_ptr can be a right pain. Also of course, unlike C++, Rust has very good support for multi-threading in the language and the standard library, mostly built around std::Mutex. Rust integrates all this with std::Option, std::Error, if let, and match in a way that makes dealing with locks and RAII quite simple. C++ may have brought RAII to mainstream programming, but it's support for multiple threads is still very weak comparedto D, Rust, Go, etc. […] -- Russel. === Dr Russel Winder t: +44 20 7585 2200 41 Buckmaster Roadm: +44 7770 465 077 London SW11 1EN, UK w: www.russel.org.uk signature.asc Description: This is a digitally signed message part
Re: Blog post: What D got wrong
On Tuesday, December 18, 2018 1:17:28 AM MST Russel Winder via Digitalmars- d-announce wrote: > On Mon, 2018-12-17 at 12:16 -0800, Walter Bright via > Digitalmars-d-announce > wrote: > > […] > > > > Going pure, however, is much harder (at least for me) because I'm not > > used to > > programming that way. Making a function pure often requires > > reorganization of > > how a task is broken up into data structures and functions. > > > > […] > > I can recommend a short period of working only with Haskell. And then a > short period working only with Prolog. Experience with Java and Python > people trying to get them to internalise the more declarative approach to > software, shows that leaving their programming languages of choice behind > for a while is important in improving their use of their languages of > choice. +1 The only reason that I'm as good at writing functional-style code as I am is because I used Haskell as my goto language for a couple of years towards the end of college. By being forced to program functionally, I got _much_ better at things like recursion, and it significantly improved aspects of my programming in languages like C++ or D. That being said, I think that anyone who programs in such a language longterm by choice has got to be a masochist. Functional programming is a fantastic tool to have in your toolbox, but man does it force you to contort things to make it work in many cases. I've never spent as much time per line of code with any other language as I did with haskell. It's great for stretching your brain but terrible for being productive. I'm sure that folks who always program that way get much better at it, but some problems simply work better with other programming paradigms, and it's fantastic to use a language like D that allows you to program in a variety of paradigms rather than forcing a particular paradigm on you all the time. But without spending a lot of time in a language that forces a particular paradigm, you're likely to be much worse at that particular paradigm in a flexible language such as D. One side effect of having spent as much time as I did with haskell is that I've rarely found the functional nature of D's templates to be much of a problem. Sometimes, it can be, and the addition of static foreach is certainly welcome, but I rarely missed it, because I rarely needed it. The declaritive stuff just tends to fit nicely into the functional paradigm in ways that normal functions often don't. LOL. And it took quite a while before I realized that templates were really a functional language (in fact, I think that I only realized it when I read Bartosz's article on the subject). I just understood how to use them and didn't think about it, though once I did realize it, I felt stupid for not having realized it. - Jonathan M Davis
Re: Blog post: What D got wrong
On Tuesday, December 18, 2018 8:00:48 AM MST Steven Schveighoffer via Digitalmars-d-announce wrote: > On 12/17/18 4:42 AM, Dukc wrote: > > On Monday, 17 December 2018 at 09:41:01 UTC, Dukc wrote: > >> On Saturday, 15 December 2018 at 19:53:06 UTC, Atila Neves wrote: > >>> @safe and pure though... > >> > >> Why @safe? Can't you just write "@safe:" on top and switch to > >> @system/@trusted as needed? > > > > Argh, I forgot that you are not supposed to @safe templates away. > > You can apply @safe to anything. It's @trusted you have to be careful > with. > > Of course, it probably won't work for many templates. @safe should only be used on a template if the @safety of the code does not depend on the template arguments, and it frequently does depend on them. Mass-applying attributes should rarely be done with templated code. It already causes enough problems with non-templated code, because it's easy to not realize that an attribute has been mass-applied, but without a way to explicitly mark a templated function so that an attribute is inferred in spite of it being mass-applied, mass-applying attributes with templated code will usually result in attributes being wrongly applied. Now, for any attribute other than @trusted, the worst that you're going to get out of incorrectly applying an attribute to a template is a compilation error when a particular instantiation doesn't work with that attribute, whereas for @trusted it's a disaster in the making. Mass-applying @trusted is almost always a terrible idea. The one exception would maybe be something like the bindings in druntime, where a number of modules do it, because it's just a bunch of C prototypes. But even then, there's a high risk of marking a function as @trusted later when someone adds it and doesn't realize that @trusted was applied. - Jonathan M Davis
Re: Blog post: What D got wrong
On Tuesday, December 18, 2018 7:02:43 PM MST H. S. Teoh via Digitalmars-d- announce wrote: > On Tue, Dec 18, 2018 at 06:53:02PM -0700, Jonathan M Davis via > Digitalmars-d-announce wrote: [...] > > > I confess that I do tend to think about things from the standpoint of > > a library designer though, in part because I work on stuff like > > Phobos, but also because I tend to break up my programs into libraries > > as much as reasonably possible. In general, the more that's in a > > reusable, easily testable library the better. And with that approach, > > a lot less of the code for your programs is actually in the program > > itself, and the attributes tend to matter that much more. > > [...] > > My recent programming style has also become very library-like, often > with standalone library-style pieces of code budding off a messier, > experimental code in main() (and ultimately, if the project is > long-lasting, main() itself becomes stripped down to the bare > essentials, just a bunch of library components put together). But I've > not felt a strong urge to deal with attributes in any detailed way; > mostly I just templatize everything and let the compiler do attribute > inference on my behalf. For the few cases where explicit attributes > matter, I still only use the bare minimum I can get away with, and > mostly just enforce template attributes using the unittest idiom rather > than bother with writing explicit attributes everywhere in the actual > code. That works when you're in control of everything and not making libraries public, but it tends to be worse when you're making stuff publicly available, because then there's a much higher risk of accidentally screwing up someone else's code by breaking an attribute. It's also much worse from a documentation standpoint, because users of the library can't look at the documentation to know which attributes are in effect. That's pretty much unavoidable with heavily templated code, but there are generally going to be fewer maintainence problems with a publicly available library if attributes are explicit. And the more heavily used the library is, the more likely it is that there are going to be problems. It's like how if you want your library to be stable with regards to CTFE, you pretty much have to test that CTFE works in your unit tests. It's easy to forget, and ideally, you wouldn't have to worry about it, but if someone else uses your library and uses one of its functions with CTFE, and you then make a change that doesn't work with CTFE and don't realize it, you'll break their code. Ideally, you wouldn't have to worry about ensuring that stuff works with CTFE (after all, D specifically doesn't require that stuff be marked to work with it), but with regards to publicly available libraries, if it's not tested for, it can become a problem. So, arguably, it's best practice to test that stuff works with CTFE (at least in publicly available libraries), but I doubt that all that many libraries actually do it. And attributes are in the same boat in many respects (especially if attribute inference is used heavily). But again, if you're not making stuff publicly available, it's usually easy to just not worry about attributes (or CTFE-ability) except in those cases where you have to or decide that you need to in order to ensure that a particular attribute and its benefits are in effect. It's when you make stuff publicly available that it becomes more of an issue - especially if the library is heavily used. - Jonathan M Davis
Re: Blog post: What D got wrong
On Tue, Dec 18, 2018 at 06:53:02PM -0700, Jonathan M Davis via Digitalmars-d-announce wrote: [...] > I confess that I do tend to think about things from the standpoint of > a library designer though, in part because I work on stuff like > Phobos, but also because I tend to break up my programs into libraries > as much as reasonably possible. In general, the more that's in a > reusable, easily testable library the better. And with that approach, > a lot less of the code for your programs is actually in the program > itself, and the attributes tend to matter that much more. [...] My recent programming style has also become very library-like, often with standalone library-style pieces of code budding off a messier, experimental code in main() (and ultimately, if the project is long-lasting, main() itself becomes stripped down to the bare essentials, just a bunch of library components put together). But I've not felt a strong urge to deal with attributes in any detailed way; mostly I just templatize everything and let the compiler do attribute inference on my behalf. For the few cases where explicit attributes matter, I still only use the bare minimum I can get away with, and mostly just enforce template attributes using the unittest idiom rather than bother with writing explicit attributes everywhere in the actual code. T -- He who sacrifices functionality for ease of use, loses both and deserves neither. -- Slashdotter
Re: Blog post: What D got wrong
On Tuesday, December 18, 2018 6:35:34 AM MST Pjotr Prins via Digitalmars-d- announce wrote: > On Tuesday, 18 December 2018 at 11:25:17 UTC, Jonathan M Davis > > wrote: > > Of course, even if we _did_ have a solution for reversing > > attributes, slapping an attribute on the top of the module > > would still potentially be a maintenance problem, because it's > > then really easy to miss that an attribute is in effect (it's a > > problem that we've had on several occasions with druntime and > > Phobos in the few cases where attributes are mass-applied). So, > > there is no silver bullet here (though regardless of whether > > mass-applying attributes is something that should ever be > > considered good practice, we really should add a way to be able > > to reverse them). > > Thanks Jonathan for your elaborate explanation. I personally have > no problem with the attributes which - in practice - means I > don't use them much unless I want to make sure something is nogc, > for example. For library designers it makes sense to be explicit. > I guess that is where the trade-off kicks in. Maybe it is just a > feature. We argue against specifying them because other languages > are not as explicit. It does add a little noise. In practice, library developers are forced to worry about it more, because it affects everyone using their code, whereas within a program, how valuable it is to worry about them depends on the size of the program and what you expect to get out of them. Very large programs can definitely benefit (especially with @safe and pure), because it reduces how much code you have to worry about when tracking down the problems that those attributes address, but with small programs, the benefit is far more debatable. And for simple scripts and the like, they're almost certainly a waste of time - which is part of why more restrictive attributes are not the default. It's supposed to be easy to write code that doesn't deal with attributes if you don't want to, but they're there for those who do care. The problem of course is that when you do care, they tend to become a bit of a pain. I confess that I do tend to think about things from the standpoint of a library designer though, in part because I work on stuff like Phobos, but also because I tend to break up my programs into libraries as much as reasonably possible. In general, the more that's in a reusable, easily testable library the better. And with that approach, a lot less of the code for your programs is actually in the program itself, and the attributes tend to matter that much more. - Jonathan M Davis
Re: Blog post: What D got wrong
On Wed, 19 Dec 2018 01:04:24 +, Nathan S. wrote: > On Saturday, 15 December 2018 at 19:53:06 UTC, Atila Neves wrote: >> Not the case in Rust, not the case in how I write D. TBH it's not such >> a big deal because something has to be typed, I just default to const >> now anyway instead of auto. @safe and pure though... > > I'd be interested in seeing some of that Rust code. My impression from > Clojure is that an all-immutable style requires leaning heavily on the > garbage collector and as far as I know Rust has none. It is greatly simplified by automatic memory management. Rust doesn't have a GC, but it has a complex ownership system instead, and that's the basis of its memory management. When that's insufficient, you use reference counting. Besides which, this is about defaults. In cases where your data is actually mutable and it would be awkward to switch to a more Haskell-like way of coding, you can still use that.
Re: Blog post: What D got wrong
On Saturday, 15 December 2018 at 19:53:06 UTC, Atila Neves wrote: Not the case in Rust, not the case in how I write D. TBH it's not such a big deal because something has to be typed, I just default to const now anyway instead of auto. @safe and pure though... I'd be interested in seeing some of that Rust code. My impression from Clojure is that an all-immutable style requires leaning heavily on the garbage collector and as far as I know Rust has none.
Re: Blog post: What D got wrong
On 18-12-2018 19:52, Russel Winder wrote: On Tue, 2018-12-18 at 16:50 +, Neia Neutuladh via Digitalmars-d-announce wrote: Is there a video link for that talk? I'd be interested in hearing it. The videos are here: https://gstconf.ubicast.tv/channels/#gstreamer-conference-2018 I think they recorded the lightning talks as a single video, so you'll have to fast forward to my little bit. If you are only interested in the MeTV part, this is the start of that lighting talk: https://gstconf.ubicast.tv/permalink/v125ac3127116gnuo89h/#start=2561 -- Mike Wey
Re: Blog post: What D got wrong
On Tue, 2018-12-18 at 16:50 +, Neia Neutuladh via Digitalmars-d-announce wrote: > On Tue, 18 Dec 2018 08:17:28 +, Russel Winder wrote: > > I did a lightning talk at the GStreamer conference in Edinburgh a couple > > of months ago, concluding that I think D (which about half the audience > > knew of) is overall better than Rust for GTK+ and GStreamer > > applications, but recognising that Rust is actually the replacement for > > C and C++ for GTK+ and GStreamer applications. (Obviously Python has an > > ongoing role in all this as well.) > > Is there a video link for that talk? I'd be interested in hearing it. The videos are here: https://gstconf.ubicast.tv/channels/#gstreamer-conference-2018 I think they recorded the lightning talks as a single video, so you'll have to fast forward to my little bit. I see from: https://pengutronix.de/de/2018-10-29-gstconf-2018.html That it has been described "an entertaining lightning talk about the history of MeTV, a live TV viewing application, up to the latest rewrite in Rust using GStreamer" -- Russel. === Dr Russel Winder t: +44 20 7585 2200 41 Buckmaster Roadm: +44 7770 465 077 London SW11 1EN, UK w: www.russel.org.uk signature.asc Description: This is a digitally signed message part
Re: Blog post: What D got wrong
On Tue, 18 Dec 2018 08:17:28 +, Russel Winder wrote: > I did a lightning talk at the GStreamer conference in Edinburgh a couple > of months ago, concluding that I think D (which about half the audience > knew of) is overall better than Rust for GTK+ and GStreamer > applications, but recognising that Rust is actually the replacement for > C and C++ for GTK+ and GStreamer applications. (Obviously Python has an > ongoing role in all this as well.) Is there a video link for that talk? I'd be interested in hearing it.
Re: Blog post: What D got wrong
On Tue, Dec 18, 2018 at 08:17:28AM +, Russel Winder via Digitalmars-d-announce wrote: > On Mon, 2018-12-17 at 12:16 -0800, Walter Bright via Digitalmars-d-announce > wrote: > > […] > > > > Going pure, however, is much harder (at least for me) because I'm > > not used to programming that way. Making a function pure often > > requires reorganization of how a task is broken up into data > > structures and functions. Component-based programming helps a lot in this regard. It breaks the problem down in a way that, when done correctly, captures the essence of the algorithm in a way that's easily translated to pure code (esp. D's expanded definition of purity). [...] > I can recommend a short period of working only with Haskell. And then > a short period working only with Prolog. Experience with Java and > Python people trying to get them to internalise the more declarative > approach to software, shows that leaving their programming languages > of choice behind for a while is important in improving their use of > their languages of choice. [...] It's all about the mindset. Being forced to think about the problem from a purely functional perspective gives you a radically different perspective from the usual imperative paradigm, and IME often yields insight into the essential structure of your programming problem that is otherwise easily obscured by the imperative structure imposed upon it. T -- Klein bottle for rent ... inquire within. -- Stephen Mulraney
Re: Blog post: What D got wrong
On Monday, 17 December 2018 at 11:04:13 UTC, Atila Neves wrote: Why @safe? Can't you just write "@safe:" on top and switch to @system/@trusted as needed? Not quite. It doesn't work the way most people expect for member functions and causes problems for templates. Don't templates infer attributes? @safe didn't work well for trusted aggregates (including inference), not sure if dip1000 fixes that.
Re: Blog post: What D got wrong
On 12/17/18 4:42 AM, Dukc wrote: On Monday, 17 December 2018 at 09:41:01 UTC, Dukc wrote: On Saturday, 15 December 2018 at 19:53:06 UTC, Atila Neves wrote: @safe and pure though... Why @safe? Can't you just write "@safe:" on top and switch to @system/@trusted as needed? Argh, I forgot that you are not supposed to @safe templates away. You can apply @safe to anything. It's @trusted you have to be careful with. Of course, it probably won't work for many templates. -Steve
Re: Blog post: What D got wrong
On Tue, 2018-12-18 at 12:20 +, Kagamin via Digitalmars-d-announce wrote: > On Tuesday, 18 December 2018 at 10:19:14 UTC, Russel Winder wrote: > > Clojure is but you have to work hard for that, the initial > > language is effectively pure. > > https://ideone.com/y8KWja clearly it isn't, its site only claims > that most code happens to be pure, but it looks like it's not > checked in any way and not sure if purity can be even checked > there. Can we all agree that Haskell is a pure functional language. I think we must because: a) it says it is, and b) it is. f2 = print "Hello World." f1 = f2 main = do f1 result of running this: GHCi, version 8.0.1 > "Hello World." > OK so Haskell uses monads and Clojure just uses the JVM I/O. Haskell is pure, Clojure is impure. But I stand by my original statement: Clojure is best used as a pure language. Even if I/O is impure, you can make it pure with monads if you really have to. -- Russel. === Dr Russel Winder t: +44 20 7585 2200 41 Buckmaster Roadm: +44 7770 465 077 London SW11 1EN, UK w: www.russel.org.uk signature.asc Description: This is a digitally signed message part
Re: Blog post: What D got wrong
On Tuesday, 18 December 2018 at 11:25:17 UTC, Jonathan M Davis wrote: Of course, even if we _did_ have a solution for reversing attributes, slapping an attribute on the top of the module would still potentially be a maintenance problem, because it's then really easy to miss that an attribute is in effect (it's a problem that we've had on several occasions with druntime and Phobos in the few cases where attributes are mass-applied). So, there is no silver bullet here (though regardless of whether mass-applying attributes is something that should ever be considered good practice, we really should add a way to be able to reverse them). Thanks Jonathan for your elaborate explanation. I personally have no problem with the attributes which - in practice - means I don't use them much unless I want to make sure something is nogc, for example. For library designers it makes sense to be explicit. I guess that is where the trade-off kicks in. Maybe it is just a feature. We argue against specifying them because other languages are not as explicit. It does add a little noise.
Re: Blog post: What D got wrong
On Tuesday, 18 December 2018 at 12:20:48 UTC, Kagamin wrote: On Tuesday, 18 December 2018 at 10:19:14 UTC, Russel Winder wrote: Clojure is but you have to work hard for that, the initial language is effectively pure. https://ideone.com/y8KWja clearly it isn't, its site only claims that most code happens to be pure, but it looks like it's not checked in any way and not sure if purity can be even checked there. From the Clojure homepage: "Clojure is impure, yet stands behind the philosophy that programs that are more functional are more robust." The goal is to make it easy to program in a functional style, not to provide a pure functional programming language. It is like OCaml in that respect.
Re: Blog post: What D got wrong
On Tuesday, 18 December 2018 at 10:19:14 UTC, Russel Winder wrote: Clojure is but you have to work hard for that, the initial language is effectively pure. https://ideone.com/y8KWja clearly it isn't, its site only claims that most code happens to be pure, but it looks like it's not checked in any way and not sure if purity can be even checked there.
Re: Blog post: What D got wrong
On Tuesday, December 18, 2018 3:36:15 AM MST Pjotr Prins via Digitalmars-d-
announce wrote:
> On Thursday, 13 December 2018 at 18:29:39 UTC, Adam D. Ruppe
>
> wrote:
> > On Thursday, 13 December 2018 at 10:29:10 UTC, RazvanN wrote:
> >> Do you honestly think that they will ever take D into account
> >> if @safe and immutable data will be the default?
> >
> > D needs to stop chasing after what you think people think they
> > want and just start being good for us.
> >
> > The majority of my code is written pretty permissively - I like
> > my pointers, my gotos, my GC, my exceptions. But I'm willing to
> > consider the change because I actually don't think it will be
> > that big of a hassle, and will be better overall. I wanna show
> > you something:
> >
> > /// Static convenience functions for common color names
> > nothrow pure @nogc @safe
> > static Color transparent() { return Color(0, 0, 0, 0); }
> >
> >
> > The attribute spam is almost longer than the function itself.
>
> Isn't it the way forward that the compiler deduces these
> attributes and fills them in automatically? All these can be
> inferenced. Only when the caller wants to guarantee, say pure, it
> could add it explicitly. I read somewhere that the compiler
> already does this to some degree. And even the generated docs
> should be able to show it.
In general, functions that have to have their source available have their
attributes inferred. So, templated functions, lambdas, and auto return
functions all have attribute inference at this point. Attribute inference
was introduced originally as being only for templated functions, because you
_have_ to have it for them for them to really work with attributes (at least
in any situation where whether an attribute is applicable depends on the
template arguments - which is frequently the case), but it's been expanded
over time. However, D's compilation model is such that many functions will
never have attribute inference, because it's frequently not guaranteed that
the compiler has the source code for a function in all cases where it's
called.
That being said, there are some serious downsides to attribute inference. It
makes it much harder to know which attributes actually apply to a function,
and it tends to result in folks not bothering with making sure that they're
code works with a particular attribute; they just let attribute inference
take care of it all and don't worry about it (in which case, the result is
comparable to not having attribute inference in some respects). Another big
issue is that when the attributes are inferred, it, becomes _very_ easy to
accidentally change which attributes a function has when changing its
implementation (similar to how its very easy to accidentally make it so that
a function no longer works with CTFE). The primary way to combat that is to
use explicit attributes on the unittest blocks which test the function, but
that's easy to forget to do, and in a way, it's just moving the explicit
attributes from the function itself to the unit tests. So, whether it
actually fixes anything is debatable.
In general, the cleanest approach is to be as explicit about attributes as
possible (which means still using attribute inference with templated
functions when the attribute should depend on the template arguments but to
not use it much of anywhere else). However, that then requires that you mark
up your functions everywhere, which can be very tedious, and many folks
don't want to do it. Of course, using more attribute inference reduces that
particular problem (which is why many folks want it), but you then get a
different set of problems due to the fact that attributes are inferred
instead of explicit.
So, there's really no winning. In some ways, minimizing attribute inference
is the best option, and in others, maximizing it would be better. Probably
the best solution to the problem would be to have the defaults better match
up with what your average program needs, but no set of defaults fits every
program, and different coding styles can result in very different opinions
on which set of attributes should be the default. I very much doubt that you
would find much of a consensus on it even just within the core set of
developers working on dmd, druntime, and Phobos.
My guess is that if code breakage were somehow not part of the question that
the majority of D programmers would be in favor of @safe by default, since
the vast majority of code can be @safe (though plenty of the time
programmers don't bother to mark it as @safe), and in theory, only small
portions of a program should typically need to be marked as @system. But I
expect that any other attribute would result in a lot of arguing. For
instance, in some respects, pure would be great as the default, but that
doesn't interact well at all with stuff like I/O, making it so that you have
to write your programs in a certain way for pure to work well for most
functions, and not everyone wants to do that. Some folks
Re: Blog post: What D got wrong
On Thursday, 13 December 2018 at 18:29:39 UTC, Adam D. Ruppe
wrote:
On Thursday, 13 December 2018 at 10:29:10 UTC, RazvanN wrote:
Do you honestly think that they will ever take D into account
if @safe and immutable data will be the default?
D needs to stop chasing after what you think people think they
want and just start being good for us.
The majority of my code is written pretty permissively - I like
my pointers, my gotos, my GC, my exceptions. But I'm willing to
consider the change because I actually don't think it will be
that big of a hassle, and will be better overall. I wanna show
you something:
/// Static convenience functions for common color names
nothrow pure @nogc @safe
static Color transparent() { return Color(0, 0, 0, 0); }
The attribute spam is almost longer than the function itself.
Isn't it the way forward that the compiler deduces these
attributes and fills them in automatically? All these can be
inferenced. Only when the caller wants to guarantee, say pure, it
could add it explicitly. I read somewhere that the compiler
already does this to some degree. And even the generated docs
should be able to show it.
Re: Blog post: What D got wrong
On Tue, 2018-12-18 at 09:59 +, Kagamin via Digitalmars-d-announce wrote: > […] > AIU rust, clojure and prolog are impure. Clearly Rust is because it allows for mutability, though it is not the default. Clojure is but you have to work hard for that, the initial language is effectively pure. I have no idea how the term impure can be applied to Prolog. -- Russel. === Dr Russel Winder t: +44 20 7585 2200 41 Buckmaster Roadm: +44 7770 465 077 London SW11 1EN, UK w: www.russel.org.uk signature.asc Description: This is a digitally signed message part
Re: Blog post: What D got wrong
On Tuesday, 18 December 2018 at 08:17:28 UTC, Russel Winder wrote: Rust I feel has a pivotal role in all this. By emphasising the ML view on mixed declarative and imperative programming, it has found an interesting middle ground that seems to work very well. Many of the C programmers who though C++ overcomplicated and not worth looking at, are taking to Rust and in doing so leaving C behind. AIU rust, clojure and prolog are impure.
Re: Blog post: What D got wrong
On Mon, 2018-12-17 at 12:16 -0800, Walter Bright via Digitalmars-d-announce wrote: > […] > > Going pure, however, is much harder (at least for me) because I'm not used > to > programming that way. Making a function pure often requires reorganization > of > how a task is broken up into data structures and functions. > > […] I can recommend a short period of working only with Haskell. And then a short period working only with Prolog. Experience with Java and Python people trying to get them to internalise the more declarative approach to software, shows that leaving their programming languages of choice behind for a while is important in improving their use of their languages of choice. For Java people this is quite easy since there is Frege (an implementation of Haskell on the JVM) and Clojure (a Lisp on the JVM). They do not have to leave the comfort of their JVM to get away from Java. On return to Java, people's use of Option, and lambda expressions, etc. was markedly different – and a lot more declarative, making testing as well as comprehensibility of their much better. For Python people you have to play slightly different games, such as requiring no use of for and while loops, since there is no pure declarative language on the PVM – the computational model of the PVM actually makes declarative programming quite hard, but it is possible, and it improves code comprehensibility and testability. The problem for people immersed in the C, and C++ world is internalising declarative as a concept. I have tried, and failed a few times, as well as succeeding some. As C++ evolves towards being more and more declarative, it seems hard for the average C++ programmer to really move on from "old style C++", despite all the literature on "modern C++". But as the standards committee drag C++ along the increasingly declarative code route, things change, albeit relatively slowly. Rust I feel has a pivotal role in all this. By emphasising the ML view on mixed declarative and imperative programming, it has found an interesting middle ground that seems to work very well. Many of the C programmers who though C++ overcomplicated and not worth looking at, are taking to Rust and in doing so leaving C behind. On a personal level, I am now doing most of my programming in Rust rather than D, but this is as much to do with the GStreamer community choosing Rust as the replacement for C for GStreamer. But this is from a library implementers perspective, rather than an application perspective – but the choice pushes through. D (with GtkD and GStreamerD) is in many ways as good a choice as gtk- rs and gstreeamer-rs for writing applications – except: – documentation for gtk-rs and gstreamer-rs is better than for GtkD and GStreamerD; and – the standard Rust executor and futures system has been integrated into gtk- rs, something not present in GtkD. – GStreamer core developers have an obsessive fear of the word "garbage collector". I did a lightning talk at the GStreamer conference in Edinburgh a couple of months ago, concluding that I think D (which about half the audience knew of) is overall better than Rust for GTK+ and GStreamer applications, but recognising that Rust is actually the replacement for C and C++ for GTK+ and GStreamer applications. (Obviously Python has an ongoing role in all this as well.) I think D has missed the opportunity to get significant traction in the GTK+ and GStreamer milieus. :-( -- Russel. === Dr Russel Winder t: +44 20 7585 2200 41 Buckmaster Roadm: +44 7770 465 077 London SW11 1EN, UK w: www.russel.org.uk signature.asc Description: This is a digitally signed message part
Re: Blog post: What D got wrong
On 12/15/2018 11:53 AM, Atila Neves wrote: @safe and pure though... @safe is not so hard to adopt, since by using @trusted one can proceed incrementally. Going pure, however, is much harder (at least for me) because I'm not used to programming that way. Making a function pure often requires reorganization of how a task is broken up into data structures and functions. For example, https://github.com/dlang/dmd/blob/master/src/dmd/target.d It's nearly all global variables that manipulate other global variables. I recently added a parameter to _init() so that it didn't need to access global.params. Now if the Target.* __gshared's could instead be replaced with fields, then _init() could be made pure.
Re: Blog post: What D got wrong
On Monday, 17 December 2018 at 09:41:01 UTC, Dukc wrote: On Saturday, 15 December 2018 at 19:53:06 UTC, Atila Neves wrote: @safe and pure though... Why @safe? Can't you just write "@safe:" on top and switch to @system/@trusted as needed? Not quite. It doesn't work the way most people expect for member functions and causes problems for templates.
Re: Blog post: What D got wrong
On Saturday, 15 December 2018 at 19:53:06 UTC, Atila Neves wrote: @safe and pure though... Why @safe? Can't you just write "@safe:" on top and switch to @system/@trusted as needed?
Re: Blog post: What D got wrong
On Monday, 17 December 2018 at 09:41:01 UTC, Dukc wrote: On Saturday, 15 December 2018 at 19:53:06 UTC, Atila Neves wrote: @safe and pure though... Why @safe? Can't you just write "@safe:" on top and switch to @system/@trusted as needed? Argh, I forgot that you are not supposed to @safe templates away.
Re: Blog post: What D got wrong
On Sat, 2018-12-15 at 19:53 +, Atila Neves via Digitalmars-d-announce wrote: > On Saturday, 15 December 2018 at 02:16:36 UTC, Nathan S. wrote: > > On Thursday, 13 December 2018 at 10:14:45 UTC, Atila Neves > > wrote: > > > My impression is that it's a consensus that it _should_, but > > > it's not going to happen due to breaking existing code. > > > > I think it would be a bad idea for `immutable` because more > > often than not it would need to be turned off. > > Not the case in Rust, not the case in how I write D. TBH it's not > such a big deal because something has to be typed, I just default > to const now anyway instead of auto. @safe and pure though... Shouldn't be the case in Java either, since it is and always has been a single assignment supporting language – it's just that they made mutable the default, and trained people not use final. -- Russel. === Dr Russel Winder t: +44 20 7585 2200 41 Buckmaster Roadm: +44 7770 465 077 London SW11 1EN, UK w: www.russel.org.uk signature.asc Description: This is a digitally signed message part
Re: Blog post: What D got wrong
On Saturday, 15 December 2018 at 02:16:36 UTC, Nathan S. wrote: On Thursday, 13 December 2018 at 10:14:45 UTC, Atila Neves wrote: My impression is that it's a consensus that it _should_, but it's not going to happen due to breaking existing code. I think it would be a bad idea for `immutable` because more often than not it would need to be turned off. Not the case in Rust, not the case in how I write D. TBH it's not such a big deal because something has to be typed, I just default to const now anyway instead of auto. @safe and pure though...
Re: Blog post: What D got wrong
On Tuesday, 11 December 2018 at 10:45:39 UTC, Atila Neves wrote: A few things that have annoyed me about writing D lately: https://atilanevesoncode.wordpress.com/2018/12/11/what-d-got-wrong/ Wait, no word about ref parameters? No way! If you try to bind to typical C++ code they are *EVERYWHERE*, add to that inability to make ref variable(well, it can be mimick'd by wrapping in a helper function but it still sucks) and it completely destroys the usability. In its current form ref in D is PITA... When it comes to C++ interop unfortunatelly it is too much left to wish
Re: Blog post: What D got wrong
On Thursday, 13 December 2018 at 10:14:45 UTC, Atila Neves wrote: My impression is that it's a consensus that it _should_, but it's not going to happen due to breaking existing code. I think it would be a bad idea for `immutable` because more often than not it would need to be turned off. I've heard Java called a "BSDM language" because it forces the programmer to type reams of unnecessary characters to accomplish ordinary tasks. This reminds me of that.
Re: Blog post: What D got wrong
On Thursday, 13 December 2018 at 18:29:39 UTC, Adam D. Ruppe wrote: 2) LETTING US TURN THEM OFF. SERIOUSLY WHY DON'T WE HAVE `virtual`, `throws`, `impure` AND THE REST?! THIS IS SO OBVIOUS AND THE LACK OF THEM IS UNBELIEVABLY FRUSTRATING. Well, we had virtual, it was reverted I know, I'm repeating this kind of things in a trollish way since 2004, but... *sigh* /Paolo
Re: Blog post: What D got wrong
On Thursday, 13 December 2018 at 18:29:39 UTC, Adam D. Ruppe wrote: Though, I think we could also get a lot of mileage out of fixing two glaring problems with the status quo: 1) making attr: at the top descend into aggregates consistently and 2) LETTING US TURN THEM OFF. SERIOUSLY WHY DON'T WE HAVE `virtual`, `throws`, `impure` AND THE REST?! THIS IS SO OBVIOUS AND THE LACK OF THEM IS UNBELIEVABLY FRUSTRATING. While I might quibble about nothrow being the default, I wouldn't care once attributes descend into aggregates. https://issues.dlang.org/show_bug.cgi?id=7616
Re: Blog post: What D got wrong
On Tuesday, 11 December 2018 at 10:45:39 UTC, Atila Neves wrote: I think there’s a general consensus that @safe, pure and immutable should be default. I recall there was a decent chunk of people around D2.007 who were pushing for const-by-default function parameters on the grounds of if we're going to have this controversial system, we may as well commit to it. Also in the topic of defaults, you could potentially add inout as a default for member functions. It's a lot more strict, but no more so than immutable by default.
Re: Blog post: What D got wrong
On Thursday, 13 December 2018 at 18:29:39 UTC, Adam D. Ruppe
wrote:
I wanna show you something:
/// Static convenience functions for common color names
nothrow pure @nogc @safe
static Color transparent() { return Color(0, 0, 0, 0); }
Enums could resolve this particular case.
My thought on this situation is to implement tuple expansion in
attributes just like in function parameters, and complete
DIP1012. Then we can write so:
---
alias noble = AliasSeq!(pure, nothrow, nogc, safe);
int queryStuff() const @noble
{
...
}
---
Re: Blog post: What D got wrong
On Thursday, 13 December 2018 at 10:29:10 UTC, RazvanN wrote:
Do you honestly think that they will ever take D into account
if @safe and immutable data will be the default?
D needs to stop chasing after what you think people think they
want and just start being good for us.
The majority of my code is written pretty permissively - I like
my pointers, my gotos, my GC, my exceptions. But I'm willing to
consider the change because I actually don't think it will be
that big of a hassle, and will be better overall. I wanna show
you something:
/// Static convenience functions for common color names
nothrow pure @nogc @safe
static Color transparent() { return Color(0, 0, 0, 0); }
The attribute spam is almost longer than the function itself. And
I don't even personally care - I only put those in because some
library user who did care filed a bug report, and that was before
I would answer those with "WON'T FIX. D's attributes are a
misdesigned waste of time. You shouldn't bother with them either"
If the defaults were swapped though, that would just work. Both
for me and for my library users. And that is worth looking at.
Though, I think we could also get a lot of mileage out of fixing
two glaring problems with the status quo: 1) making attr: at the
top descend into aggregates consistently and 2) LETTING US TURN
THEM OFF. SERIOUSLY WHY DON'T WE HAVE `virtual`, `throws`,
`impure` AND THE REST?! THIS IS SO OBVIOUS AND THE LACK OF THEM
IS UNBELIEVABLY FRUSTRATING.
Re: Blog post: What D got wrong
On Thursday, 13 December 2018 at 17:07:58 UTC, H. S. Teoh wrote: [snip] Why not? You can opt out. It's not as though you're forced to use immutable everything and nothing but, like in a pure functional language. Just tack on @system or mutable when you need to. Mutable might be a little easier since it applies only to variables and member functions. If @safe is the default, including for main, then any @system block in your program and you also have to make main @trusted or @system too.
Re: Blog post: What D got wrong
On Thu, Dec 13, 2018 at 10:29:10AM +, RazvanN via Digitalmars-d-announce wrote: [...] > D and Rust are competing to get the C/C++/Java/Python market share. In > order to do that they should make it simple for developers to convert > to the new language. Due to its design, Rust is insanely hard to > master, which on the long run I think will kill the language despite > of the advantages it offers. On the other side, consider die hard C > fans: they are willing to accept the possibility of a buffer overflow > simply because they want more power. Do you honestly think that they > will ever take D into account if @safe and immutable data will be the > default? Why not? You can opt out. It's not as though you're forced to use immutable everything and nothing but, like in a pure functional language. Just tack on @system or mutable when you need to. Some people balk at the idea of `mutable` being sprinkled everywhere in their code, but that's really just a minor syntactic issue. There's already precedent for using `val` and `var` -- it couldn't get easier to type than that. The syntax is not a real problem. [...] > > It would be if the change weren't accompanied by adding `impure` and > > some sort of mutable auto. @system already exists. It's a question > > of opting out (like with variable initialisation) instead of opting > > in. > > It still is, because the user is imposed to work in certain conditions > that some might not want to. No, there's always the option of opting out. There's no imposition. It's not like Java where everything must be a class, no matter what. You can write @system code or mutable variables to your heart's content. The idea is to *default* to @safe so that when the programmer doesn't really care either way, the default behaviour gives you memory safety. Or default to immutable, so that unless the programmer consciously wants to mutate state, he'll get the benefit of being warned about any unintended mutation. Plus optimization benefits for variables that don't need to be mutable. But defaults are called defaults because they're there to be overridden. T -- LINUX = Lousy Interface for Nefarious Unix Xenophobes.
Re: Blog post: What D got wrong
On Thursday, 13 December 2018 at 10:14:45 UTC, Atila Neves wrote: On Thursday, 13 December 2018 at 09:40:45 UTC, RazvanN wrote: On Tuesday, 11 December 2018 at 10:45:39 UTC, Atila Neves wrote: A few things that have annoyed me about writing D lately: https://atilanevesoncode.wordpress.com/2018/12/11/what-d-got-wrong/ That was a really good blog post, however I am strongly against the following sentence: "I think there’s a general consensus that @safe, pure and immutable should be default." It's not at all a general consensus and doing this would literally break all the existing D code. Without discussing all the technical aspects, this will severely impact the adoption rate of D because it will make it very complicated for people coming from a C/C++/Java background to accommodate with the language. In addition, this is completely against D's liberal philosophy where you can program however you want. My impression is that it's a consensus that it _should_, but it's not going to happen due to breaking existing code. this will severely impact the adoption rate of D because it will make it very complicated for people coming from a C/C++/Java background to accommodate with the language How? Rust has immutable and safe by default and it's doing fine. D and Rust are competing to get the C/C++/Java/Python market share. In order to do that they should make it simple for developers to convert to the new language. Due to its design, Rust is insanely hard to master, which on the long run I think will kill the language despite of the advantages it offers. On the other side, consider die hard C fans: they are willing to accept the possibility of a buffer overflow simply because they want more power. Do you honestly think that they will ever take D into account if @safe and immutable data will be the default? this is completely against D's liberal philosophy where you can program however you want. It would be if the change weren't accompanied by adding `impure` and some sort of mutable auto. @system already exists. It's a question of opting out (like with variable initialisation) instead of opting in. It still is, because the user is imposed to work in certain conditions that some might not want to.
Re: Blog post: What D got wrong
On Thursday, 13 December 2018 at 09:40:45 UTC, RazvanN wrote: On Tuesday, 11 December 2018 at 10:45:39 UTC, Atila Neves wrote: A few things that have annoyed me about writing D lately: https://atilanevesoncode.wordpress.com/2018/12/11/what-d-got-wrong/ That was a really good blog post, however I am strongly against the following sentence: "I think there’s a general consensus that @safe, pure and immutable should be default." It's not at all a general consensus and doing this would literally break all the existing D code. Without discussing all the technical aspects, this will severely impact the adoption rate of D because it will make it very complicated for people coming from a C/C++/Java background to accommodate with the language. In addition, this is completely against D's liberal philosophy where you can program however you want. My impression is that it's a consensus that it _should_, but it's not going to happen due to breaking existing code. this will severely impact the adoption rate of D because it will make it very complicated for people coming from a C/C++/Java background to accommodate with the language How? Rust has immutable and safe by default and it's doing fine. this is completely against D's liberal philosophy where you can program however you want. It would be if the change weren't accompanied by adding `impure` and some sort of mutable auto. @system already exists. It's a question of opting out (like with variable initialisation) instead of opting in.
Re: Blog post: What D got wrong
On Thursday, 13 December 2018 at 09:40:45 UTC, RazvanN wrote: "I think there’s a general consensus that @safe, pure and immutable should be default." It's not at all a general consensus and doing this would literally break all the existing D code. Without discussing all the technical aspects, this will severely impact the adoption rate of D because it will make it very complicated for people coming from a C/C++/Java background to accommodate with the language. In addition, this is completely against D's liberal philosophy where you can program however you want. +1 The point of them not being default is that you can ignore them if you want, and create added-value instead of proving properties in your programs. So a D program can start its life being crap and get better _if_ it creates any value.
Re: Blog post: What D got wrong
On Tuesday, 11 December 2018 at 10:45:39 UTC, Atila Neves wrote: A few things that have annoyed me about writing D lately: https://atilanevesoncode.wordpress.com/2018/12/11/what-d-got-wrong/ That was a really good blog post, however I am strongly against the following sentence: "I think there’s a general consensus that @safe, pure and immutable should be default." It's not at all a general consensus and doing this would literally break all the existing D code. Without discussing all the technical aspects, this will severely impact the adoption rate of D because it will make it very complicated for people coming from a C/C++/Java background to accommodate with the language. In addition, this is completely against D's liberal philosophy where you can program however you want.
Re: Blog post: What D got wrong
On Wednesday, December 12, 2018 3:49:51 PM MST H. S. Teoh via Digitalmars-d- announce wrote: > If the delegate property thing is the only real use case for @property, > it seems quite out-of-proportion that an entire @-identifier in the > language is dedicated just for this purpose. One would've thought D > ought to be better designed than this... Originally, the idea was to restrict property syntax to functions marked with @property, which would mean no more lax parens. If it's a property function, then it must be called like one, and if it's not, then it must be called as a function (i.e. with parens), whereas right now, we have this mess where folks can use parens or not however they feel like. That doesn't work well with being able to swap between property functions and public variables, and it makes generic code harder, because in general, you can't rely on whether something is called with parens or not, meaning that the symbol in question has to be an actual function (where parens are optional) instead of being allowed to be a different kind of callable (which requires parens) or be a variable (which can't have parens). @property would have fixed all of that by forcing functions to either be called with or without parens based on what they're used for, allowing generic code to rely on more than convention ensuring that symbols are called consistently with or without parens (and thus allow symbols other than functions to be reliably used in place of functions where appropriate). So, as originally envisioned, @property was anything but useless. However, all of that became extremely unpopular once UFCS became a thing, because most folks didn't like having an empty set of parens when calling a templated function that had a template argument that used parens, and as such, they wanted to be able to continue to drop the parens, which goes against the core idea behind @property. So, the end result is that the original plans for @property got dropped, and plenty of folks would be very unhappy if we went in that direction now - but it's still the case that @property was supposed to solve a very real problem, and that problem remains unsolved. As things stand, you have to be _very_ careful when using anything other than a function in a generic context that normally uses a function, because there's no guarantee that using something other than a function will work due to the lack of guarantee of whether parens will be used or not. It tends to work better with variables than with callables, because dropping parens is so popular, and callables aren't, but it's still a problem. Anyone who wants to use a callable instead of a function in generic code is almost certainly in for a world of hurt unless they're in control of all of the code involved - and that's without even getting into the issue of property functions that return callables (those simply don't work at all). Template constraints combat this to an extent in that they end up requiring that the construct in question either be callable with parens or usable without them, but that places no restrictions on the code that actually uses the symbols, making it easy for code to use parens when it shouldn't or not use parens when it should and then run into problems when it's given a type that conforms to the template constraint, but the code didn't use the symbol in the same way as the constraint. The only thing things that really prevent this from be a much bigger problem than it is is that many folks do follow the conventions set forth by the template constraint (e.g. always calling front without parens) and the fact that in most cases, it's the lack of parens which is required, and using variables instead of functions is far more popular than using callables instead of functions. So, convention is really all that prevents this from being a bigger problem, and the end result is that callables in generic code are borderline useless. On example of trying to work around this problem is that not all that long ago, isInputRange was actually changed to use popFront without parens just so that folks could rely on being able to call it without parens, since previously it was possible to use a delegate or other callable for popFront instead of a function, which would then not have worked with any code where folks didn't bother to put parens on popFront when calling it. All in all though, I think that the fact that we aren't strict about parens usage mostly kills the use of callables in generic code except in cases where you're in control of all of the code involved. It could be argued that callables are desirable infrequently enough that being able to drop parens when calling functions for whatever syntactic beauty supposedly comes with outweighs the loss, but that doesn't mean that the problem isn't there, just that many folks don't care and think that the tradeoff is worth it. - Jonathan M Davis
Re: Blog post: What D got wrong
On Wed, Dec 12, 2018 at 02:10:31PM -0700, Jonathan M Davis via Digitalmars-d-announce wrote: > On Wednesday, December 12, 2018 6:03:39 AM MST Kagamin via Digitalmars-d- > announce wrote: [...] > > Imagine you have void delegate() prop() and use the property > > without parentheses everywhere then suddenly m.prop() doesn't > > call the delegate. So it's mostly for getters and should be used > > only in edge cases, most code should be fine with optional parens. > > Except that @property does not currently have any effect on this. The > delegate case (or really, the case of callables in general) is one > argument for keeping @property for using in that particular corner > case, since without it, having property functions that return > callables simply doesn't work, but @property has never been made to > actually handle that case, so having property functions that return > callables has never worked in D. It's certainly been discussed before, > but the implementation has never been changed to make it work. Yep. Basically, @property as currently implemented is useless, and I've stopped bothering with it except where Phobos requires it. > If/when we finally rework @property, that use case would be the number > one reason to not simply get rid of @property, but until then, it > doesn't actually fix that use case. As things stand, @property > basically just serves as documentation of intent for the API and as a > way to screw up type introspection by having the compiler lie about > the type of the property. [...] Haha yeah, currently @property confers no real benefits and only comes with bad (and probably unexpected) side-effects. More confirmation that it's a waste of time and not worth my attention. If the delegate property thing is the only real use case for @property, it seems quite out-of-proportion that an entire @-identifier in the language is dedicated just for this purpose. One would've thought D ought to be better designed than this... T -- Gone Chopin. Bach in a minuet.
Re: Blog post: What D got wrong
On Wednesday, December 12, 2018 6:03:39 AM MST Kagamin via Digitalmars-d- announce wrote: > On Tuesday, 11 December 2018 at 12:57:03 UTC, Atila Neves wrote: > > @property is useful for setters. Now, IMHO setters are a code > > stink anyway but sometimes they're the way to go. I have no > > idea what it's supposed to do for getters (nor am I interested > > in learning or retaining that information) and never slap the > > attribute on. > > Imagine you have void delegate() prop() and use the property > without parentheses everywhere then suddenly m.prop() doesn't > call the delegate. So it's mostly for getters and should be used > only in edge cases, most code should be fine with optional parens. Except that @property does not currently have any effect on this. The delegate case (or really, the case of callables in general) is one argument for keeping @property for using in that particular corner case, since without it, having property functions that return callables simply doesn't work, but @property has never been made to actually handle that case, so having property functions that return callables has never worked in D. It's certainly been discussed before, but the implementation has never been changed to make it work. If/when we finally rework @property, that use case would be the number one reason to not simply get rid of @property, but until then, it doesn't actually fix that use case. As things stand, @property basically just serves as documentation of intent for the API and as a way to screw up type introspection by having the compiler lie about the type of the property. > >I think there’s a general consensus that @safe, pure and > >immutable should be default. > > I can agree there are at least 5 people holding that firm belief, > but that's hardly a consensus. There are definitely people who want one or more of those attributes as the default, but I very much doubt that it's a consensus. It wouldn't surprise me if @safe or pure by default went over fairly well, but I'm sure that immutable or const by default would be far more controversial, because that's a big shift from what C-derived languages normally do. Personally, I would be very unhappy if it were the default, though I know that there are some folks who would very much like to see const or immutable be the default. > >I’ve lost count now of how many times I’ve had to write @safe > >@nogc pure nothrow const scope return. Really. > > If immutable was default, wouldn't you still need to write const > attribute everywhere, and @nogc, and nothrow? Strings are like > the only relevant immutable data structure (and they are already > immutable), everything else is inherently mutable except for use > cases with genuine need for immutability like a shared cache of > objects. If immutable were the default, then I expect that writing types that worked with immutable would become more common, because it would then be encouraged by the language, but I think that your average type is written to work as mutable (and maybe const), and it's a pretty big shift to write types to be immutable unless you're talking about simple POD types, so if immutable became the default, I expect that mutable (or whatever the modifier to make a type mutable would be) would start getting plastered everywhere. And without the range API being changed, ranges wouldn't work unless you marked them as mutable, making const or immutable by default a bit of a mess for what would now be idiomatic D code (though if the default were changed to const or immutable, we'd probably see the range API be changed to use the classic, functional head/tail list mechanism rather than front and popFront, which could very well be an improvement anyway). - Jonathan M Davis
Re: Blog post: What D got wrong
On Wednesday, 12 December 2018 at 20:12:54 UTC, Guillaume Piolat wrote: On Wednesday, 12 December 2018 at 14:48:23 UTC, Atila Neves wrote: On Tuesday, 11 December 2018 at 14:00:10 UTC, dayllenger wrote: On Tuesday, 11 December 2018 at 13:42:03 UTC, Guillaume Piolat wrote: One could say getters and particularly setters don't really deserve a nicer way to write them. It's a code stink, it deserve a long ugly name. (10 years ago I would be in the other camp) Can you please explain it in more detail? I never read such about getters and setters. Tell, don't ask: https://martinfowler.com/bliki/TellDontAsk.html Sometimes formulated slightly differently as "Law of Demeter" https://en.wikipedia.org/wiki/Law_of_Demeter if you like more pompous names. Law of Demeter is different. Law of Demeter basically translates to "don't have more than one dot", like x.y() is fine, x.y.z() isn't because it makes too many assumptions about internals of x and y. Properties have use when the setting or getting the variable isn't a trivial assignment. For example, sometimes the units need to be converted along the way. In many cases, especially when GUI programming, you might want to do additional actions when settings/getting a variable, like calling listeners to notify them of the value change so that they can change the value in the GUI widget automatically.
Re: Blog post: What D got wrong
On Wednesday, 12 December 2018 at 14:48:23 UTC, Atila Neves wrote: On Tuesday, 11 December 2018 at 14:00:10 UTC, dayllenger wrote: On Tuesday, 11 December 2018 at 13:42:03 UTC, Guillaume Piolat wrote: One could say getters and particularly setters don't really deserve a nicer way to write them. It's a code stink, it deserve a long ugly name. (10 years ago I would be in the other camp) Can you please explain it in more detail? I never read such about getters and setters. Tell, don't ask: https://martinfowler.com/bliki/TellDontAsk.html Sometimes formulated slightly differently as "Law of Demeter" https://en.wikipedia.org/wiki/Law_of_Demeter if you like more pompous names.
Re: Blog post: What D got wrong
On Tuesday, 11 December 2018 at 14:00:10 UTC, dayllenger wrote: On Tuesday, 11 December 2018 at 13:42:03 UTC, Guillaume Piolat wrote: One could say getters and particularly setters don't really deserve a nicer way to write them. It's a code stink, it deserve a long ugly name. (10 years ago I would be in the other camp) Can you please explain it in more detail? I never read such about getters and setters. Tell, don't ask: https://martinfowler.com/bliki/TellDontAsk.html Getters and setters break encapsulation - the client knows way too much about your struct/class. Whatever you were going to do with the data you got from the object, move it into a member function of that object's type. Setters are like that as well, but worse since mutable state is the root of all evil. Personally, I cringe whenever I have to use `auto` instead of `const` for a variable declaration.
Re: Blog post: What D got wrong
On Tuesday, 11 December 2018 at 12:57:03 UTC, Atila Neves wrote: @property is useful for setters. Now, IMHO setters are a code stink anyway but sometimes they're the way to go. I have no idea what it's supposed to do for getters (nor am I interested in learning or retaining that information) and never slap the attribute on. Imagine you have void delegate() prop() and use the property without parentheses everywhere then suddenly m.prop() doesn't call the delegate. So it's mostly for getters and should be used only in edge cases, most code should be fine with optional parens. inout Template this can accomplish the same thing and is more useful anyway. "Everything is a template" is a spiritual successor to "everything is an object" hype :) Returning a reference It’s practically pointless. See https://github.com/dlang/druntime/blob/master/src/core/stdc/errno.d#L66 Also AFAIK alias this doesn't dereference pointers automatically, and retaining the pointer may be not desirable. I think there’s a general consensus that @safe, pure and immutable should be default. I can agree there are at least 5 people holding that firm belief, but that's hardly a consensus. I’ve lost count now of how many times I’ve had to write @safe @nogc pure nothrow const scope return. Really. If immutable was default, wouldn't you still need to write const attribute everywhere, and @nogc, and nothrow? Strings are like the only relevant immutable data structure (and they are already immutable), everything else is inherently mutable except for use cases with genuine need for immutability like a shared cache of objects.
Re: Blog post: What D got wrong
On 12/11/2018 4:51 AM, Nicholas Wilson wrote: > Returning a reference Wow, thats f*ck'n stupid! https://run.dlang.io/is/SAplYw It's quite deliberate. ref in C++ is a type constructor, but it's so special-cased to behave like a storage class, it might as well be one. In D it is. (For example, ref in C++ can only appear at the top level. There are no "pointers to refs".) refs exist so the lifetime of them can be controlled for memory safety. Treating them as flexibly as pointers would make that pretty difficult. refs are the primary way a memory safe container can expose pointers to its contents.
Re: Blog post: What D got wrong
On Tuesday, 11 December 2018 at 10:45:39 UTC, Atila Neves wrote:
A few things that have annoyed me about writing D lately:
https://atilanevesoncode.wordpress.com/2018/12/11/what-d-got-wrong/
No UFCS chain for templates.
No template lambdas.
You can write code like this today via library that I wrote ;)
```
import std.conv : to;
auto filterMembers(alias pred, type)(type _)
{
import std.format : format;
alias MemberType(T, string name) = typeof(__traits(getMember,
T, name));
return l!(__traits(allMembers, type.get))
.staticMap!(name => π!(MemberType!(type.get, name.get),
name.get))
.staticFilter!pred
.staticMap!(t => "%s %s".format(t.get[0].stringof,
t.get[1]));
}
enum members = [ π!S.filterMembers!(t => is(t.get[0] : U[],
U)).get ];
pragma (msg, members.to!string); // Prints: ["string wxyz",
"int[4] uvwxyz"]
struct S
{
int x;
double xy;
int xyz;
string wxyz;
S* vwxyz;
int[4] uvwxyz;
}
```
Here's a full example: [2]
Though, I agree that this certainly not as elegant and
straightforward to use as what a language feature could provide.
[1]:
https://github.com/dlang/phobos/pull/5977/files#diff-33b50b4967214bfd07ca2ebb7bbc023cR1218
[2]:
https://run.dlang.io/gist/ZombineDev/a808c94857de84858accfb094c19bf77?compiler=dmd=-unittest%20-main
Re: Blog post: What D got wrong
On Tuesday, 11 December 2018 at 14:38:25 UTC, Steven Schveighoffer wrote: @property: This was almost about to be awesome, but squabbling amongst the D core team killed it. Yes, the problem with @property is that it is neither correctly implemented nor completely implemented. And to do the former something will have to break. Note that you can't use binary assignment operators on parentheses-less function calls, and returning by ref is not a solution either. Not only does that break encapsulation, but some @property functions may not return an addressable lvalue (e.g. when working with bitfields). One might be able to fix the @property implementation, but now, there's so much disdain for the incorrect, incomplete @property implementation it's going to take some serious sweetener to remove the bitter taste from some people's mouths. Mike
Re: Blog post: What D got wrong
On Tuesday, 11 December 2018 at 20:44:28 UTC, Dukc wrote: On Tuesday, 11 December 2018 at 15:34:28 UTC, Simen Kjærås wrote: I believe a reasonable case can be made for .! for UFCS - it's currently invalid syntax and will not compile, and ! is the symbol we already associate with template instantiation: alias memberFunctions = __traits(allMembers, T) .!staticMap!Member .!Filter!(isSomeFunction); -- Simen Perhaps. I also think that it might be good if types could be results of compile-ime expressions, including ufcs expressions (so that 42.typeof would become legal, meaning an int). I vaguely remember a very ancient version of D that had .typeof instead of typeof(). This might've been D1... the details are fuzzy.
Re: Blog post: What D got wrong
On Tuesday, 11 December 2018 at 10:45:39 UTC, Atila Neves wrote: A few things that have annoyed me about writing D lately: https://atilanevesoncode.wordpress.com/2018/12/11/what-d-got-wrong/ Template lambdas and better eponymous template syntax are the two big ones that I would really like. It's very painful not having them in code that makes heavy use of metaprogramming.
Re: Blog post: What D got wrong
On Tuesday, 11 December 2018 at 15:34:28 UTC, Simen Kjærås wrote: I believe a reasonable case can be made for .! for UFCS - it's currently invalid syntax and will not compile, and ! is the symbol we already associate with template instantiation: alias memberFunctions = __traits(allMembers, T) .!staticMap!Member .!Filter!(isSomeFunction); -- Simen Perhaps. I also think that it might be good if types could be results of compile-ime expressions, including ufcs expressions (so that 42.typeof would become legal, meaning an int).
Re: Blog post: What D got wrong
On Tue, Dec 11, 2018 at 03:34:28PM +, Simen Kjærås via Digitalmars-d-announce wrote: [...] > I believe a reasonable case can be made for .! for UFCS - it's > currently invalid syntax and will not compile, and ! is the symbol we > already associate with template instantiation: > > alias memberFunctions = __traits(allMembers, T) > .!staticMap!Member > .!Filter!(isSomeFunction); [...] +1. T -- Too many people have open minds but closed eyes.
Re: Blog post: What D got wrong
On Tue, Dec 11, 2018 at 03:03:19PM +0100, Daniel Kozak via Digitalmars-d-announce wrote: >On Tue, Dec 11, 2018 at 11:50 AM Atila Neves via Digitalmars-d-announce ><[1]digitalmars-d-announce@puremagic.com> wrote: > > A few things that have annoyed me about writing D lately: > > [2]https://atilanevesoncode.wordpress.com/2018/12/11/what-d-got-wrong/ > >Eponymous templates - workaround >[3]https://run.dlang.io/is/qIvcVH [...] Clever! Perhaps this should be proposed as the lowering in a DIP for eponymous templates improvement. T -- Тише едешь, дальше будешь.
Re: Blog post: What D got wrong
On Tue, Dec 11, 2018 at 12:57:03PM +, Atila Neves via
Digitalmars-d-announce wrote:
> On Tuesday, 11 December 2018 at 12:52:20 UTC, Adam D. Ruppe wrote:
> > On Tuesday, 11 December 2018 at 10:45:39 UTC, Atila Neves wrote:
> > > A few things that have annoyed me about writing D lately:
> > >
> > > https://atilanevesoncode.wordpress.com/2018/12/11/what-d-got-wrong/
> >
> > If @property worked for a thing to return a delegate, it would be
> > useful.
> >
> > But n, we got worked up over syntax and forgot about semantics
> > :(
>
> @property is useful for setters. Now, IMHO setters are a code stink
> anyway but sometimes they're the way to go. I have no idea what it's
> supposed to do for getters (nor am I interested in learning or
> retaining that information) and never slap the attribute on.
You don't need @property for setters. This works:
struct S {
void func(int x);
}
S s;
s.func = 1;
Of course, it's generally not a good idea to call it `func` when the
intent is to emulate a member variable. :-D
I agree setters are a code stink, but only when they are trivial:
struct S {
private int _x;
// This is a code smell: just make _x public, dammit!
void x(int val) { _x = val; }
}
But they can be very useful for non-trivial use cases. Recently I wrote
code that auto-generates a nice D API for setting GLSL inputs. So
instead of writing:
FVec position;
glUniform3fv(myshader.u_dirLightId_pos, 1, position[].ptr);
I write:
FVec position;
myshader.position = position; // much more readable and less error
prone!
with myshader.position defined as a setter function that does that ugly
glUniform3fv call for me. Plus, I can hide away that ugly internal
detail of attribute position IDs and make it private, instead of
exposing it to the world and adding a needless GL dependency to client
code. (E.g., now I have the possibility of substituing a Direct3D
backend for the OpenGL just by emitting a different implementation for
myshader.position. The calling code doesn't need to be touched.)
T
--
If you think you are too small to make a difference, try sleeping in a closed
room with a mosquito. -- Jan van Steenbergen
Re: Blog post: What D got wrong
On Tue, Dec 11, 2018 at 10:45:39AM +, Atila Neves via
Digitalmars-d-announce wrote:
> A few things that have annoyed me about writing D lately:
>
> https://atilanevesoncode.wordpress.com/2018/12/11/what-d-got-wrong/
About UFCS chains for templates: totally agree! I found myself wishing
for exactly that, many times. I'd even venture to say we should cook up
a DIP for it. To prevent confusion and potential ambiguity with
non-template UFCS chains, I propose using a separate operator, perhaps
`.!`:
alias blah = AliasSeq!(...)
.!firstTemplate!(...)
.!secondTemplate!(...)
...;
Template lambdas have also been an annoyance for me. But again, there's
a need to distinguish between a template lambda and a non-template
lambda.
And yes, I've also run into the eponymous template renaming problem. But
I think it will be a pretty small and safe change to use `this` instead
of repeating the template name? And while we're at it, might as well
use `this` for recursive templates too. So we'd have something like:
template Eponymous(T...) {
static if (T.length == 0)
enum this = 1;
else
enum this = 1 + 2*this!(T[1 .. $]);
}
Now we can freely rename Eponymous without also having to rename the
occurrences of `this`, which in current syntax would also have to be
spelt out as `Eponymous`.
Though we probably have to write it as `This` instead, in order to
prevent ambiguity when working with class templates.
@property getters... I've pretty much given up on @property by this
point, except for the few places (primarily isInputRange and its ilk)
where @property is explicitly tested for. Optional parens and the
equivalence of `func(1)` vs. `func = 1` have made the distinction
between @property and non-@property more-or-less irrelevant except for
language lawyers and corner cases that nobody uses. Dmd's -property flag
is a flop that nobody uses anymore. There have been a few efforts in
the past for reviving @property, but nothing has come of it, and in the
recent years nobody has even bothered to talk about it anymore. So,
tl;dr: @property is moribund, if not completely dead. As far as I'm
concerned, it belongs only in the history books of D now.
inout... it's still useful for reducing template bloat in certain cases.
But yeah, it has some not-very-pretty corner cases that I don't really
want to talk about right now. But for the most part, the niche cases
for which it's intended still work pretty well. It can be a life-saver
when you try to be (slightly) const-correct in your code. Of course,
const is a giant bear to work with -- it's an all-or-nothing deal that
can require refactoring your *entire* codebase -- and generally I don't
bother with it except for leaf modules that don't affect too much else.
Trying to be const-correct in your core application logic can quickly
turn into a nightmare -- and inout is also implicated in such cases.
And yeah, ref as a storage class rather than part of the type is a
strange concept that seems incongruous with much of the rest of the
language. Its asymmetry with type qualifiers makes it hard to reason
about (you have to shift mental gears when parsing it, which hampers
easy understanding of code). I generally avoid it except in quick-hack
cases, e.g., to make opIndex work with assignment without actually
writing a separate opIndexAssign, or to grant by-reference semantics to
struct parameters (but in the latter case I've often found it better to
just change the struct to a class instead). So it's a *necessary* part
of the language, but it feels a lot like a square peg jammed in a round
hole sometimes. If I were to redesign ref, I'd do it a lot differently.
As for attribute soup... I've mostly given up on writing attributes. I
just stick () in front of every function parameter list to turn them
into templates, and let the compiler do auto-inference for me. The only
time I'd spell out attributes is in unittests, or in the rare case where
I want to ensure a certain attribute is in effect. But seriously, in
the grand scheme of things, attributes are an added annoyance that
nobody wants to deal with (and do so only grudgingly when it cannot be
helped). Attributes need to be auto-inferred everywhere. Nothing else
is scalable. Of course, I realize that it's a bit too late to have auto
inference in non-template functions, but I fully applaud Walter's move
to apply inference to auto functions. The wider the scope of auto
inference, the less attribute soup needs to be visible in your code, and
the better it will be. In an ideal world, attributes would be completely
invisible, and completely inferred and propagated by the compiler via
static analysis. (Yes I know this doesn't work with separate
compilation. But in theory, it *should*. The compiler should just store
attributes in a special section in the object file and load
Re: Blog post: What D got wrong
On 11-12-2018 12:10, Atila Neves wrote: On Tuesday, 11 December 2018 at 11:08:29 UTC, user1234 wrote: On Tuesday, 11 December 2018 at 10:45:39 UTC, Atila Neves wrote: A few things that have annoyed me about writing D lately: https://atilanevesoncode.wordpress.com/2018/12/11/what-d-got-wrong/ I agree about template lambdas. But is something that misses really an error ? It's debatable. I thought it was funny that it was an oversight given the fact that D had lambdas to avoid the problems that C++ used to have, then went and made the "same" mistake again. It isn't as bad as the example in the blog post, this also works: ``` range.map!(fun).filter!(gun).join; ``` -- Mike Wey
Re: Blog post: What D got wrong
On Tuesday, 11 December 2018 at 14:38:25 UTC, Steven Schveighoffer wrote: On 12/11/18 5:45 AM, Atila Neves wrote: A few things that have annoyed me about writing D lately: https://atilanevesoncode.wordpress.com/2018/12/11/what-d-got-wrong/ Agree with most of this. UFCS for templates would be awesome, but the syntax is trickier, since instantiation uses ! instead of . I can't see how you get around the ambiguities, especially when a template could be a UFCS function. I believe a reasonable case can be made for .! for UFCS - it's currently invalid syntax and will not compile, and ! is the symbol we already associate with template instantiation: alias memberFunctions = __traits(allMembers, T) .!staticMap!Member .!Filter!(isSomeFunction); -- Simen
Re: Blog post: What D got wrong
On 12/11/18 5:45 AM, Atila Neves wrote:
A few things that have annoyed me about writing D lately:
https://atilanevesoncode.wordpress.com/2018/12/11/what-d-got-wrong/
Agree with most of this. UFCS for templates would be awesome, but the
syntax is trickier, since instantiation uses ! instead of .
I can't see how you get around the ambiguities, especially when a
template could be a UFCS function.
inout: template This doesn't work the same (no guarantee it doesn't
mutate the data). And it still generates multiple copies of the same
function. As I said in my dconf 2016 presentation and in numerous
debates on this forums, the only reason to care about const or inout is
if you care about mutability guarantees on the callee. We can make do
with templates and immutable without either of those features.
@property: This was almost about to be awesome, but squabbling amongst
the D core team killed it. Now, it's only a very obscure difference:
struct S
{
int _x;
int x1() { return _x; }
@property int x2() { return _x; }
}
pragma(msg, typeof(S.x1)); // int()
pragma(msg, typeof(S.x2)); // int
Which is COMPLETELY USELESS, since you have to handle both cases anyway.
-Steve
Re: Blog post: What D got wrong
On Tue, Dec 11, 2018 at 11:50 AM Atila Neves via Digitalmars-d-announce < digitalmars-d-announce@puremagic.com> wrote: > A few things that have annoyed me about writing D lately: > > https://atilanevesoncode.wordpress.com/2018/12/11/what-d-got-wrong/ Eponymous templates - workaround https://run.dlang.io/is/qIvcVH
Re: Blog post: What D got wrong
On Tuesday, 11 December 2018 at 12:57:03 UTC, Atila Neves wrote: On Tuesday, 11 December 2018 at 12:52:20 UTC, Adam D. Ruppe wrote: On Tuesday, 11 December 2018 at 10:45:39 UTC, Atila Neves wrote: A few things that have annoyed me about writing D lately: https://atilanevesoncode.wordpress.com/2018/12/11/what-d-got-wrong/ If @property worked for a thing to return a delegate, it would be useful. But n, we got worked up over syntax and forgot about semantics :( @property is useful for setters. Now, IMHO setters are a code stink anyway but sometimes they're the way to go. I have no idea what it's supposed to do for getters (nor am I interested in learning or retaining that information) and never slap the attribute on. My view of getters is that they serve as a contract of between contractor and client stating "You can't modify this value, I however can".
Re: Blog post: What D got wrong
On Tuesday, 11 December 2018 at 13:42:03 UTC, Guillaume Piolat wrote: One could say getters and particularly setters don't really deserve a nicer way to write them. It's a code stink, it deserve a long ugly name. (10 years ago I would be in the other camp) Can you please explain it in more detail? I never read such about getters and setters.
Re: Blog post: What D got wrong
On Tuesday, 11 December 2018 at 10:45:39 UTC, Atila Neves wrote: A few things that have annoyed me about writing D lately: https://atilanevesoncode.wordpress.com/2018/12/11/what-d-got-wrong/ One thing that could be improved in this post is separating things that can't reasonably be either fixed or added as enhancements vs. things that would be big breaking changes. I would think UFCS chain for templates, template lambdas, and eponymous template changes are all things that could be added or changed without breaking any code, whereas @safe by default would break a bunch of code. I'm not sold on immutable by default yet, but I think all the attributes should be able to be used with the block and colon syntax.
Re: Blog post: What D got wrong
On Tuesday, 11 December 2018 at 13:08:18 UTC, 0xEAB wrote:
Well, one can use it for optics :)
@property
{
int x()
{
return this._x;
}
void x(int value)
{
this._x = value;
}
}
One could say getters and particularly setters don't really
deserve a nicer way to write them. It's a code stink, it deserve
a long ugly name. (10 years ago I would be in the other camp)
Re: Blog post: What D got wrong
On Tuesday, 11 December 2018 at 12:57:03 UTC, Atila Neves wrote:
On Tuesday, 11 December 2018 at 12:52:20 UTC, Adam D. Ruppe
wrote:
On Tuesday, 11 December 2018 at 10:45:39 UTC, Atila Neves
wrote:
A few things that have annoyed me about writing D lately:
https://atilanevesoncode.wordpress.com/2018/12/11/what-d-got-wrong/
If @property worked for a thing to return a delegate, it would
be useful.
But n, we got worked up over syntax and forgot about
semantics :(
@property is useful for setters. Now, IMHO setters are a code
stink anyway but sometimes they're the way to go. I have no
idea what it's supposed to do for getters (nor am I interested
in learning or retaining that information) and never slap the
attribute on.
Well, one can use it for optics :)
@property
{
int x()
{
return this._x;
}
void x(int value)
{
this._x = value;
}
}
Re: Blog post: What D got wrong
On Tuesday, 11 December 2018 at 12:51:56 UTC, Nicholas Wilson wrote: On Tuesday, 11 December 2018 at 10:45:39 UTC, Atila Neves wrote: A few things that have annoyed me about writing D lately: https://atilanevesoncode.wordpress.com/2018/12/11/what-d-got-wrong/ Nice! Thanks! I like the eponymous templates idea, though it might get confusing with doubly nested eponymous templates I'd say it would refer to the innermost template. and with mixin templates injecting constructors ( https://run.dlang.io/is/UYakit ) I'd say it wouldn't work in mixin templates - is there such a thing as an eponymous mixin template now? We really do need to figure out what to do with @property Returning a reference Wow, thats f*ck'n stupid! https://run.dlang.io/is/SAplYw You're telling me - how do you think I found out? ;) Variables can’t be ref not _quite true, foreach variables can be. That's true and a weird edge case.
Re: Blog post: What D got wrong
On Tuesday, 11 December 2018 at 12:52:20 UTC, Adam D. Ruppe wrote: On Tuesday, 11 December 2018 at 10:45:39 UTC, Atila Neves wrote: A few things that have annoyed me about writing D lately: https://atilanevesoncode.wordpress.com/2018/12/11/what-d-got-wrong/ If @property worked for a thing to return a delegate, it would be useful. But n, we got worked up over syntax and forgot about semantics :( @property is useful for setters. Now, IMHO setters are a code stink anyway but sometimes they're the way to go. I have no idea what it's supposed to do for getters (nor am I interested in learning or retaining that information) and never slap the attribute on.
Re: Blog post: What D got wrong
On Tuesday, 11 December 2018 at 10:45:39 UTC, Atila Neves wrote: A few things that have annoyed me about writing D lately: https://atilanevesoncode.wordpress.com/2018/12/11/what-d-got-wrong/ If @property worked for a thing to return a delegate, it would be useful. But n, we got worked up over syntax and forgot about semantics :(
Re: Blog post: What D got wrong
On Tuesday, 11 December 2018 at 10:45:39 UTC, Atila Neves wrote: A few things that have annoyed me about writing D lately: https://atilanevesoncode.wordpress.com/2018/12/11/what-d-got-wrong/ Nice! I like the eponymous templates idea, though it might get confusing with doubly nested eponymous templates and with mixin templates injecting constructors ( https://run.dlang.io/is/UYakit ) We really do need to figure out what to do with @property Returning a reference Wow, thats f*ck'n stupid! https://run.dlang.io/is/SAplYw Variables can’t be ref not _quite true, foreach variables can be.
Re: Blog post: What D got wrong
On Tuesday, 11 December 2018 at 10:45:39 UTC, Atila Neves wrote: A few things that have annoyed me about writing D lately: https://atilanevesoncode.wordpress.com/2018/12/11/what-d-got-wrong/ Really great article. I like the "UFCS for templates" idea. 12 years in and I still don't know what @property is for! . The way to do eponymous templates right is to (obviously renaming the feature) follow D’s own lead here and use either this or This to refer to itself. Brilliant.
Re: Blog post: What D got wrong
On Tuesday, 11 December 2018 at 11:08:29 UTC, user1234 wrote: On Tuesday, 11 December 2018 at 10:45:39 UTC, Atila Neves wrote: A few things that have annoyed me about writing D lately: https://atilanevesoncode.wordpress.com/2018/12/11/what-d-got-wrong/ I agree about template lambdas. But is something that misses really an error ? It's debatable. I thought it was funny that it was an oversight given the fact that D had lambdas to avoid the problems that C++ used to have, then went and made the "same" mistake again.
Re: Blog post: What D got wrong
On Tuesday, 11 December 2018 at 10:45:39 UTC, Atila Neves wrote: A few things that have annoyed me about writing D lately: https://atilanevesoncode.wordpress.com/2018/12/11/what-d-got-wrong/ I agree about template lambdas. But is something that misses really an error ?
Blog post: What D got wrong
A few things that have annoyed me about writing D lately: https://atilanevesoncode.wordpress.com/2018/12/11/what-d-got-wrong/
