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
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 pr
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
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` (assu
What's the differences in the approaches between SOLID and
component programming? Are they orthogonal? Or can they be used
together?
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.
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 b
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, wherea
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 pers
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 i
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.
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.
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.toU
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,
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
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 b
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 visibilit
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 exp
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/
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!("privateFieldNa
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
21 matches
Mail list logo
