On Sunday, 17 April 2016 at 23:03:26 UTC, Adam D. Ruppe wrote:
On Sunday, 17 April 2016 at 21:20:49 UTC, Timon Gehr wrote:
On 17.04.2016 18:44, Nick Treleaven wrote:
I think @property is OK.
No, it isn't:
Seriously, @property is one of the biggest SNAFUs of the
language.
Today I learn
On Monday, 18 April 2016 at 00:27:06 UTC, Joe Duarte wrote:
On Tuesday, 5 April 2016 at 10:27:46 UTC, Walter Bright wrote:
Besides, I think it's a poor design to customize the app for
only one SIMD type. A better idea (I've repeated this ad
nauseum over the years) is to have n modules, one for
On Sunday, 17 April 2016 at 23:03:26 UTC, Adam D. Ruppe wrote:
On Sunday, 17 April 2016 at 21:20:49 UTC, Timon Gehr wrote:
On 17.04.2016 18:44, Nick Treleaven wrote:
I think @property is OK.
No, it isn't:
Seriously, @property is one of the biggest SNAFUs of the
language.
I think I'll wr
On Tuesday, 5 April 2016 at 10:27:46 UTC, Walter Bright wrote:
Besides, I think it's a poor design to customize the app for
only one SIMD type. A better idea (I've repeated this ad
nauseum over the years) is to have n modules, one for each
supported SIMD type. Compile and link all of them in, t
On Sunday, 17 April 2016 at 23:10:38 UTC, Adam D. Ruppe wrote:
On Sunday, 17 April 2016 at 22:08:55 UTC, Bauss wrote:
Like I also said this does not apply to normal mixins but
usually very big mixins composited of multiple mixins and
template mixins.
Why are your mixins so huge?
But yeah, I
On Sunday, 17 April 2016 at 22:08:55 UTC, Bauss wrote:
On Sunday, 17 April 2016 at 21:59:38 UTC, Timon Gehr wrote:
On 17.04.2016 23:49, Bauss wrote:
On Sunday, 17 April 2016 at 21:23:58 UTC, Timon Gehr wrote:
mixin(generate());
pragma(msg,generate());
That's not a solution to the problem, be
On Sunday, 17 April 2016 at 22:08:55 UTC, Bauss wrote:
Like I also said this does not apply to normal mixins but
usually very big mixins composited of multiple mixins and
template mixins.
Why are your mixins so huge?
But yeah, I would like to see it print the error line and a few
surrounding
On Sunday, 17 April 2016 at 21:20:49 UTC, Timon Gehr wrote:
On 17.04.2016 18:44, Nick Treleaven wrote:
I think @property is OK.
No, it isn't:
Seriously, @property is one of the biggest SNAFUs of the language.
I think I'll write an editorial about this stuff in TWID tonight.
(I'm also very
On Sunday, 17 April 2016 at 09:43:09 UTC, Marc Schütz wrote:
The "source" link at the bottom is broken, though.
That's a ddoc misdesign that I'm in the process of correcting.
On Sunday, 17 April 2016 at 05:04:46 UTC, H. S. Teoh wrote:
I'm pretty sure that toImpl being public is an oversight. The
name itself implies that it should be private. I seriously
doubt any user code actually calls toImpl directly... shouldn't
it be just a matter of marking it private instead
On Sunday, 17 April 2016 at 21:59:38 UTC, Timon Gehr wrote:
On 17.04.2016 23:49, Bauss wrote:
On Sunday, 17 April 2016 at 21:23:58 UTC, Timon Gehr wrote:
mixin(generate());
pragma(msg,generate());
That's not a solution to the problem, because you will be
printing ALL
mixins and not just the
On Sunday, 17 April 2016 at 11:00:33 UTC, Jonathan M Davis wrote:
What do you propose that we do instead? We need all of the
separate toImpl functions regardless of the name. Do you want
to try and embed them all inside of std.conv.to with the name
to? I expect that it's feasible, but it would
On 17.04.2016 23:49, Bauss wrote:
On Sunday, 17 April 2016 at 21:23:58 UTC, Timon Gehr wrote:
mixin(generate());
pragma(msg,generate());
That's not a solution to the problem, because you will be printing ALL
mixins and not just the ones causing compilation errors.
Obviously you'll insert th
On Sunday, 17 April 2016 at 21:23:58 UTC, Timon Gehr wrote:
mixin(generate());
pragma(msg,generate());
That's not a solution to the problem, because you will be
printing ALL mixins and not just the ones causing compilation
errors.
On 17.04.2016 18:44, Nick Treleaven wrote:
I think @property is OK.
No, it isn't:
import std.stdio;
struct S{
@property int delegate() foo(){ return ()=>3; }
}
void main(){
S s;
writeln(s.foo()); // "int delegate()"
}
On 17.04.2016 23:18, Bauss wrote:
Can there please be implemented something to retrieve the generated
mixins that causes compiler errors; like perhaps a flag you pass that
will print all mixins with compiler errors?
Sometimes when you create highly dynamic mixins it can be hard to
identify error
Can there please be implemented something to retrieve the
generated mixins that causes compiler errors; like perhaps a flag
you pass that will print all mixins with compiler errors?
Sometimes when you create highly dynamic mixins it can be hard to
identify errors in them, because you might not
On Friday, 20 June 2014 at 19:22:04 UTC, Brian Schott wrote:
http://wiki.dlang.org/DIP64
Attributes in D have two problems:
1. There are too many of them and declarations are getting too
verbose
2. New attributes use @ and the old ones do not.
I've created a DIP to address these issues.
Nic
On Sun, Apr 17, 2016 at 03:32:16AM -0700, Jonathan M Davis via Digitalmars-d
wrote:
> On Saturday, April 16, 2016 22:04:46 H. S. Teoh via Digitalmars-d wrote:
> > On Fri, Apr 15, 2016 at 05:23:26PM +, Jack Stouffer via Digitalmars-d
> wrote:
> > > Before I opened a PR, I wanted to get some se
On 17.04.2016 19:39, QAston wrote:
First @property + compiler switch, now @property + deprecated switch.
When should I use property? For all the getters? Should I start with
property or with member access? Does it even matter because of optional
parens? Why do I even need to care about this?
@p
On Sunday, 17 April 2016 at 16:44:50 UTC, Nick Treleaven wrote:
The @safe troika is a good design (except @safe should be the
default), the implementation is lacking though. Ideallists want
to make @safe strict now, but break code sometimes even without
basic workarounds for memory-safe code. P
On Friday, 15 April 2016 at 17:24:19 UTC, Andrei Alexandrescu
wrote:
inout(T)[] overlap(T)(inout(T)[] r1, inout(T)[] r2) @trusted
BTW, why is overlap undocumented - is ctfe support a good enough
reason?
https://github.com/dlang/phobos/blob/v2.071.0/std/array.d#L715
I've thought about impleme
On Sunday, 17 April 2016 at 12:05:03 UTC, Anonymous5 wrote:
If attributes are well split into sub categories, we could
justify that a sub category will have @ and another not (e.g
protection attributes: not @, functions attributes: @).
The list of attributes that's not classified is:
+ static
On Sunday, 17 April 2016 at 14:30:59 UTC, QAston wrote:
You've got lucky with pure (modulo corner cases) and ctfe, much
less lucky with @safe, @trusted, @system, inout, shared, scope,
property.
The @safe troika is a good design (except @safe should be the
default), the implementation is lacki
I recently found myself wanting an algorithm to apply f(x)
repeatedly, generating an infinite sequence, for a variety of
reasons. One of those reasons is to generate ancestor
directories. Typically when I desire such a thing, I find myself
trying to find the existing algorithm which does this a
Am Fri, 15 Apr 2016 12:08:37 -0400
schrieb Andrei Alexandrescu :
> https://github.com/D-Programming-Language/phobos/pull/4200 -- Andrei
Whenever I notice something like that in my code, it makes
me smile with the reassuring thought that the right design
choices were taken that reduce code complex
On Friday, 15 April 2016 at 20:03:07 UTC, Andrei Alexandrescu
wrote:
We should really do away with the cowboy style of designing
language, which sadly Walter and I have been guilty of too
often in the past. The slow but sure accretion of complexity of
inout is a textbook example of where that l
Am Sat, 16 Apr 2016 21:46:08 -0700
schrieb Walter Bright :
> On 4/16/2016 2:40 PM, Marco Leise wrote:
> > Tell me again, what's more elgant !
>
> If I wanted to write in assembler, I wouldn't write in a high level language,
> especially a weird one like GNU version.
I hate the many pitfalls o
On Sunday, 17 April 2016 at 11:26:02 UTC, Walter Bright wrote:
My experience is that over time one gets used to writing 32/64
bit portable code naturally, and the minor irritations don't
happen anymore. D isn't a language that tries to hide the
differences, and one should be aware of them.
A
On 04/17/2016 09:10 AM, Ilya Yaroshenko wrote:
> We plan to add a set of numeric packages and this would be real pain if
> they would be one-by-one moved from experimental to stable std. So sci.*
> should be considered as experimental during few years.
>
>
> https://github.com/dlang/phobos/pull/4
On Friday, 20 June 2014 at 19:22:04 UTC, Brian Schott wrote:
http://wiki.dlang.org/DIP64
Attributes in D have two problems:
1. There are too many of them and declarations are getting too
verbose
2. New attributes use @ and the old ones do not.
I've created a DIP to address these issues.
@ex
On 4/17/2016 2:29 AM, WebFreak001 wrote:
It's annoying to fix all these `int index = str.indexOf("something")` to
size_t/ptrdiff_t because you started writing the code thinking that indexOf
returns an integer even though it returns a ptrdiff_t. When porting code from
32bit to 64bit you need to fi
On Friday, April 15, 2016 17:23:26 Jack Stouffer via Digitalmars-d wrote:
> Before I opened a PR, I wanted to get some second opinions.
>
> There is no reason IMO that the various overloads of toImpl
> should be public. Having the internal functionality of a parent
> function, in this case to, be e
On Sunday, April 17, 2016 09:51:07 WebFreak001 via Digitalmars-d wrote:
> On Sunday, 17 April 2016 at 09:38:33 UTC, Temtaime wrote:
> > On Sunday, 17 April 2016 at 09:29:33 UTC, WebFreak001 wrote:
> >> It's annoying to fix all these `int index =
> >> str.indexOf("something")` to size_t/ptrdiff_t be
On Saturday, April 16, 2016 22:04:46 H. S. Teoh via Digitalmars-d wrote:
> On Fri, Apr 15, 2016 at 05:23:26PM +, Jack Stouffer via Digitalmars-d
wrote:
> > Before I opened a PR, I wanted to get some second opinions.
> >
> > There is no reason IMO that the various overloads of toImpl should be
On Sunday, 17 April 2016 at 09:44:30 UTC, Ilya Yaroshenko wrote:
This would be a real pain for a user if he supports few
compiler versions.
This approach is wrong because you assume there won't be changes
to how module works while in experimental and during transition
from experimental to sta
On 17.04.2016 11:44, Ilya Yaroshenko wrote:
This would be a real pain for a user if he supports few compiler versions.
static if(__VERSION__ < 2072)
{
import std.experimental.sci.ndslice;
}
else
{
import std.sci.ndslice;
}
[...]
Breakage is what you sign up for when using experiment
On Sunday, 17 April 2016 at 09:38:33 UTC, Temtaime wrote:
On Sunday, 17 April 2016 at 09:29:33 UTC, WebFreak001 wrote:
It's annoying to fix all these `int index =
str.indexOf("something")` to size_t/ptrdiff_t because you
started writing the code thinking that indexOf returns an
integer even th
On Sunday, 17 April 2016 at 09:32:25 UTC, QAston wrote:
On Sunday, 17 April 2016 at 09:09:52 UTC, Ilya Yaroshenko wrote:
Just with std.sci.* without `experimental`. Otherwise this
would be the same problem.
What's wrong with std.experimental.sci.*? experimental is where
experimental modules
On Sunday, 17 April 2016 at 02:03:06 UTC, Adam D. Ruppe wrote:
BTW, my superior doc site handles it this way:
http://dpldocs.info/experimental-docs/std.experimental.allocator.html
It marries the package.d contents along with the other concept
of package as a collection of submodules.
The "sou
On Sunday, 17 April 2016 at 09:29:33 UTC, WebFreak001 wrote:
It's annoying to fix all these `int index =
str.indexOf("something")` to size_t/ptrdiff_t because you
started writing the code thinking that indexOf returns an
integer even though it returns a ptrdiff_t. When porting code
from 32bit
On Sunday, 17 April 2016 at 09:22:21 UTC, WebFreak001 wrote:
you need to use toImpl if you want to convert a number to/from
a specific base! I use that a lot when converting hexadecimal
values
No, the documentation just gives that impression. This works:
void main(string[] args) {
On Sunday, 17 April 2016 at 09:09:52 UTC, Ilya Yaroshenko wrote:
Just with std.sci.* without `experimental`. Otherwise this
would be the same problem.
What's wrong with std.experimental.sci.*? experimental is where
experimental modules/packages should go.
It's annoying to fix all these `int index =
str.indexOf("something")` to size_t/ptrdiff_t because you started
writing the code thinking that indexOf returns an integer even
though it returns a ptrdiff_t. When porting code from 32bit to
64bit you need to fix all these lines which can quickly bec
On Friday, 15 April 2016 at 17:23:26 UTC, Jack Stouffer wrote:
Before I opened a PR, I wanted to get some second opinions.
There is no reason IMO that the various overloads of toImpl
should be public. Having the internal functionality of a parent
function, in this case to, be exposed like this
On Sunday, 17 April 2016 at 08:49:53 UTC, Seb wrote:
On Sunday, 17 April 2016 at 07:35:19 UTC, Ilya Yaroshenko wrote:
On Sunday, 17 April 2016 at 07:30:38 UTC, Vladimir Panteleev
I don't understand, what's wrong with std.sci or etc.sci?
I am ok with std.sci for example. I just want to exclude
On Sunday, 17 April 2016 at 05:04:46 UTC, H. S. Teoh wrote:
On Fri, Apr 15, 2016 at 05:23:26PM +, Jack Stouffer via
Digitalmars-d wrote:
[...]
I'm pretty sure that toImpl being public is an oversight. The
name itself implies that it should be private. I seriously
doubt any user code act
On Sunday, 17 April 2016 at 07:35:19 UTC, Ilya Yaroshenko wrote:
On Sunday, 17 April 2016 at 07:30:38 UTC, Vladimir Panteleev
wrote:
On Sunday, 17 April 2016 at 07:25:55 UTC, Ilya Yaroshenko
wrote:
sci name was reserved for future use:
http://code.dlang.org/packages/sci
What does a Dub packag
On Sunday, 17 April 2016 at 07:30:38 UTC, Vladimir Panteleev
wrote:
On Sunday, 17 April 2016 at 07:25:55 UTC, Ilya Yaroshenko wrote:
sci name was reserved for future use:
http://code.dlang.org/packages/sci
What does a Dub package have to do with D module system
packages?
The goal is to incl
On Sunday, 17 April 2016 at 07:25:55 UTC, Ilya Yaroshenko wrote:
sci name was reserved for future use:
http://code.dlang.org/packages/sci
What does a Dub package have to do with D module system packages?
The goal is to include only good consistent basic functionality
for data/numeric/math/sci
On Sunday, 17 April 2016 at 07:11:17 UTC, Vladimir Panteleev
wrote:
On Sunday, 17 April 2016 at 06:10:34 UTC, Ilya Yaroshenko wrote:
We plan to add a set of numeric packages and this would be
real pain if they would be one-by-one moved from experimental
to stable std. So sci.* should be conside
On Sunday, 17 April 2016 at 07:02:25 UTC, Jack Stouffer wrote:
On Sunday, 17 April 2016 at 06:10:34 UTC, Ilya Yaroshenko wrote:
We plan to add a set of numeric packages and this would be
real pain if they would be one-by-one moved from experimental
to stable std. So sci.* should be considered a
On Sunday, 17 April 2016 at 06:10:34 UTC, Ilya Yaroshenko wrote:
We plan to add a set of numeric packages and this would be real
pain if they would be one-by-one moved from experimental to
stable std. So sci.* should be considered as experimental
during few years.
https://github.com/dlang/ph
On Sunday, 17 April 2016 at 06:10:34 UTC, Ilya Yaroshenko wrote:
We plan to add a set of numeric packages and this would be real
pain if they would be one-by-one moved from experimental to
stable std. So sci.* should be considered as experimental
during few years.
https://github.com/dlang/ph
54 matches
Mail list logo
