On Monday, 24 September 2012 at 05:45:11 UTC, H. S. Teoh wrote:
On Sat, Sep 22, 2012 at 03:48:49AM -0400, Nick Sabalausky wrote:
On Fri, 21 Sep 2012 15:37:46 -0700
"H. S. Teoh" wrote:
>
> The sad part is that so many of the commenters have no idea
> that
> adjacent C literals are concatenated
On Sat, Sep 22, 2012 at 03:48:49AM -0400, Nick Sabalausky wrote:
> On Fri, 21 Sep 2012 15:37:46 -0700
> "H. S. Teoh" wrote:
> >
> > The sad part is that so many of the commenters have no idea that
> > adjacent C literals are concatenated at compile-time. It's a very
> > nice way to put long strin
Glad to hear that comma operator won't be depreciated.
On Sun, 23 Sep 2012 18:48:22 -0400
Andrei Alexandrescu wrote:
>
> Once a one-element tuple becomes equivalent to the actual item,
> there's an explosion of trouble and special cases in the language and
> in code that uses it. For example, divide and conquer code that
> manipulates tuples and take
On Sun, Sep 23, 2012 at 11:45 PM, Ben Davis wrote:
> Actually I stole the {} from Nick's suggestion. My suggestion was using a
> mixin template instead of a string mixin, making it harder to screw up
> invoking the mixin :)
Ah, OK :) I actually just skimmed the entire thread :) I think self
shou
On Sun, 23 Sep 2012 21:30:08 -0700
"H. S. Teoh" wrote:
> On Sun, Sep 23, 2012 at 04:40:34PM -0400, Andrei Alexandrescu wrote:
> > I discussed this with Walter, and we concluded that we could
> > deprecate the comma operator if it helps tuples. So I started with
> > this:
> >
> > http://www.prowi
On Sun, Sep 23, 2012 at 04:40:34PM -0400, Andrei Alexandrescu wrote:
> I discussed this with Walter, and we concluded that we could
> deprecate the comma operator if it helps tuples. So I started with
> this:
>
> http://www.prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP19
+1 to getting rid of
On 9/23/12 10:15 PM, Timon Gehr wrote:
On 09/24/2012 03:14 AM, Andrei Alexandrescu wrote:
On 9/23/12 7:20 PM, Adam D. Ruppe wrote:
On Sunday, 23 September 2012 at 22:55:33 UTC, Timon Gehr wrote:
I believe it is currently left-to-right for D, in all kinds of
expressions, but DMD does not implem
On 9/23/12 9:31 PM, deadalnix wrote:
Le 24/09/2012 03:14, Andrei Alexandrescu a écrit :
On 9/23/12 7:20 PM, Adam D. Ruppe wrote:
On Sunday, 23 September 2012 at 22:55:33 UTC, Timon Gehr wrote:
I believe it is currently left-to-right for D, in all kinds of
expressions, but DMD does not implemen
On 9/23/12 9:27 PM, deadalnix wrote:
I understand the trouble here. But why divide and conquer is preferable
here over a static foreach over the tuple ?
There are fewer data dependencies, which results on faster execution on
today's CPUs.
Andrei
On 09/24/2012 04:27 AM, Timon Gehr wrote:
On 09/24/2012 03:41 AM, Jonathan M Davis wrote:
On Monday, September 24, 2012 03:31:08 deadalnix wrote:
Le 24/09/2012 03:14, Andrei Alexandrescu a écrit :
On 9/23/12 7:20 PM, Adam D. Ruppe wrote:
On Sunday, 23 September 2012 at 22:55:33 UTC, Timon Geh
On 09/24/2012 03:41 AM, Jonathan M Davis wrote:
On Monday, September 24, 2012 03:31:08 deadalnix wrote:
Le 24/09/2012 03:14, Andrei Alexandrescu a écrit :
On 9/23/12 7:20 PM, Adam D. Ruppe wrote:
On Sunday, 23 September 2012 at 22:55:33 UTC, Timon Gehr wrote:
I believe it is currently left-to
On 09/24/2012 03:14 AM, Andrei Alexandrescu wrote:
On 9/23/12 7:20 PM, Adam D. Ruppe wrote:
On Sunday, 23 September 2012 at 22:55:33 UTC, Timon Gehr wrote:
I believe it is currently left-to-right for D, in all kinds of
expressions, but DMD does not implement it yet.
Yeah, I thought it was alr
On Monday, September 24, 2012 03:31:08 deadalnix wrote:
> Le 24/09/2012 03:14, Andrei Alexandrescu a écrit :
> > On 9/23/12 7:20 PM, Adam D. Ruppe wrote:
> >> On Sunday, 23 September 2012 at 22:55:33 UTC, Timon Gehr wrote:
> >>> I believe it is currently left-to-right for D, in all kinds of
> >>> e
Le 24/09/2012 02:44, Timon Gehr a écrit :
The motivation for having these conversions was syntactic ambiguity.
If there is none, just do it like this:
(create_tuple,)
get_value[0]
As I answered to Andrei, my motivation isn't related to syntax
ambiguity, and I actually don't care what the syn
Le 24/09/2012 03:14, Andrei Alexandrescu a écrit :
On 9/23/12 7:20 PM, Adam D. Ruppe wrote:
On Sunday, 23 September 2012 at 22:55:33 UTC, Timon Gehr wrote:
I believe it is currently left-to-right for D, in all kinds of
expressions, but DMD does not implement it yet.
Yeah, I thought it was alr
Le 24/09/2012 03:14, Andrei Alexandrescu a écrit :
On 9/23/12 7:08 PM, deadalnix wrote:
Le 24/09/2012 00:48, Andrei Alexandrescu a écrit :
This notion a lot of trouble with it; I think it's safe to abandon it
entirely.
Once a one-element tuple becomes equivalent to the actual item, there's
an
On 9/23/12 7:20 PM, Adam D. Ruppe wrote:
On Sunday, 23 September 2012 at 22:55:33 UTC, Timon Gehr wrote:
I believe it is currently left-to-right for D, in all kinds of
expressions, but DMD does not implement it yet.
Yeah, I thought it was already defined.
Actually it's right to left for assi
On 9/23/12 7:08 PM, deadalnix wrote:
Le 24/09/2012 00:48, Andrei Alexandrescu a écrit :
This notion a lot of trouble with it; I think it's safe to abandon it
entirely.
Once a one-element tuple becomes equivalent to the actual item, there's
an explosion of trouble and special cases in the langua
On 09/24/2012 02:28 AM, deadalnix wrote:
Le 24/09/2012 02:21, Timon Gehr a écrit :
On 09/24/2012 02:00 AM, deadalnix wrote:
Le 24/09/2012 01:28, Timon Gehr a écrit :
I agree with Andrei. Single element tuples need to support the same
operations as tuples of other arities do.
Obviously it sho
Le 24/09/2012 02:21, Timon Gehr a écrit :
On 09/24/2012 02:00 AM, deadalnix wrote:
Le 24/09/2012 01:28, Timon Gehr a écrit :
I agree with Andrei. Single element tuples need to support the same
operations as tuples of other arities do.
Obviously it should. The whole point is that you can impli
On 09/24/2012 02:00 AM, deadalnix wrote:
Le 24/09/2012 01:28, Timon Gehr a écrit :
I agree with Andrei. Single element tuples need to support the same
operations as tuples of other arities do.
Obviously it should. The whole point is that you can implicitly cast a 1
element tuple into the eleme
Le 24/09/2012 01:34, bearophile a écrit :
Andrei Alexandrescu:
The interesting thing about this is that, if we decide it's the main
issue with today's tuples, we pull Kenji's patch and close the case.
As I have tried to explain in my precedent post, Kenji's patch covers
about 1/4 of the most
Le 24/09/2012 01:23, Timon Gehr a écrit :
I assume named tuple fields are not a problem?
I'm not sure it is really usefull.
Other than that, I raised the issue of how to match and destructure
tuple types in template parameter lists. And came up with the following
proposal, which I do not like
Le 24/09/2012 01:28, Timon Gehr a écrit :
I agree with Andrei. Single element tuples need to support the same
operations as tuples of other arities do.
Obviously it should. The whole point is that you can implicitly cast a 1
element tuple into the element and vice versa.
like :
(int) a = (3)
Timon Gehr:
Switch is syntax sugar for jump tables. An adequate pattern
matching
construct would not require explicit control flow statements,
and it would be an expression of arbitrary type.
Introducing a good pattern matching syntax in D requires the
introduction of a good amount of comple
On 09/24/2012 01:36 AM, bearophile wrote:
Timon Gehr:
cases already introduce their own scopes in D,
Thank you, I didn't remember this.
but switch cannot be extended well to serve such use cases.
Please explain, as I am not able to see the problems.
Switch is syntax sugar for jump tab
Timon Gehr:
cases already introduce their own scopes in D,
Thank you, I didn't remember this.
but switch cannot be extended well to serve such use cases.
Please explain, as I am not able to see the problems.
I have discussed that topic a little here:
http://d.puremagic.com/issues/show_bu
Andrei Alexandrescu:
The interesting thing about this is that, if we decide it's the
main issue with today's tuples, we pull Kenji's patch and close
the case.
As I have tried to explain in my precedent post, Kenji's patch
covers about 1/4 of the most important use cases.
Bye,
bearophile
On 09/24/2012 01:08 AM, deadalnix wrote:
Le 24/09/2012 00:48, Andrei Alexandrescu a écrit :
This notion a lot of trouble with it; I think it's safe to abandon it
entirely.
Once a one-element tuple becomes equivalent to the actual item, there's
an explosion of trouble and special cases in the la
On 09/24/2012 12:57 AM, Andrei Alexandrescu wrote:
On 9/23/12 6:42 PM, Timon Gehr wrote:
That is because it does not base the discussion on the right
limitations of built-in tuples:
Actually that is mostly unrelated to the comma operator. Apologies.
auto (a,b) = (1,"3");
(auto a, string b)
On Sunday, 23 September 2012 at 22:55:33 UTC, Timon Gehr wrote:
I believe it is currently left-to-right for D, in all kinds of
expressions, but DMD does not implement it yet.
Yeah, I thought it was already defined.
Le 24/09/2012 00:48, Andrei Alexandrescu a écrit :
This notion a lot of trouble with it; I think it's safe to abandon it
entirely.
Once a one-element tuple becomes equivalent to the actual item, there's
an explosion of trouble and special cases in the language and in code
that uses it. For examp
On 9/23/12 6:42 PM, Timon Gehr wrote:
That is because it does not base the discussion on the right
limitations of built-in tuples:
auto (a,b) = (1,"3");
(auto a, string b) = (1, "3");
I meant to mention that but forgot. The interesting thing about this is
that, if we decide it's the main issu
On 09/24/2012 12:40 AM, Jonathan M Davis wrote:
On Monday, September 24, 2012 00:30:27 jerro wrote:
If D is like C in this regard, then the function above cannot
replace comma operator, because the order of evaluation is
defined for comma operator, but not for function parameters.
I believe th
On 09/24/2012 12:11 AM, bearophile wrote:
...
Second: removing comma operator from D has some advantages unrelated to
tuple syntax. Even disallowing bad looking C-like code that uses commas
is an improvement by itself (but maybe it's not a big enough
improvement...).
I would think that it isn'
On 9/23/12 5:57 PM, deadalnix wrote:
Le 23/09/2012 23:52, Nick Sabalausky a écrit :
Ok, here's a crazy idea:
Do the reasons for explicit tuple-expansion necessarily apply to
zero- and one-element tuples? I'm not so sure. Suppose we allowed
implicit expansion on those...
Now I know what you're
On 09/23/2012 10:40 PM, Andrei Alexandrescu wrote:
I discussed this with Walter, and we concluded that we could deprecate
the comma operator if it helps tuples. So I started with this:
http://www.prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP19
Unfortunately, I started much cockier than I e
On Monday, September 24, 2012 00:30:27 jerro wrote:
> If D is like C in this regard, then the function above cannot
> replace comma operator, because the order of evaluation is
> defined for comma operator, but not for function parameters.
I believe that it's currently undefined for D, but Walter
On Sunday, 23 September 2012 at 21:37:06 UTC, Adam D. Ruppe wrote:
I'm not for removing the comma operator, but it occurs to me we
could do it in the library:
auto commaOperatorReplacement(T...)(T t) {
return t[$-1];
}
There might be some edge case where that wouldn't work, but I
think it
On Sunday, 23 September 2012 at 22:29:31 UTC, jerro wrote:
On Sunday, 23 September 2012 at 21:37:06 UTC, Adam D. Ruppe
wrote:
I'm not for removing the comma operator, but it occurs to me
we could do it in the library:
auto commaOperatorReplacement(T...)(T t) {
return t[$-1];
}
There might b
On Sunday, 23 September 2012 at 20:49:54 UTC, Nick Sabalausky
wrote:
On Sun, 23 Sep 2012 19:08:16 +0200
"Paulo Pinto" wrote:
On Sunday, 23 September 2012 at 16:14:33 UTC, Jonas Drewsen
wrote:
> On Sunday, 23 September 2012 at 15:06:51 UTC, Paulo Pinto
> wrote:
>> Since this is one area where
This is a complex topic, and in this post I am not able to
discuss everything that needs to be discussed. So I will discuss
only part of the story.
First: tuples are important enough. I think they should be
built-in in a modern language, but maybe having them as
half-built-in will be enough i
Le 23/09/2012 23:52, Nick Sabalausky a écrit :
Ok, here's a crazy idea:
Do the reasons for explicit tuple-expansion necessarily apply to
zero- and one-element tuples? I'm not so sure. Suppose we allowed
implicit expansion on those...
Now I know what you're thinking: That would be an ugly incons
Ok, here's a crazy idea:
Do the reasons for explicit tuple-expansion necessarily apply to
zero- and one-element tuples? I'm not so sure. Suppose we allowed
implicit expansion on those...
Now I know what you're thinking: That would be an ugly inconsistency
between tuples of sizes >1 vs <=1. Well,
On 23/09/2012 20:58, Philippe Sigaud wrote:
On Sun, Sep 23, 2012 at 7:16 PM, Ben Davis wrote:
Here's another one that might work, and be less error-prone:
mixin template Self() {
auto self = __traits(identifier, __traits(parent, {}));
}
void test() {
mixin Self;
writeln(self);
}
O
On 09/23/2012 10:58 PM, foobar wrote:
On Sunday, 23 September 2012 at 20:39:38 UTC, Andrei Alexandrescu wrote:
I discussed this with Walter, and we concluded that we could deprecate
the comma operator if it helps tuples. So I started with this:
http://www.prowiki.org/wiki4d/wiki.cgi?LanguageDev
I'm not for removing the comma operator, but it occurs to me we
could do it in the library:
auto commaOperatorReplacement(T...)(T t) {
return t[$-1];
}
There might be some edge case where that wouldn't work, but I
think it works in most cases.
Le 23/09/2012 22:40, Andrei Alexandrescu a écrit :
I discussed this with Walter, and we concluded that we could deprecate
the comma operator if it helps tuples. So I started with this:
http://www.prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP19
Unfortunately, I started much cockier than I e
On Sunday, 23 September 2012 at 21:00:39 UTC, foobar wrote:
On Sunday, 23 September 2012 at 20:57:48 UTC, foobar wrote:
On Sunday, 23 September 2012 at 20:39:38 UTC, Andrei
Alexandrescu wrote:
I discussed this with Walter, and we concluded that we could
deprecate the comma operator if it helps
On Sunday, 23 September 2012 at 20:57:48 UTC, foobar wrote:
On Sunday, 23 September 2012 at 20:39:38 UTC, Andrei
Alexandrescu wrote:
I discussed this with Walter, and we concluded that we could
deprecate the comma operator if it helps tuples. So I started
with this:
http://www.prowiki.org/wik
On 9/23/12, Andrei Alexandrescu wrote:
> I discussed this with Walter, and we concluded that we could deprecate
> the comma operator if it helps tuples. So I started with this:
>
> http://www.prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP19
About the (,) problem, what about using (void)? It's
On Sunday, 23 September 2012 at 20:39:38 UTC, Andrei Alexandrescu
wrote:
I discussed this with Walter, and we concluded that we could
deprecate the comma operator if it helps tuples. So I started
with this:
http://www.prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP19
Unfortunately, I start
On Sun, 23 Sep 2012 19:08:16 +0200
"Paulo Pinto" wrote:
> On Sunday, 23 September 2012 at 16:14:33 UTC, Jonas Drewsen wrote:
> > On Sunday, 23 September 2012 at 15:06:51 UTC, Paulo Pinto wrote:
> >> Since this is one area where D could eventually replace C++,
> >> I've decided to post it here.
>
I discussed this with Walter, and we concluded that we could deprecate
the comma operator if it helps tuples. So I started with this:
http://www.prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP19
Unfortunately, I started much cockier than I ended. The analysis in
there fails to construct a c
On Sun, Sep 23, 2012 at 7:16 PM, Ben Davis wrote:
> Here's another one that might work, and be less error-prone:
>
> mixin template Self() {
> auto self = __traits(identifier, __traits(parent, {}));
> }
>
> void test() {
> mixin Self;
> writeln(self);
>
> }
Oh, you're using {} as a local bl
On 09/23/2012 07:37 PM, Andrej Mitrovic wrote:
On 9/7/12, Kevin McTaggart wrote:
snip
There's one thing nobody mentioned yet, and that is that we're already
using this syntax in the language -- in foreach loops:
struct Foo { int x; }
Foo[] arr = [{4}, {5}, {6}];
foreach (idx, ref val; arr)
On Sunday, 23 September 2012 at 18:43:08 UTC, bearophile wrote:
foreach (idx, val; arr)
{
val.x = idx; // clearly a bug, but lacks warning
}
I've had *numerous* occasions over the last few years where
I've had this bug happen to me.
The same for me. Most people seem to not care for this p
On 9/20/2012 1:08 PM, Jonas Drewsen wrote:
On Thursday, 20 September 2012 at 18:03:18 UTC, David Nadlinger wrote:
On Thursday, 20 September 2012 at 17:26:25 UTC, Joseph Rushton Wakeling wrote:
Some rather urgent news: LDC has just been blacklisted in Ubuntu.
It would be great if somebody from
Andrej Mitrovic:
However I'd like to see a custom compiler warning switch that
would
warn me if I tried to call opAssign on a fundamental or struct
type in
a foreach loop with a non-ref foreach parameter:
foreach (idx, val; arr)
{
val.x = idx; // clearly a bug, but lacks warning
}
I've
Andrej Mitrovic:
However I'd like to see a custom compiler warning switch that
would
warn me if I tried to call opAssign on a fundamental or struct
type in
a foreach loop with a non-ref foreach parameter:
foreach (idx, val; arr)
{
val.x = idx; // clearly a bug, but lacks warning
}
I've
Al 23/09/12 19:57, En/na Jason Spencer ha escrit:
> On Sunday, 23 September 2012 at 14:16:45 UTC, Jordi Sayol wrote:
[...]
> 0 upgraded, 0 newly installed, 0 to remove and 61 not upgraded.
>
first of all, upgrade your system
$ sudo apt-get update
$ sudo apt-get dist-upgrade
>
> jason ~/Downloa
On Sunday, 23 September 2012 at 14:16:45 UTC, Jordi Sayol wrote:
to install dmd2 on LinuxMint:
$ sudo gdebi dmd_2.060-0_amd64.deb
Even gdebi's not happy. I removed dmd:i386 and started fresh.
Here's a transcript:
jason ~/Downloads $ sudo apt-get install -f
Reading package l
On 9/23/12, correspondent wrote:
> This win API call generates fatal error. Is there a fix?
The gdi32.lib import library DMD distributes is outdated. You can use
this one: https://github.com/AndrejMitrovic/DWinProgramming/raw/master/gdi32.lib
Pass it to DMD's command line when compiling.
There'
On 9/7/12, Kevin McTaggart wrote:
> snip
There's one thing nobody mentioned yet, and that is that we're already
using this syntax in the language -- in foreach loops:
struct Foo { int x; }
Foo[] arr = [{4}, {5}, {6}];
foreach (idx, ref val; arr)
{
val.x = idx;
}
However I'd like to see a c
This win API call generates fatal error. Is there a fix?
Here's another one that might work, and be less error-prone:
mixin template Self() {
auto self = __traits(identifier, __traits(parent, {}));
}
void test() {
mixin Self;
writeln(self);
}
On 23/09/2012 09:58, Rob T wrote:
string scopeName()
{
return q{__traits(identifier, __traits(pare
On Sunday, 23 September 2012 at 16:14:33 UTC, Jonas Drewsen wrote:
On Sunday, 23 September 2012 at 15:06:51 UTC, Paulo Pinto wrote:
Since this is one area where D could eventually replace C++,
I've decided to post it here.
So after Sony decided to make use of C#/Mono for the PS Vita
SDK, Nint
On Sunday, 23 September 2012 at 15:06:51 UTC, Paulo Pinto wrote:
Since this is one area where D could eventually replace C++,
I've decided to post it here.
So after Sony decided to make use of C#/Mono for the PS Vita
SDK, Nintendo has decided to do the same by supporting Unity
for the new Wii
Since this is one area where D could eventually replace C++, I've
decided to post it here.
So after Sony decided to make use of C#/Mono for the PS Vita SDK,
Nintendo has decided to do the same by supporting Unity for the
new Wii U.
http://www.marketwire.com/press-release/unity-technologies-e
Jacob Carlborg wrote:
> On 2012-09-22 19:43, Jens Mueller wrote:
>
> >What does it mean to make no distinction in RSpec?
> >Both should be reported. In D you just see either an AssertError or
> >SomeException.
>
> Test-unit would report something like this:
>
> 5 tests, 2 failures, 1 error
>
>
On 2012-09-22 19:43, Jens Mueller wrote:
What does it mean to make no distinction in RSpec?
Both should be reported. In D you just see either an AssertError or
SomeException.
Test-unit would report something like this:
5 tests, 2 failures, 1 error
Failures would be asserts that triggered, er
Al 23/09/12 07:38, En/na Jason Spencer ha escrit:
> Though Mint 13 is very similar to ubuntu 12, I cannot seem to get the deb
> package to install. I get dependency errors on gcc, gcc-mulitlib, and
> xdg-utils. apt-get assures me these are all the latest version. Still, dpkg
> won't install d
On 22/09/12 07:10, Nick Sabalausky wrote:
I think this entire discussion serves as evidence that, at the very
least, it needs to communicate that scope/methodology/rationale better
that it currently does. If all of us are having trouble "getting it",
then others certainly will too.
My feeling i
On 22/09/12 11:13, Russel Winder wrote:
Perhaps even better talk with the Debian people to find a route into the
Debian repository, which then automatically gets to be part of Ubuntu
and Mint.
In the bigger picture yes, but as in this case it's Ubuntu that's blacklisted
the package, probably b
string scopeName()
{
return q{__traits(identifier, __traits(parent, {}))};
}
void main()
{
writeln(mixin(scopeName()));
}
That should be quite usable, except if the user forgets the
mixin() part - unfortunately that potential bug seems to be
statically undetectable.
Thanks, for comm
76 matches
Mail list logo
