Re: allMembers broke for __
On Sunday, 17 June 2018 at 02:25:59 UTC, Adam D. Ruppe wrote: On Sunday, 17 June 2018 at 01:02:17 UTC, DigitalDesigns wrote: If this was a sane language constraint then any identifiers starting with __ that were not reserved would at least give a warning but particularly give an error! Not fail silently and break code in ways that cannot be determined otherwise. It is undefined behavior to use ANY identifier with __ leading. C works exactly the same way. I'm sure there are naive C programmers who use "__" prefix for their own purposes. Maybe it would be cleaner to create more special syntax for "internal" functions/methods, e.g require some kind of UDA in addition to the "__" prefix: @Dinternal void __someMethod() ... Then disallow "__" prefix altogether (with the exception above). Now, if someone still uses both the UDA and the prefix, he really cannot say he didn't know.
Re: SOLID principals in D
On Saturday, 16 June 2018 at 19:20:30 UTC, FromAnotherPlanet wrote: - Interface segregation principal: Essentially breaking the program up into smaller interfaces. Sometimes only consistent of one or two methods/properties (can feed into 'S' of SOLID quite nicely). - Dependency inversion principle: Things should depend on abstractions not concretions. Strongly enables dependency injection. D seems to have all of the features *required* to make this happen, but I guess the real question is the last two, and more specifically the last one. Then D supports everything you need (and even better, just look at interface with contracts: https://dlang.org/spec/interface.html) Interface segregation example: https://run.dlang.io/gist/6aa1710dd5a8327f20e605b0ac3b978f Keep in mind that D doesn't support multiple inheritance, so if you want to follow DRY principle, you need to use interfaces + template mixins to make it happen (so in this point D is way better than the plain Java, because D's templates mixins are like traits). Dependency injection is also supported. However, D doesn't supply any DI containers in its standard library, so you have to rely on 3rd-party components, or implement it on your own. Look at this page: https://wiki.dlang.org/Dependency_Injection_Containers The most popular and actively maintained are "aedi" and "poodinis".
Re: @safe by default
On 6/16/18 4:27 PM, Jacob Shtokolov wrote: On Saturday, 16 June 2018 at 18:47:10 UTC, Steven Schveighoffer wrote: I would just caution that this does not affect member functions, only module-level functions. You have to repeat the @safe: inside any structs or classes as well. Just tried that and it works very well (throws compilation errors): https://gist.github.com/run-dlang/ba59bcca4464d875f95f975d13bebe88 It seems that it works even for member functions! But still not sure about anonymous functions and delegates. Hm... interesting! I guess for @safe it works, but other attributes (nothrow, pure), it doesn't. I assumed all the attributes behaved the same, but apparently not. -Steve
Re: @safe by default
On Saturday, 16 June 2018 at 13:52:37 UTC, Jacob Shtokolov wrote: Is it possible to introduce a new parameter/flag to the compiler, to force all functions be @safe by default on a per-module basis? Forgive me if you're already aware of this, but to ensure your entire program is `@safe` (assuming it's single threaded) you only need to attribute `main` with `@safe`. This is because `@safe` functions cannot call unsafe functions and will emit a compiler error if attempting to do so. You still may need to attribute called functions with `@safe` or `@trusted` as necessary, and as others have already explained, but your program will enforce `@safe`ty simply by attributing `main`. Mike
Re: SOLID principals in D
What's the differences in the approaches between SOLID and component programming? Are they orthogonal? Or can they be used together?
Re: An (old/new?) pattern to utilize phobos better with @nogc
On Saturday, 16 June 2018 at 11:58:47 UTC, Dukc wrote: snip] What are your thoughts? Do you agree with this coding pattern? I like it.
Re: An (old/new?) pattern to utilize phobos better with @nogc
On Saturday, 16 June 2018 at 11:58:47 UTC, Dukc wrote: What are your thoughts? Do you agree with this coding pattern? It would even be better if map can recognize tuples and thus allows to simply use a lambda functions with two parameters, but in the past with a few exceptions there hasn't been much support/consensus on specializing Phobos functions for tuples.
Re: SOLID principals in D
On Sunday, 17 June 2018 at 12:24:35 UTC, FromAnotherPlanet wrote: What's the differences in the approaches between SOLID and component programming? Are they orthogonal? Or can they be used together? It looks like they have some overlap, but are not the same. SOLID seems focused on OOP, whereas component programming isn't and has its own abstraction of ranges. I suggest you read the article and contrast them for yourself, as I'm not that familiar with SOLID.
Re: Replacing C's memcpy with a D implementation
On Monday, 11 June 2018 at 08:02:42 UTC, Walter Bright wrote: On 6/10/2018 9:44 PM, Patrick Schluter wrote: See what Agner Fog has to say about it: Thanks. Agner Fog gets the last word on this topic! Well, Agner is rarely wrong indeed, but there is a limit to how much material a single person can keep up to date. On newer uarchs, `rep movsb` isn't slower than `rep movsd`, and often performs similar to the best SSE2 implementation (using NT stores). See "BeeOnRope"'s answer to this StackOverflow question for an in-depth discussion about this: https://stackoverflow.com/questions/43343231/enhanced-rep-movsb-for-memcpy AVX2 seems to offer extra performance beyond that, though, if it is available (for example if runtime feature detection is used). I believe I read a comment by Agner somewhere to that effect as well – a search engine will certainly be able to turn up more. — David
Re: Replacing C's memcpy with a D implementation
On Monday, 11 June 2018 at 03:34:59 UTC, Basile B. wrote: - default linux: https://github.com/gcc-mirror/gcc/blob/master/libgcc/memcpy.c To see what is executed when you call memcpy() on a regular GNU/Linux distro, you'd want to have a look at glibc instead. For example, the AVX2 and AVX512 implementations are in sysdeps/x86_64/multiarch/memmove-avx512-no-vzeroupper.S and sysdeps/x86_64/multiarch/memmove-vec-unaligned-erms.S, as forwarded to by memmove-avx2-unaligned-erms.S and memmove-avx512-unaligned-erms.S. (Pop quiz: Why might a separate "no-vzeroupper" variant be a good idea?) — David
Re: D community's view on syntactic sugar
On Friday, 15 June 2018 at 23:04:40 UTC, Sjoerd Nijboer wrote:
For someone coming from a C# background there is some seemingly
simple syntactic sugar missing from D.
* The null conditional operator `?.`
Null-safe dereference operator, I think it's called?
Hrm, my first impulse was in favor. I find this useful in Kotlin
and I miss it when using Java. In D, I don't encounter null very
often at all.
* Something like a `yield return` statement for coroutines.
For iterables, more like? If you want a userspace thread, Fiber
gives you this. But it can be annoying right now to write a range.
T* he `async` & `await` keyword from C# make proactor pattern
async code extremely easy to reason about.
http://journal.stuffwithstuff.com/2015/02/01/what-color-is-your-function/
Maybe not the best. It's useful when you want to execute a small
fixed number of heterogeneous things in parallel, but the cost is
that everyone has to choose whether to make their thing run
asynchronously or synchronously, and there's going to be pressure
to make everything that could take more than a few milliseconds
to go asynchronous. This would force almost every program to be
multithreaded.
* a good syntax for properties so there's less code bloat.
C# has syntax like:
public int Something { get; set; }
It does this to make it easier to switch out a field for a
computed property, to add validation to a field, and to let you
put properties into interfaces.
D code typically doesn't use interfaces much, and you don't have
to do anything special to convert a field into a getter/setter
pair.
The only case where D loses out is compared to { get; private
set; }.
* replacing `Allocator.make()` with `new!Allocator`. After all
`new` can be concidered as just a wrapper around the standard
GC allocator. Why can't we just have a special template of it?
allocator.make!Foo(args)
new!allocator Foo(args)
One character difference. Doesn't seem like a big deal.
Re: D community's view on syntactic sugar
On Sunday, 17 June 2018 at 16:52:59 UTC, Neia Neutuladh wrote:
The only case where D loses out is compared to { get; private
set; }.
That's a pretty big thing to give up. That allows for pretty
valuable control over visibility of encapsulated properties.
Cannot hash a std.datetime.Date
The following
unittest
{
import std.datetime.date : Date;
Date date;
import core.internal.hash : hashOf;
auto hash = date.hashOf;
}
errors (with DMD v2.081.0-beta.1) as
/usr/include/dmd/druntime/import/core/internal/convert.d(619,101): Error:
template `core.internal.convert.toUbyte` cannot deduce function from argument
types `!()(Month)`, candidates are:
/usr/include/dmd/druntime/import/core/internal/convert.d(14,16):
`core.internal.convert.toUbyte(T)(ref T val) if
(is(Unqual!T == float) || is(Unqual!T == double) || is(Unqual!T
== real) || is(Unqual!T == ifloat) || is(Unqual!T == idouble) ||
is(Unqual!T == ireal))`
/usr/include/dmd/druntime/import/core/internal/convert.d(479,16):
`core.internal.convert.toUbyte(T)(T[] arr) if (T.sizeof ==
1)`
/usr/include/dmd/druntime/import/core/internal/convert.d(485,16):
`core.internal.convert.toUbyte(T)(T[] arr) if
(is(typeof(toUbyte(arr[0])) == const(ubyte)[]) && (T.sizeof > 1))`
/usr/include/dmd/druntime/import/core/internal/convert.d(503,16):
`core.internal.convert.toUbyte(T)(ref T val) if
(__traits(isIntegral, T) && !is(T == enum))`
/usr/include/dmd/druntime/import/core/internal/convert.d(537,16):
`core.internal.convert.toUbyte(T)(ref T val) if
(is(Unqual!T == cfloat) || is(Unqual!T == cdouble) || is(Unqual!T
== creal))`
/usr/include/dmd/druntime/import/core/internal/convert.d(619,101):...
(2 more, -v to show) ...
/usr/include/dmd/druntime/import/core/internal/hash.d(145,37):
Error: template instance `core.internal.convert.toUbyte!(Date)`
error instantiating
foo.d(6,21):instantiated from here: `hashOf!(Date)`
but not with 2.080.1. A regression?
Re: An (old/new?) pattern to utilize phobos better with @nogc
On Sunday, 17 June 2018 at 13:50:31 UTC, Seb wrote: On Saturday, 16 June 2018 at 11:58:47 UTC, Dukc wrote: What are your thoughts? Do you agree with this coding pattern? It would even be better if map can recognize tuples and thus allows to simply use a lambda functions with two parameters, but in the past with a few exceptions there hasn't been much support/consensus on specializing Phobos functions for tuples. Yes, I agree. And each too, of course.
Re: allMembers broke for __
On 6/15/2018 11:08 PM, DigitalDesigns wrote: When an identifier starts with __, allMembers does not return it. This is very bad behavior! It can silently create huge problems if the programmer is not aware of the bug. It's not a bug, it's quite deliberate: https://github.com/dlang/dmd/blob/master/src/dmd/traits.d#L1385 Identifiers starting with __ are reserved for the implementation: https://dlang.org/spec/lex.html#identifiers They have implementation-defined behavior. Do not use them in user code.
Re: allMembers broke for __
On Sunday, 17 June 2018 at 22:55:57 UTC, Walter Bright wrote: On 6/15/2018 11:08 PM, DigitalDesigns wrote: When an identifier starts with __, allMembers does not return it. This is very bad behavior! It can silently create huge problems if the programmer is not aware of the bug. It's not a bug, it's quite deliberate: https://github.com/dlang/dmd/blob/master/src/dmd/traits.d#L1385 Identifiers starting with __ are reserved for the implementation: https://dlang.org/spec/lex.html#identifiers They have implementation-defined behavior. Do not use them in user code. If you don't want me to use it then why not give an error instead of punishing me by introducing very difficult bugs to detect? Do you really think that everyone that starts using D will automatically know the traps of __ and avoid it like the plague just because you said so(even though they probably never actually seen you say it)? How about instead of __, you guys use in your code? That would be more sane than breaking my code because I used an extra _. Again, you can justify all you want... it doesn't make it right.
Re: D community's view on syntactic sugar
On Sunday, 17 June 2018 at 17:48:21 UTC, FromAnotherPlanet wrote:
On Sunday, 17 June 2018 at 16:52:59 UTC, Neia Neutuladh wrote:
The only case where D loses out is compared to { get; private
set; }.
That's a pretty big thing to give up. That allows for pretty
valuable control over visibility of encapsulated properties.
He means that in D this is split like that, which isn't as clean
as C# does
class MyClass
{
private int _myProp; // backing field
private @property void myProp(int a) { _myProp = a; } //
private setter
public @property int myProp() { return _myProp; } // getter
}
Re: import std.traits. std.string;
On Saturday, 16 June 2018 at 06:43:25 UTC, Meta wrote: On Saturday, 16 June 2018 at 00:24:42 UTC, DigitalDesigns wrote: space is ignored! Seems like a bug std . traits . std . string is valid? Like most C-family languages, D is a freeform language[1]. Funnily enough, I don't think this is explicitly stated in the D spec (at least not that I could find). It's just assumed, because D is an evolution of C, C++, and Java primarily, all of which are freeform languages. From the Language → Lexical docs: "The lexical analysis is independent of the syntax parsing and the semantic analysis. The lexical analyzer splits the source text up into tokens. The lexical grammar describes the syntax of those tokens." "The source text is decoded from its source representation into Unicode Characters. The Characters are further divided into: WhiteSpace, EndOfLine, Comments, SpecialTokenSequences, Tokens, all followed by EndOfFile." So a source file contains a number of things, some of them tokens. The tokenizer produces a series of tokens from it. The parser deals with those tokens. This doesn't state that whitespace is ignored; instead, it says that the language only pays attention to tokens (and, by implication, not whitespace, or comments, or the end of the file, etc).
Re: Cannot hash a std.datetime.Date
On Sunday, June 17, 2018 18:15:19 Per Nordlöw via Digitalmars-d wrote:
> The following
>
> unittest
> {
> import std.datetime.date : Date;
> Date date;
> import core.internal.hash : hashOf;
> auto hash = date.hashOf;
> }
>
> errors (with DMD v2.081.0-beta.1) as
>
> /usr/include/dmd/druntime/import/core/internal/convert.d(619,101): Error:
> template `core.internal.convert.toUbyte` cannot deduce function from
> argument types `!()(Month)`, candidates are:
> /usr/include/dmd/druntime/import/core/internal/convert.d(14,16):
> `core.internal.convert.toUbyte(T)(ref T val) if
> (is(Unqual!T == float) || is(Unqual!T == double) || is(Unqual!T
> == real) || is(Unqual!T == ifloat) || is(Unqual!T == idouble) ||
> is(Unqual!T == ireal))`
> /usr/include/dmd/druntime/import/core/internal/convert.d(479,16):
> `core.internal.convert.toUbyte(T)(T[] arr) if (T.sizeof ==
> 1)`
> /usr/include/dmd/druntime/import/core/internal/convert.d(485,16):
> `core.internal.convert.toUbyte(T)(T[] arr) if
> (is(typeof(toUbyte(arr[0])) == const(ubyte)[]) && (T.sizeof > 1))`
> /usr/include/dmd/druntime/import/core/internal/convert.d(503,16):
> `core.internal.convert.toUbyte(T)(ref T val) if
> (__traits(isIntegral, T) && !is(T == enum))`
> /usr/include/dmd/druntime/import/core/internal/convert.d(537,16):
> `core.internal.convert.toUbyte(T)(ref T val) if
> (is(Unqual!T == cfloat) || is(Unqual!T == cdouble) || is(Unqual!T
> == creal))`
> /usr/include/dmd/druntime/import/core/internal/convert.d(619,101):
> ... (2 more, -v to show) ...
> /usr/include/dmd/druntime/import/core/internal/hash.d(145,37):
> Error: template instance `core.internal.convert.toUbyte!(Date)`
> error instantiating
> foo.d(6,21):instantiated from here: `hashOf!(Date)`
>
> but not with 2.080.1. A regression?
I'm not very familiar with the details of hashOf, so I can't say for sure
whether this is a regression or not, but in most cases, if something worked
in a previous release but doesn't work now, and there are no deprecation
messages involved, then it's probably a regression (especially if the
changelog doesn't say anything about it). Occasionally, the breakage is
intentional, but you pretty much can't go wrong by reporting it as a
regression. Worst case, it turns out that it was completely on purpose, and
the bug report will be closed accordingly. But if you don't report it as a
regression, and it is one, then it probably won't be fixed before the actual
release.
Glancing over the changelog, there are multiple entries which have to do
with improving core.internal.hash, and my guess would be that one of those
changes accidentally broke something.
- Jonathan M Davis
Friends in D, the easy way!
These go in the module you want allow access to the outside world
just as if they were in the same module!
auto Setter(string name, alias O, T)(T t)
{
mixin("t."~name~" = O();");
}
auto ref Getter(string name, T)(T t)
{
mixin("return t."~name~";");
}
x.Setter!("privateFieldName", { return value; }); //
privateFieldName = value;
x.Getter!("privateFieldName"); // = privateFieldName
You can think me now... or later, which ever you choose! I hope
there is no SOLID henchmen here!
Of course, these should be used only between modules that are
tightly coupled... This can happen when a derived class needs
access to it's parent as if it were in the same module but the
modules are split only for parsing.
Re: An (old/new?) pattern to utilize phobos better with @nogc
On Sunday, 17 June 2018 at 20:17:36 UTC, Dukc wrote: Yes, I agree. And each too, of course. Thought again and not so sure anymore: I just realized that if we are to do that, it should apply the same changes to tee, find, filter etc. Probably too complicated to be worth it. For @nogc, there's also always hope that we will be able to mark delegates scope, and with -dip1000, use local variables directly again.
