On Wednesday, 15 October 2014 at 14:42:30 UTC, Regan Heath wrote:
On Thu, 09 Oct 2014 09:50:44 +0100, Martin Nowak
wrote:
Would this affect your code?
No
Do you think it makes your code better or worse?
Better. More clear
Is this just a pointless style change?
No
Has anybody some methodology or codestyle for mixin template?
I use general nouns for structures and classes and verbs for
functions. Variables and functions start with lowercase,
structures, classes and enums uppercase, templates follow their
internal content (eponymous trick helps very with
TL;DR: I think it would be good to have a strong community
guideline
that people are not to be criticized or treated badly for
having
requests or suggestions, even if they are not willing to
implement
them themselves. The quid pro quo is that it's necessary to be
(calmly) candid with people ab
For my particular project (it binds with something like finite
state machine) I will write some counterpart of decode function
from std.utf. Future function will decode string backward, return
dchar and change index passed by reference.
Is it interesting for community that I code this feature
I'm pretty sure that you basically have to do what strideBack
does before
you can decode a code point, so all decodeBack would do would
be to do
exactly what back already does for strings, which is to use
strideBack
followed by decode.
- Jonathan M Davis
I have to read more attentively std.u
On Tuesday, 6 January 2015 at 16:58:24 UTC, Andrei Alexandrescu
wrote:
On 1/5/15 10:43 PM, HaraldZealot wrote:
For my particular project (it binds with something like finite
state
machine) I will write some counterpart of decode function from
std.utf.
Future function will decode string backward
On Saturday, 10 January 2015 at 20:18:03 UTC, Walter Bright wrote:
Has someone made a dfmt, like http://gofmt.com/ ?
I with one my good student have started project coDewife 1,5
month ago. It based on some interesting theoretical approach
(something like FSM, but with essential differences).
That said, I really want my destructors, and would be very
upset to
see them go. So... ARC?
Manu, can you direct me what is ARC? This abbreviation is very
misgooglly.
I have to say that all this discussion (more precisely the
understanding on the side of key developers) make me very upset.
It's good that Andrei agreed with impossibility of the
harebrained disallowing of the class destructors. But I was very
surprise, that so thought go to such head, because
That experimental package idea that was discussed months ago
comes to my mind again. Add that thing as exp.rational and
have people report bugs or shortcomings to the original
author. When it seems to be usable by everyone interested it
can move into Phobos proper after the formal review (that
i
The major issue with the garbage collector is that it's not
guaranteed to run a collection. When a collection is run the GC
will call the destructors for the objects it collects. If
there's no guarantee a collection is run there can be no
guarantee that destructors are called. A collection is
Destructors of the first kind are usually called just
destructors and are used for resource management, and the
second kind are called finalizers. These are useful for
implementing weak references, caching, and various other things
where you don't require objects to be destroyed at a certain
p
This is a misunderstanding of the situation. This is
brainstorming. There has to be a public place in which ideas
can be discussed freely, no matter how radical.
This is another misunderstanding :)). Not radicalism upset me,
but proposal to create one more hole instead exist hole from man,
th
This is another misunderstanding :)). Not radicalism upset me,
but proposal to create one more hole instead exist hole from
man, that touched me solidness in code by his book. It were
surprising. But it's only emotion.
But yes, It may possible as troll mode in brainstorming.
This looks like interesting.
The logger is very good and need thing. But has anybody an idea
how to preserve purity of functions?
std.experimintal is helpfull and I rejoy about.
But I think, we can have better place as subpackage.
I wrote some ideas about, but they have sunk in other topic.
http://forum.dlang.org/thread/ljrm0d$28vf$1...@digitalmars.com?page=16#post-mdhlmsxfzaelpdgwfbfh:40forum.dlang.org
I use Archlinux 64 exclusivly.
And my students use arch, LinuxMint and Windows7 for their D
projects
Well, they're definitely cool looking (and I certainly couldn't
do anything
that looks that good), but nothing about them makes me think of
D.
- Jonathan M Davis
I totally agree with Jonathan.
--
Alaksiej Stankievič
Possible initial prerequisites:
- User awareness about the usage consequences
- Library placed at https://github.com/D-Programming-Language/
- Only well recognized community members have pull rights
- design decision made on the best known sw engineering
patterns used in D
- New module should be
Another variant somewhere between the all-red one and the
all-grey one:
http://ag0aep6g-dlang.rhcloud.com/variants/grey-newlogo/
+1
but perhaps blending between logo and menu were good.
On Sunday, 1 February 2015 at 09:46:16 UTC, HaraldZealot wrote:
Another variant somewhere between the all-red one and the
all-grey one:
http://ag0aep6g-dlang.rhcloud.com/variants/grey-newlogo/
And also when Phobos and Deimos receive some grayness than D
letter becomes more contrast and rec
On Sunday, 09 April 2017 at 23:14:08 UTC, Jack Stoufer wrote:
You're missing the forrest for the trees. D needs a general
solution to the problem of GC code in Phobos. This >tackles one
specific area via special case but leaves every other GC
allocation in Phobos, with no way to make >it @saf
On Thursday, 6 April 2017 at 17:56:03 UTC, bachmeier wrote:
On Thursday, 6 April 2017 at 13:55:43 UTC, Olivier FAURE wrote:
I don't want to make any assumptions, and I do respect Walter
for consistently taking on a role that means that people keep
criticizing his choices whatever he does, but
On Thursday, 14 May 2015 at 06:02:37 UTC, thedeemon wrote:
On Wednesday, 13 May 2015 at 18:59:42 UTC, Dennis Ritchie wrote:
http%3A%2F%2Fhabrahabr.ru%2Fpost%2F257875%2F
Just some usual C++ critique and very vague basic principles
about having a core language with some extensions and library
On Wednesday, 20 May 2015 at 22:14:56 UTC, Adam D. Ruppe wrote:
Also, when are the videos going to be released this time? I'd
like it on youtube as soon as possible.
+1
So we have:
* 1 request to change names;
* 3 requests to wank around the directory structure;
* 0 of everything else.
Sigh.
Andrei
Yesterday I have found an error in documentation and have left a
comment about it on github PR.
And I only start to read the documentation, so I think there
On Wednesday, 17 June 2015 at 06:08:57 UTC, Andrei Alexandrescu
wrote:
Regarding compatibility, I see three possibilities:
1. Just keep the current spec and deal with it. Some containers
are and will remain garbage collected because they started as
such. Add new containers that are better alo
On Thursday, 4 June 2015 at 17:02:46 UTC, Oleg B wrote:
On Thursday, 4 June 2015 at 16:21:54 UTC, Jonathan M Davis
wrote:
I think toString for float must be pure, but in practice it's
not.
It's a bug? I read what std.format.format using libc sprintf
http://www.digitalmars.com/d/archives/di
On Wednesday, 24 June 2015 at 14:16:04 UTC, Jonathan M Davis
wrote:
On Wednesday, 24 June 2015 at 12:15:10 UTC, Joseph Rushton
Wakeling wrote:
Hello all,
As I promised at DConf (though sadly arriving a bit later than
I'd hoped), I've submitted a PR to convert std.random to a
package:
https:/
On Wednesday, 8 July 2015 at 09:13:27 UTC, Jonathan M Davis wrote:
On Wednesday, 8 July 2015 at 08:59:15 UTC, deadalnix wrote:
Yeah. Every name sucks. Alias seems to solve the first half of
the name reasonably well, but nothing that anyone has come up
with really solves the second half.
[...
On Monday, 20 July 2015 at 21:27:17 UTC, Mathias Lang wrote:
We do follow a versioning style: '2.MAJOR.PATCH' (with major
being 3 digits). It's not as good as SemVer, but better than it
was few years ago, and I have faith we'll end up following
SemVer at some point.
Following SemVer strict
I found myself in situation that were good that all types support
`.examplevalues` property in unittest version. This property will
return array of predefined values for specified type (we can even
have some convention like `examplevalues[0]` is `init`,
`examplevalues[1]` is `min` (for numerica
On Monday, 3 August 2015 at 13:13:55 UTC, Andrea Fontana wrote:
Why don't you use templates? Something like:
enum ValueType
{
Init,
Min,
Max
}
auto exampleValues(T)()
{
T[ValueType] retVal;
retVal[ValueType.Init] = T.init;
static if (__traits(compiles,
On Monday, 3 August 2015 at 14:30:43 UTC, Andrea Fontana wrote:
On Monday, 3 August 2015 at 13:54:51 UTC, HaraldZealot wrote:
You have to write the same amount of code.
It's just one line for each type... Something like:
[...]
Many thanks, it seems like good workaround for my personal use
ca
On Saturday, 15 August 2015 at 10:06:13 UTC, Joseph Rushton
Wakeling wrote:
...
In some cases we're going to want true laziness of evaluation,
but _not_ transience of .front. In these cases, the _first_
time .front is called, its value should be freshly evaluated;
but thereafter, the value i
On Tuesday, 18 August 2015 at 19:37:47 UTC, Joseph Rushton
Wakeling wrote:
Yes, broadly like your example, although note that your version
won't handle multiple popFront() calls in succession without
any .front call in-between.
Good point! And you show acceptable solution.
The last your exa
On Tuesday, 12 April 2011 at 16:44:10 UTC, David Nadlinger wrote:
Recently, I have been playing around with a little units of
measurement system in D. As this topic has already been brought
up quite a number of times here, I thought I would put my
implementation up for discussion here.
...
A
On Tuesday, 3 May 2016 at 03:48:09 UTC, Joe Duarte wrote:
Hi all,
I'm a social scientist and I'm preparing some studies on the
effects of programming language syntax on learning, motivation
to pursue programming, as well as any disproportionate effects
that PL syntax has on the appeal of prog
On Thursday, 2 June 2016 at 10:56:36 UTC, Martin Nowak wrote:
On 04/23/2016 04:17 PM, Seb wrote:
This project is about adding non-uniform random generators to
mir and hopefully eventually to Phobos.
I just happen to need a gaussian random number generator right
now. Is there already some WIP
On Monday, 6 June 2016 at 09:16:45 UTC, Walter Bright wrote:
Paying attention to our existing users is a much more reliable
source of information.
+1000
All ranges in Phobos pass by value, but if I have output range
with state like cumulative statistics this is useless.
After discussion with Dicebot I try this work-arround:
http://dpaste.dzfl.pl/8af8eb8d0007
It is unfinished. But direction is observable.
Is this good solution? And how about to
On Friday, 20 November 2015 at 18:48:51 UTC, Alex Parrill wrote:
On Friday, 20 November 2015 at 18:23:57 UTC, HaraldZealot wrote:
I'm not sure how useful this is as opposed to plain pointers.
For structs, since `foo.bar` is the same as `(&foo).bar`, you
may as well use a pointer, and the only
On Friday, 20 November 2015 at 19:53:23 UTC, HaraldZealot wrote:
On Friday, 20 November 2015 at 18:48:51 UTC, Alex Parrill wrote:
On Friday, 20 November 2015 at 18:23:57 UTC, HaraldZealot
wrote:
You say ranges are pass-by-value, but that's not entirely
true. Ranges themselves can be classes,
On Monday, 23 November 2015 at 12:09:13 UTC, Jonathan M Davis
wrote:
On Monday, 23 November 2015 at 11:31:32 UTC, HaraldZealot wrote:
RefRange is not intended to work with output ranges, and output
ranges are very different beasts from input ranges, so any kind
of reference type wrapper for ou
On Monday, 23 November 2015 at 15:35:32 UTC, Jonathan M Davis
wrote:
Well, if all you want is to get a reference type out of a value
type, then putting it on the heap and using a pointer to it
would be a solution. Using RefCounted would be another, and I
would think that it would be similar t
On Saturday, 23 January 2016 at 14:19:03 UTC, Jacob Carlborg
wrote:
This is mostly to prevent ugly hacks like Flag [1].
http://wiki.dlang.org/DIP88
[1] https://dlang.org/phobos/std_typecons.html#.Flag
Why not simply allow programmer to declare auto variable at
function call side like in `for
On Monday, 25 January 2016 at 14:35:09 UTC, arturg wrote:
On Monday, 25 January 2016 at 13:40:18 UTC, HaraldZealot wrote:
the equal sign cant be used because D behaves like this
int width, height;
foo(width = 5, height = 10); // 5
// 10
width.writeln; // 5
height.w
In current D, overloading operator like "+" with external
function is prohibited. There is the rationale [1] (see second
paragraph).
BUT this rationale is totally UNCONVINCING. I can say that resume
of rationale is: "it is impossible because it brakes some C++
patterns and behaviour". Further
On Wednesday, 21 September 2016 at 19:01:40 UTC, Timon Gehr wrote:
Basically, the rationale is: external operators cannot be used
in generic code that does not import the module defining the
operators.
Could you give some elaborate example, for now I can't imagine
what your mean.
On Wednesday, 21 September 2016 at 21:14:15 UTC, H. S. Teoh wrote:
Thank you both, I see now.
So it seems to be essential point. But because we already have
the same problem with UFCS, I don't see why we should prohibit
external overloading of operator, it is just inequality (in
political
On Thursday, 22 September 2016 at 05:38:53 UTC, HaraldZealot
wrote:
And problem with generic code solve independently for all UFCS
functions including operators.
Unfortunately I don't know compiler and all related stuff
internally (time to change this ;) ), but it seems to me there is
a way
On Thursday, 22 September 2016 at 07:14:52 UTC, H. S. Teoh wrote:
It's not so simple. The UFCS operator overload could be
declared in a different module from the type itself. Then
there is no guarantee that it will be found. Multiple calls to
the same template function with the same argume
On Thursday, 22 September 2016 at 08:53:26 UTC, HaraldZealot
wrote:
OK, it seems to me it's time to investigate a community opinion.
So let's vote for the following sentence:
"It would be good to have an operator overloading even without
support in generic function"
On Thursday, 22 September 2016 at 08:58:54 UTC, HaraldZealot
wrote:
So let's vote for the following sentence:
"It would be good to have an operator overloading even without
support in generic function"
Yes
On Wednesday, 14 December 2016 at 03:49:23 UTC, Jonathan M Davis
wrote:
On Tuesday, 13 December 2016 at 22:40:47 UTC, 01010100b wrote:
The _only_ way to eliminate all of the inconsistencies with @
is to get rid of it from everywhere but UDAs, and turn all of
those built-in attributes into full
On Wednesday, 14 December 2016 at 12:00:04 UTC, ketmar wrote:
On Wednesday, 14 December 2016 at 09:51:00 UTC, Joseph Rushton
Wakeling wrote:
On Wednesday, 14 December 2016 at 03:49:23 UTC, Jonathan M
Davis wrote:
I say that when dealing with the built-in attributes, just
treat @ like another le
57 matches
Mail list logo