221–230 of 360 posts
Earlier quoted context omitted.
What would be the return type of that? Does D have an Either type?
Depends on the value of the template parameter. If it's 0 the return type is an int, if it's not 0 the return type is a string. There's a wanting implementation of a sumtype in the standard library ( https://dlang.org/phobos/std_variant.html#.Algebraic ), and a much better one as a package: https://code.dlang.org/packages/sumtype
Earlier quoted context omitted.
Yeah I think "better C" is a space which has a really good reason to exist and I'm always interested to see new entrants. IMO describing Rust as a "C replacement" is slightly off the mark because Rust's value proposition is very different from C. Rust is about giving you the best possible performance in a safe-by-default language. C is about giving you maximal control over memory, with a very thin layer of abstractio…
D also now supports Ownership/Borrowing (experimental) on a per-function basis, meaning it can be added incrementally to an existing program.
One thing that really annoyed me about D is that its documentation lists basically every function with an 'auto' return type. Auto should be completely banned from documentation, it's a complete hindrance. It's the single biggest contributor to why I stopped using D for personal projects - I was so tired of having to hunt down what functions are going to return, sometimes having to resort to just using it and looking…
I've felt this as well, been using D for a couple years now, and this is the kind of thing that just makes me have to context switch more than I'd like. With the current implementation of the language it's hard to avoid, and function's return type can be quite complex, so writing it down can be hard. Another reason is the (ironically) dynamic nature of a return type. E.g. auto whatDoesItReturn(int i)() { static if (i…
If the docs are filled with this, then D is certainly coming off my list of langs to look at.
For functions that can return different types, I think interfaces or union types would be more helpful (not sure if D supports either though).
Earlier quoted context omitted.
+1, I cringed when Herb Sutter released the 'Almost Always Auto' C++ presentation on YouTube. Sure, auto has its place, and I personally use it, but I just knew that less experience devs would go nuts with it, and it'd only make their lives easier for a short time.
Plus, seeing the word 'auto' all over the place leaves a weird impression.
Whether that's really what you want and whether that is the best approach to solve the problem at hand is a matter of preference and the problem space.
It is also allows for a "gradual typing" approach that Dart 1 had.
Earlier quoted context omitted.
The use of Auto is requires in some places because the standard library returns types that cannot be named in the context of the calling function. This happens for example with algortihms that return a custom Range implementation that is declared within the scope of the function implementing the algorithm. I am not sure what to make of this pattern. At least the documentation should be more explicit about these Volde…
I'm glad that Rust has no `auto`. I find this: fn map (it: I) -> impl Iterator where I: Iterator , U: From { it.map(|t| From::from(t)) } infinitely more readable than fn map (it: I) -> auto where I: Iterator , U: From { it.map(|t| From::from(t)) } The type signature of the first one clearly tells me that the return type is an `Iterator `, even though the actual type cannot be named because of the anonymous closure. T…
Earlier quoted context omitted.
I've felt this as well, been using D for a couple years now, and this is the kind of thing that just makes me have to context switch more than I'd like. With the current implementation of the language it's hard to avoid, and function's return type can be quite complex, so writing it down can be hard. Another reason is the (ironically) dynamic nature of a return type. E.g. auto whatDoesItReturn(int i)() { static if (i…
I haven't looked at D yet, but... yuck ! `var` for return types in a method signature is seriously unhelpful! If the docs are filled with this, then D is certainly coming off my list of langs to look at. For functions that can return different types, I think interfaces or union types would be more helpful (not sure if D supports either though).
Earlier quoted context omitted.
I checked your link, each function has a “Returns:” section that describe what to expect. Isn’t that what you want from a documentation?
A type is much denser, than a textual description, and in most cases sufficient.
A more explicit "impl(InputRange) map()" may be better until you consider that map is generic on the kind of range you give it, so that just turns into "impl(MapResult!R) map(R)()". A more roundabout, pointless way of saying "auto".
D is pretty exciting. Seems like a perfect choice for those of us looking for an alternative systems programming language and are not completely convinced we'll be happy in Rust.
D is a much better option for those that believe that it isn't a crime to have a GC on a systems programming language. It basically follows on the school of thought at Xerox PARC, ETHZ, and Microsoft Research. Now what it lacks is more more manpower to improve its runtime capabilities and having a big name actually pushing it forward. However this doesn't need to be a zero sum game, any language that helps to fix C i…
Earlier quoted context omitted.
Depends on the value of the template parameter. If it's 0 the return type is an int, if it's not 0 the return type is a string. There's a wanting implementation of a sumtype in the standard library ( https://dlang.org/phobos/std_variant.html#.Algebraic ), and a much better one as a package: https://code.dlang.org/packages/sumtype
Interesting, so the return type isn't known until runtime.
The docs on static if may shed some more light: https://dlang.org/spec/version.html#staticif
Earlier quoted context omitted.
I use Pascal as better C
Pascal is not better, it's just more verbose.
- Units (modules) for separate compilation with strong type checking and not needing useless prefixes
- A proper string type
- Proper arrays with bounds checking, it has functions to retrieve upper and lower bounds
- Allows the definition of numeric ranges
- Enumerations are their own type, can be used as array indexes or data sets
- Support for sets
- Thanks to reference parameters there is less need to deal with pointers that might be invalid
- Already allows for a simplified way of doing Type Driven Development
- Supports type safe function pointers
- Supports single inheritance OOP with minimal RAII support for heap allocated objects
- Comes with a quite powerful OOP framework for TUI applications, Turbo Vision
- While it doesn't prevent use-after-free, it allows for memory regions that can be deallocated on one go
- Can map arrays to memory regions with bounds checking
- Besides inline assembly without UNIX's clusmy syntax, allows to use registers as variables
- If one really wants do do unsafe C style coding there are compiler pragmas to allow it and yes even pointer arithmetic and unsafe casts.
This in 1992, if I take a recent version of Delphi, FreePascal or Oxygene, there are even more bullet points.