Lionello Lunesu Wrote:
> On 31-1-2010 16:34, Simen kjaeraas wrote:
> > Lionello Lunesu wrote:
> >
> >> I miss typedef. I think this is exactly what typedef was intended
> >> for. Perhaps we can reintroduce it as a 'short hand' for such a
> >> struct?
> >
> > struct Typedef( T ) {
> > T payloa
On 31-1-2010 16:34, Simen kjaeraas wrote:
> Lionello Lunesu wrote:
>
>> I miss typedef. I think this is exactly what typedef was intended
>> for. Perhaps we can reintroduce it as a 'short hand' for such a
>> struct?
>
> struct Typedef( T ) {
> T payload;
> alias payload this;
> }
>
> Usage:
On Sun, 31 Jan 2010 15:09:28 +0100, Denis Koroskin <2kor...@gmail.com>
wrote:
On Sun, 31 Jan 2010 01:30:41 +0300, Simen kjaeraas
wrote:
Andrei Alexandrescu wrote:
bearophile wrote:
I can't remember the bit size of wchar and dchar. So names like char,
char16 and char32 can be better..
On Sun, 31 Jan 2010 11:34:03 +0300, Simen kjaeraas
wrote:
Lionello Lunesu wrote:
I miss typedef. I think this is exactly what typedef was intended
for. Perhaps we can reintroduce it as a 'short hand' for such a
struct?
struct Typedef( T ) {
T payload;
alias payload this;
}
Usage:
On Sun, 31 Jan 2010 01:30:41 +0300, Simen kjaeraas
wrote:
Andrei Alexandrescu wrote:
bearophile wrote:
I can't remember the bit size of wchar and dchar. So names like char,
char16 and char32 can be better...
I think it's a tad late for that.
So adding aliases to object.d is not possi
Lionello Lunesu wrote:
I miss typedef. I think this is exactly what typedef was intended
for. Perhaps we can reintroduce it as a 'short hand' for such a
struct?
struct Typedef( T ) {
T payload;
alias payload this;
}
Usage:
alias Typedef!( int ) myInt;
Is this what you want?
By the wa
On 2010-01-30 22:06:06 -0500, Lionello Lunesu said:
On 30-1-2010 1:59, Andrei Alexandrescu wrote:
bearophile wrote:
Andrei Alexandrescu:
Currently arrays of characters count as random-access ranges, which
is not true for arrays of char and wchar. I plan to make std.range
aware of that and on
On 30-1-2010 1:59, Andrei Alexandrescu wrote:
> bearophile wrote:
>> Andrei Alexandrescu:
>>> Currently arrays of characters count as random-access ranges, which
>>> is not true for arrays of char and wchar. I plan to make std.range
>>> aware of that and only characterize char[] and wchar[] (and th
Simen kjaeraas wrote:
Andrei Alexandrescu wrote:
bearophile wrote:
I can't remember the bit size of wchar and dchar. So names like char,
char16 and char32 can be better...
I think it's a tad late for that.
So adding aliases to object.d is not possible this late in the process?
I'm not sur
Andrei Alexandrescu wrote:
bearophile wrote:
I can't remember the bit size of wchar and dchar. So names like char,
char16 and char32 can be better...
I think it's a tad late for that.
So adding aliases to object.d is not possible this late in the process?
I'm not sure I want that to happe
Robert Jacques wrote:
On Fri, 29 Jan 2010 15:18:14 -0500, Andrei Alexandrescu
wrote:
Lutger wrote:
On 01/29/2010 06:36 PM, Andrei Alexandrescu wrote:
...
One problem I foresee is the growth of std.algorithm. It already has
many things in it, and I fear that some user who just wants to trim
On Fri, 29 Jan 2010 15:18:14 -0500, Andrei Alexandrescu
wrote:
Lutger wrote:
On 01/29/2010 06:36 PM, Andrei Alexandrescu wrote:
...
One problem I foresee is the growth of std.algorithm. It already has
many things in it, and I fear that some user who just wants to trim a
string may find it i
dsimcha wrote:
> == Quote from Jacob Carlborg (d...@me.com)'s article
>> Perhaps it's time to start adding more packages than just the std. Make
>> std.algorithm a package and try to split it into several modules.
>
> Please, no. I **HATE** fine-grained imports like Tango has. I don't want
> to
Ali Çehreli wrote:
D is great that it supports three separate Unicode encodings in the
language, but encodings are at a lower level of abstraction than
"letters". I am not sure what data is used for toUniUpper and toUniLower
in std.uni, but they can't work correctly without alphabet information
Jacob Carlborg wrote:
> On 1/29/10 22:18, Ali Çehreli wrote:
>> Jacob Carlborg wrote:
>>
>> > I would keep std.string for string specific functions and perhaps
>> > publicly import std.algorithm. For exmaple functions like: tolower,
>> icmp
>> > and toStringz.
>>
>> I've been thinking about cha
On 1/29/10 22:18, Ali Çehreli wrote:
Jacob Carlborg wrote:
> I would keep std.string for string specific functions and perhaps
> publicly import std.algorithm. For exmaple functions like: tolower, icmp
> and toStringz.
I've been thinking about characters lately and have realized that
tolower
Andrei Alexandrescu:
> // in client code
> // get everything tagged with "string"
> import std.algorithm : @tag(string);
A next step is to allow to import all names with a specified tag, even if such
names are inside more than one text file (the compiler can create a json txt
file to speed up t
== Quote from Jacob Carlborg (d...@me.com)'s article
> Perhaps it's time to start adding more packages than just the std. Make
> std.algorithm a package and try to split it into several modules.
Please, no. I **HATE** fine-grained imports like Tango has. I don't want to
write tons of boilerplate
Ali Çehreli wrote:
Jacob Carlborg wrote:
> I would keep std.string for string specific functions and perhaps
> publicly import std.algorithm. For exmaple functions like: tolower, icmp
> and toStringz.
I've been thinking about characters lately and have realized that
tolower, toupper, icmp,
Lutger wrote:
On 01/29/2010 09:43 PM, bearophile wrote:
Andrei Alexandrescu:
I think the idea of tags is awesome, particularly because it doesn't
require one to divide items in disjoint sets. I'll think some more of
it.
A hierarchical D/Python-like module system isn't the only way to
organi
Jacob Carlborg wrote:
> I would keep std.string for string specific functions and perhaps
> publicly import std.algorithm. For exmaple functions like: tolower, icmp
> and toStringz.
I've been thinking about characters lately and have realized that
tolower, toupper, icmp, and friends should not
On 01/29/2010 09:43 PM, bearophile wrote:
Andrei Alexandrescu:
I think the idea of tags is awesome, particularly because it doesn't
require one to divide items in disjoint sets. I'll think some more of it.
A hierarchical D/Python-like module system isn't the only way to organize
blocks of cod
Andrei Alexandrescu:
> I think the idea of tags is awesome, particularly because it doesn't
> require one to divide items in disjoint sets. I'll think some more of it.
A hierarchical D/Python-like module system isn't the only way to organize
blocks of code. Both future Windows file system and Go
On 01/29/2010 09:18 PM, Andrei Alexandrescu wrote:
Lutger wrote:
On 01/29/2010 06:36 PM, Andrei Alexandrescu wrote:
...
One problem I foresee is the growth of std.algorithm. It already has
many things in it, and I fear that some user who just wants to trim a
string may find it intimidating to b
Lutger wrote:
On 01/29/2010 06:36 PM, Andrei Alexandrescu wrote:
...
One problem I foresee is the growth of std.algorithm. It already has
many things in it, and I fear that some user who just wants to trim a
string may find it intimidating to browse through all that
documentation. I wonder how w
On 01/29/2010 09:13 PM, Lutger wrote:
http://www.naturaldocs.org/documenting/reference.html#Example_Class
sorry, wrong anchor:
http://www.naturaldocs.org/documenting/reference.html#Summaries
On 01/29/2010 06:36 PM, Andrei Alexandrescu wrote:
...
One problem I foresee is the growth of std.algorithm. It already has
many things in it, and I fear that some user who just wants to trim a
string may find it intimidating to browse through all that
documentation. I wonder how we could break s
On 1/29/10 18:36, Andrei Alexandrescu wrote:
I plan a few improvements to Phobos that will improve string handling.
Currently arrays of characters count as random-access ranges, which is
not true for arrays of char and wchar. I plan to make std.range aware of
that and only characterize char[] an
bearophile wrote:
Andrei Alexandrescu:
Currently arrays of characters count as random-access ranges, which is
not true for arrays of char and wchar. I plan to make std.range aware of
that and only characterize char[] and wchar[] (and their qualified
versions) as bidirectional ranges.
32 bits
Andrei Alexandrescu:
> Currently arrays of characters count as random-access ranges, which is
> not true for arrays of char and wchar. I plan to make std.range aware of
> that and only characterize char[] and wchar[] (and their qualified
> versions) as bidirectional ranges.
32 bits are not enou
I plan a few improvements to Phobos that will improve string handling.
Currently arrays of characters count as random-access ranges, which is
not true for arrays of char and wchar. I plan to make std.range aware of
that and only characterize char[] and wchar[] (and their qualified
versions) as
31 matches
Mail list logo
