On Thursday, 19 December 2013 at 01:38:07 UTC, Kenji Hara wrote:
No, that's not merely syntactic choice. The 'const'
constructor/postblit is
a natural conclusion derived from the semantic meaning.
I tweaked descriptions in DIP to express it more clearly.
I disagree. It's the `unique` postblit
On Thursday, 19 December 2013 at 00:23:47 UTC, Dicebot wrote:
On Wednesday, 18 December 2013 at 23:51:06 UTC, Meta wrote:
Of course, another large boon would be to correct the
implementation of:
import std.algorithm: sort, find, splitter, swap;
So that it actually works in a sane way as oppos
https://docs.google.com/document/d/1P3BLR31VA8cvLJLfMibSuTdwTuF7WWLux71CYD0eeD8/preview?sle=true&pli=1
On 2013-12-18 22:40, Andrei Alexandrescu wrote:
There are several directions we can take this.
1. Improve the compiler to handle imports lazily, i.e. an unused import
is never opened. That's unlikely to help a lot of uses because most
unqualified name lookups require all imports to be loaded (e
On Tuesday, 17 December 2013 at 21:56:01 UTC, inout wrote:
I don't think it's the forums' issue - news.digitalmars.com was
failing (although the forums could do a better job of
recovering from timeouts).
I think it has to do with the hosting provider. Every night
(UTC+1), the forum is down.
2013/12/19 Timon Gehr
> The natural interpretation of a const constructor is that it constructs a
> const object directly. Such a constructor could eg. initialize a field
> declared with a mutable type using some external const reference.
>
> void foo(const(int[]) a){
> // ...
> struct S{
2013/12/19 Joseph Rushton Wakeling
> And you have this(...) const (aka "unique"), which can be used to
> construct both immutable and mutable instances.
>
> It seems to me that this is a very natural relation to the existing
> interpretation of mutable, immutable and const variables by the langua
On Thursday, 19 December 2013 at 00:15:12 UTC, Justin Whear wrote:
Presumably there would still be a std.algorithm package module;
the
questions is: does
import std.algorithm : joiner;
still work if std.algorithm is actually a package module and
joiner is in
a std.algorithm.joiner module?
On Wednesday, 18 December 2013 at 23:51:06 UTC, Meta wrote:
Of course, another large boon would be to correct the
implementation of:
import std.algorithm: sort, find, splitter, swap;
So that it actually works in a sane way as opposed to pulling
in everything.
I don't see how it is even theo
On Thu, 19 Dec 2013 00:51:04 +0100, Meta wrote:
> On Wednesday, 18 December 2013 at 23:08:21 UTC, Walter Bright wrote:
>> I favor (2), and also (4):
>>
>> 4. Break kitchen sink modules like std.algorithm into one module per
>> algorithm. This should not result in code duplication.
>
> That seems
On Wednesday, 18 December 2013 at 21:40:08 UTC, Andrei
Alexandrescu wrote:
1. Improve the compiler to handle imports lazily, i.e. an
unused import is never opened. That's unlikely to help a lot of
uses because most unqualified name lookups require all imports
to be loaded (even after the name i
On Wednesday, 18 December 2013 at 23:08:21 UTC, Walter Bright
wrote:
I favor (2), and also (4):
4. Break kitchen sink modules like std.algorithm into one
module per algorithm. This should not result in code
duplication.
That seems a little over the top. While I guess it's not
necessarily a
On 12/18/13 3:08 PM, Walter Bright wrote:
On 12/18/2013 1:40 PM, Andrei Alexandrescu wrote:
1. Improve the compiler to handle imports lazily, i.e. an unused
import is never
opened. That's unlikely to help a lot of uses because most unqualified
name
lookups require all imports to be loaded (even
On 12/18/2013 1:40 PM, Andrei Alexandrescu wrote:
1. Improve the compiler to handle imports lazily, i.e. an unused import is never
opened. That's unlikely to help a lot of uses because most unqualified name
lookups require all imports to be loaded (even after the name if resolved, the
compiler mu
On Wednesday, 18 December 2013 at 22:26:32 UTC, Timon Gehr wrote:
The natural interpretation of a const constructor is that it
constructs a const object directly. Such a constructor could
eg. initialize a field declared with a mutable type using some
external const reference.
void foo(const(i
On 12/18/2013 10:11 PM, Joseph Rushton Wakeling wrote:
And you have this(...) const (aka "unique"), which can be used to
construct both immutable and mutable instances.
It seems to me that this is a very natural relation to the existing
interpretation of mutable, immutable and const variables b
On Thu, Dec 19, 2013 at 01:47:26AM +0400, Dmitry Olshansky wrote:
> 19-Dec-2013 01:40, Andrei Alexandrescu пишет:
> >On 12/18/13 1:16 PM, Dmitry Olshansky wrote:
> >>19-Dec-2013 01:06, Andrei Alexandrescu пишет:
> >>>http://chopapp.com/#fvepfd8 shows the number of dependencies (plus
> >>>1) for eac
On Wednesday, 18 December 2013 at 21:11:10 UTC, Joseph Rushton
Wakeling wrote:
On 18/12/13 21:11, ilya-stromberg wrote:
Sorry if I miss something, but I don't understand this analogy.
`const` means that original type can be `mutable` or
`immutable`, so both
`mutable` and `immutable` types can
19-Dec-2013 01:40, Andrei Alexandrescu пишет:
On 12/18/13 1:16 PM, Dmitry Olshansky wrote:
19-Dec-2013 01:06, Andrei Alexandrescu пишет:
http://chopapp.com/#fvepfd8 shows the number of dependencies (plus 1)
for each module in phobos. Those include druntime dependencies.
So the bill of using
On 12/18/13 1:16 PM, Dmitry Olshansky wrote:
19-Dec-2013 01:06, Andrei Alexandrescu пишет:
http://chopapp.com/#fvepfd8 shows the number of dependencies (plus 1)
for each module in phobos. Those include druntime dependencies.
So the bill of using pretty much anything in Phobos is pulling in 87
19-Dec-2013 01:06, Andrei Alexandrescu пишет:
http://chopapp.com/#fvepfd8 shows the number of dependencies (plus 1)
for each module in phobos. Those include druntime dependencies.
So the bill of using pretty much anything in Phobos is pulling in 87
modules. Pretty much what I feared it is.
On 18/12/13 21:16, Timon Gehr wrote:
On 12/18/2013 08:09 PM, Joseph Rushton Wakeling wrote:
Well, quite :-) I'm not complaining about the issues here, I'm
suggesting that inventing an extra keyword for the cases discussed in
these DIPs is not necessary, because the analogy and connection with
e
On Wednesday, 18 December 2013 at 20:45:44 UTC, Timon Gehr wrote:
Giving up Eg. ¬(A ∧ B) → ¬A ∨ ¬B is actually a sensible thing
to do in constructive logic.
It is common to give it up in fuzzy logic too, doesn't mean it is
the first thing to throw out.
Anyway, the point in the discussion ab
On 18/12/13 21:11, ilya-stromberg wrote:
Sorry if I miss something, but I don't understand this analogy.
`const` means that original type can be `mutable` or `immutable`, so both
`mutable` and `immutable` types can be implicitly converted to the `const` type.
If I understand DIP correctly, uniq
http://chopapp.com/#fvepfd8 shows the number of dependencies (plus 1)
for each module in phobos. Those include druntime dependencies.
With https://github.com/D-Programming-Language/phobos/pull/1768
dependencies would be generated automatically, which should be a good
step toward reining in.
On 12/18/2013 09:06 PM, "Ola Fosheim Grøstad"
" wrote:
On Wednesday, 18 December 2013 at 19:47:05 UTC, Andrei Alexandrescu wrote:
I don't think so. Algebraic properties have been derived from
desirable and useful properties and have long shown good returns.
No, when you change the foundation/d
On 12/18/2013 08:09 PM, Joseph Rushton Wakeling wrote:
On 18/12/13 19:40, H. S. Teoh wrote:
For this reason, it is better to write 'const' on the right side of the
function name than on the left
Yes, and it's exactly the practice I follow, although Ddoc replaces it
on the left-hand side ... :-
On 12/18/2013 06:33 PM, Joseph Rushton Wakeling wrote:
On 18/12/13 18:20, Timon Gehr wrote:
Well, 'const' attached to a method is simply the notation used for
attaching
'const' to the implicit 'this' parameter.
Sure, but if you see a method:
struct Foo
{
const int bar() { ...
On Wednesday, 18 December 2013 at 19:10:07 UTC, Joseph Rushton
Wakeling wrote:
Well, quite :-) I'm not complaining about the issues here, I'm
suggesting that inventing an extra keyword for the cases
discussed in these DIPs is not necessary, because the analogy
and connection with existing use
On Wednesday, 18 December 2013 at 19:47:05 UTC, Andrei
Alexandrescu wrote:
I don't think so. Algebraic properties have been derived from
desirable and useful properties and have long shown good
returns.
No, when you change the foundation/definitions some of the
theorems will break. That alway
On 12/18/13 10:02 AM, "Ola Fosheim Grøstad" > The trick is to make the
algebra useful for the domain it is used in.
Some properties we are used to from regular real numbers will almost
always break, so you have to decide based on usefulness.
I don't think so. Algebraic properties have been deri
On Wed, Dec 18, 2013 at 08:09:54PM +0100, Joseph Rushton Wakeling wrote:
> On 18/12/13 19:40, H. S. Teoh wrote:
> >For this reason, it is better to write 'const' on the right side of
> >the function name than on the left
>
> Yes, and it's exactly the practice I follow, although Ddoc replaces
> it
On 18/12/13 19:40, H. S. Teoh wrote:
For this reason, it is better to write 'const' on the right side of the
function name than on the left
Yes, and it's exactly the practice I follow, although Ddoc replaces it on the
left-hand side ... :-)
And also to always write `const(int)` rather than
On Wednesday, 18 December 2013 at 17:29:19 UTC, Andrei
Alexandrescu wrote:
There's been a discussion on fast tristate logic recently in
here.
Thanks for the tip. It uses one of the implementations I tested
too, a LUT in a shift register. However, I think I found the
regular lookup-table to be
On Wed, Dec 18, 2013 at 06:33:37PM +0100, Joseph Rushton Wakeling wrote:
> On 18/12/13 18:20, Timon Gehr wrote:
> >Well, 'const' attached to a method is simply the notation used for
> >attaching 'const' to the implicit 'this' parameter.
>
> Sure, but if you see a method:
>
>struct Foo
>{
On Wednesday, 18 December 2013 at 17:29:19 UTC, Andrei
Alexandrescu wrote:
Within the tolerance allowed, they are equal.
No, "a != a" is only false for singeltons ([3,3] etc)
[0,5] < [6,10] => true
[0,5] < [2,10] => uncertain
That would be false.
Interval-arithmetic is used for approximat
On Wednesday, 18 December 2013 at 15:20:39 UTC, Kenji Hara wrote:
I think adding new keyword/attribute just for readability is
overkill.
Kenji Hara
We can use `unique` keyword as unique storage class of variables
in future if we decide that this feature can be useful.
It's not my idea, see
On 18/12/13 18:20, Timon Gehr wrote:
Well, 'const' attached to a method is simply the notation used for attaching
'const' to the implicit 'this' parameter.
Sure, but if you see a method:
struct Foo
{
const int bar() { ... }
}
... the instinctive interpretation of that is "This
On 12/18/13 12:58 AM, "Ola Fosheim Grøstad"
" wrote:
On Wednesday, 18 December 2013 at 02:17:06 UTC, Andrei Alexandrescu wrote:
On 12/17/13 5:58 PM, "Ola Fosheim Grøstad"
" wrote:
Why is that? I would think that 10 == Interval(10,10), but
interval(5,100).contains(10) ?
Yah, defining == my way
On 12/18/2013 05:05 PM, Joseph Rushton Wakeling wrote:
On 18/12/13 16:59, Timon Gehr wrote:
It will be used to annotate a postblit that requires all fields with
indirections to be re-initialized with freshly allocated data instead
of a
postblit that is used during copying of a const object. (The
On 18/12/13 16:59, Timon Gehr wrote:
It will be used to annotate a postblit that requires all fields with
indirections to be re-initialized with freshly allocated data instead of a
postblit that is used during copying of a const object. (There will be no way to
define such a const postblit, becau
On 12/18/2013 04:47 PM, Maxim Fomin wrote:
On Wednesday, 18 December 2013 at 15:29:44 UTC, bearophile wrote:
Kenji Hara:
I think adding new keyword/attribute just for readability is overkill.
Making the code more explicit and easy to understand, using the right
words, is rather important. So
On Wed, Dec 18, 2013 at 03:03:20PM +0100, Craig Dillabaugh wrote:
> On Tuesday, 17 December 2013 at 20:50:23 UTC, H. S. Teoh wrote:
> >On Tue, Dec 17, 2013 at 08:47:17PM +0100, Craig Dillabaugh wrote:
>
> >>Another question is can your queries be batched? If that is the
> >>case and your data is
On Wednesday, 18 December 2013 at 15:29:44 UTC, bearophile wrote:
Kenji Hara:
I think adding new keyword/attribute just for readability is
overkill.
Making the code more explicit and easy to understand, using the
right words, is rather important. So I like @unique, that can
probably be re-u
Kenji Hara:
I think adding new keyword/attribute just for readability is
overkill.
Making the code more explicit and easy to understand, using the
right words, is rather important. So I like @unique, that can
probably be re-uses for another purpose.
What's worse than having many keywords i
I think adding new keyword/attribute just for readability is overkill.
Kenji Hara
2013/12/18 ilya-stromberg
> On Wednesday, 18 December 2013 at 11:10:10 UTC, QAston wrote:
>
>> On Wednesday, 18 December 2013 at 03:42:46 UTC, Kenji Hara wrote:
>>
>>> http://wiki.dlang.org/DIP53
>>> Redesign cur
On Tuesday, 17 December 2013 at 20:50:23 UTC, H. S. Teoh wrote:
On Tue, Dec 17, 2013 at 08:47:17PM +0100, Craig Dillabaugh
wrote:
Another question is can your queries be batched? If that is
the
case and your data is bigger than your available memory, then
try
Googling "Lars Arge Buffer Tree
On Wednesday, 18 December 2013 at 03:42:46 UTC, Kenji Hara wrote:
http://wiki.dlang.org/DIP53
Redesign currently implemented qualified constructor concept.
Thank you very much -- this is going to be really useful.
On Wednesday, 18 December 2013 at 11:10:10 UTC, QAston wrote:
On Wednesday, 18 December 2013 at 03:42:46 UTC, Kenji Hara
wrote:
http://wiki.dlang.org/DIP53
Redesign currently implemented qualified constructor concept.
http://wiki.dlang.org/DIP49
Improved points from version 1:
- Swap meanings o
On Wednesday, 18 December 2013 at 03:42:46 UTC, Kenji Hara wrote:
http://wiki.dlang.org/DIP53
Redesign currently implemented qualified constructor concept.
http://wiki.dlang.org/DIP49
Improved points from version 1:
- Swap meanings of 'this(this) inout' and 'this(this) const'
- Inout postblit no
"Jerry" wrote in message
news:87r49bzawu@optonline.net...
Manu writes:
On 13 December 2013 19:31, John Colvin
wrote:
I've experienced the same slowing effect I mentioned before in this
context
too.
Have you ever trying playing with a delay AND an uncomfortably high
latency?
Since yo
On Wednesday, 18 December 2013 at 08:58:07 UTC, Ola Fosheim
Grøstad wrote:
[1,5] != [1,5] => false? // counter-intuitive
(a bit unclear there, [1,5]!=[1,5] is uncertain/true, but not
false which we might first assume)
On Wednesday, 18 December 2013 at 02:17:06 UTC, Andrei
Alexandrescu wrote:
On 12/17/13 5:58 PM, "Ola Fosheim Grøstad"
" wrote:
Why is that? I would think that 10 == Interval(10,10), but
interval(5,100).contains(10) ?
Yah, defining == my way would make it non-transitive.
True interval arithme
53 matches
Mail list logo
