On Fri, 11 Mar 2016 14:29:39 +, Marc Schütz wrote:
>> 0 "Inside tuple literal, ; never appears."
>> {{;}} // a tuple not matching your specification
>> {{if(foo()){}}} // a non-tuple matching your specification
>
> This is not a serious problem, because it just means that the
On Friday, 11 March 2016 at 13:26:49 UTC, Meta wrote:
On Thursday, 10 March 2016 at 19:36:05 UTC, ZombineDev wrote:
On Monday, 7 March 2016 at 18:21:24 UTC, Meta wrote:
[...]
Can you find the exact case? I'm really interested in getting
proper tuple syntax support and I think that's
On Friday, 11 March 2016 at 13:26:49 UTC, Meta wrote:
On Thursday, 10 March 2016 at 19:36:05 UTC, ZombineDev wrote:
On Monday, 7 March 2016 at 18:21:24 UTC, Meta wrote:
Unfortunately this will not work. There was a tuple proposal
sometime back in 2012 or 2013. I can't remember the exact
On Thursday, 10 March 2016 at 19:36:05 UTC, ZombineDev wrote:
On Monday, 7 March 2016 at 18:21:24 UTC, Meta wrote:
On Monday, 7 March 2016 at 10:40:15 UTC, ZombineDev wrote:
Which I don't think will cause ambiguity with delegates:
auto tuple3 = { getInt() }; tuple
auto tuple3 = { getInt(); };
On Friday, 11 March 2016 at 05:09:44 UTC, Chris Wright wrote:
On Thu, 10 Mar 2016 19:01:53 +, ZombineDev wrote:
On Monday, 7 March 2016 at 19:06:54 UTC, Chris Wright wrote:
On Mon, 07 Mar 2016 11:06:13 +, ZombineDev wrote:
The compiler should detect that this call is ambiguous and
On Thu, 10 Mar 2016 19:01:53 +, ZombineDev wrote:
> On Monday, 7 March 2016 at 19:06:54 UTC, Chris Wright wrote:
>> On Mon, 07 Mar 2016 11:06:13 +, ZombineDev wrote:
>>> The compiler should detect that this call is ambiguous and would not
>>> allow it.
>>
>> It's a potentially significant
On Monday, 7 March 2016 at 18:21:24 UTC, Meta wrote:
On Monday, 7 March 2016 at 10:40:15 UTC, ZombineDev wrote:
Which I don't think will cause ambiguity with delegates:
auto tuple3 = { getInt() }; tuple
auto tuple3 = { getInt(); }; lambda
Unfortunately this will not work. There was a tuple
On Monday, 7 March 2016 at 19:06:54 UTC, Chris Wright wrote:
On Mon, 07 Mar 2016 11:06:13 +, ZombineDev wrote:
The compiler should detect that this call is ambiguous and
would not allow it.
It's a potentially significant amount of work to determine that
the expression is ambiguous, or to
On Tuesday, 8 March 2016 at 20:32:02 UTC, Idan Arye wrote:
Declaring the named arguments variadically will be done by
adding `...` after a struct argument:
struct Options{int x; int y=1; int z=2;}
auto fun(Options options ...)
We'll need a syntax for specifying the arguments - but
On Thursday, 10 March 2016 at 05:17:03 UTC, Michael Coulombe
wrote:
[...]
Whoops, forgot this:
private immutable struct KeyWordDollar {
@property
auto opDispatch(string param, T)(T t) {
return Named!(param,T)(t);
}
}
On Wednesday, 9 March 2016 at 12:55:16 UTC, Idan Arye wrote:
Allowing something like `auto params = [:y : 50, :x : 100]`
won't really solve anything. It works nicely in Ruby, because
Ruby has dynamic typing and with some syntactic sugar you get
elegant syntax for dynamic structs. But in a
On Wednesday, 9 March 2016 at 07:30:31 UTC, Edwin van Leeuwen
wrote:
On Sunday, 6 March 2016 at 17:35:38 UTC, Seb wrote:
[...]
In ggplotd I often use named tuples as and "anonymoous" struct:
Tuple!(double,"x")( 0.0 )
I also added a merge function that will return a tuple
containing merged
On Wednesday, 9 March 2016 at 13:39:57 UTC, Martin Tschierschke
wrote:
On Wednesday, 9 March 2016 at 12:55:16 UTC, Idan Arye wrote:
[...]
[...]
[...]
Thats true.
[...]
Yes.Ok.
What I like about the :symbol notation is, that a string witch
is used
only to distinguish between different
On Wednesday, 9 March 2016 at 12:55:16 UTC, Idan Arye wrote:
[...]
An other point on my wish list would be to allow string symbol
notation
like in ruby. Than using hashes (AA) for parameters gets more
convenient:
:symbol <= just short for => "symbol"
h[:y]= 50; h[:x] = 100; // <=> h["y"] =
On Wednesday, 9 March 2016 at 10:06:25 UTC, Martin Tschierschke
wrote:
On Tuesday, 8 March 2016 at 18:46:02 UTC, Chris Wright wrote:
On Tue, 08 Mar 2016 13:52:09 +, Martin Tschierschke wrote:
What about this idea? A new word "as" or something similar.
fun(ypos as y, xpos as x, radius as
On Tuesday, 8 March 2016 at 18:46:02 UTC, Chris Wright wrote:
On Tue, 08 Mar 2016 13:52:09 +, Martin Tschierschke wrote:
What about this idea? A new word "as" or something similar.
fun(ypos as y, xpos as x, radius as r); // different order!
The syntax isn't an issue.
There was one DIP
On Wednesday, 9 March 2016 at 07:30:31 UTC, Edwin van Leeuwen
wrote:
I also added a merge function that will return a tuple
containing merged named tuples:
Tuple!(double,"x",string,"colour")(-1,
"black").merge(Tuple!(double,"x")(0.0))
returns:
Tuple!(double,"x",string,"colour")(0, "black");
On Sunday, 6 March 2016 at 17:35:38 UTC, Seb wrote:
Hey all,
Using structs is not ideal, because one can't require
parameters, but this can be solved by having those parameters
as normal ones like `sliced(4, {allowDownsize: true})` and it
creates some maybe unnecessary overhead.
However it
On Sunday, 6 March 2016 at 17:35:38 UTC, Seb wrote:
Hey all,
I wanted to relive the discussion on named arguments and ping
for its current status.
There is a bunch of examples to show how needed a unified
solution for this problem is, let me give you one from phobos
[2].
```
// I want to
On Tue, 08 Mar 2016 13:52:09 +, Martin Tschierschke wrote:
> What about this idea? A new word "as" or something similar.
> fun(ypos as y, xpos as x, radius as r); // different order!
The syntax isn't an issue.
There was one DIP about named parameters, but it was unpopular. It didn't
change
hi, has the UDA syntax been proposed already?
void fun(int foo, int bar, int bazDaz = 0){}
fun(10, 30, 50); // normal
fun(10, 30); normal with default
fun(10, 30, @bazDaz 50); // mixed
fun(@bazDaz 50, 10, 30) // mixed and reordered
fun(@bar 30, 10); // mixed, reordered and default
fun(@foo
On Sunday, 6 March 2016 at 17:35:38 UTC, Seb wrote:
Hey all,
I wanted to relive the discussion on named arguments and ping
for its current status.
There is a bunch of examples to show how needed a unified
solution for this problem is, let me give you one from phobos
[2].
```
// I want to
On Monday, 7 March 2016 at 18:21:24 UTC, Meta wrote:
On Monday, 7 March 2016 at 10:40:15 UTC, ZombineDev wrote:
Which I don't think will cause ambiguity with delegates:
auto tuple3 = { getInt() }; tuple
auto tuple3 = { getInt(); }; lambda
Unfortunately this will not work. There was a tuple
On Mon, 07 Mar 2016 11:06:13 +, ZombineDev wrote:
> The compiler should detect that this call is ambiguous and would not
> allow it.
It's a potentially significant amount of work to determine that the
expression is ambiguous, or to disambiguate.
> To resolve the ambiguity, the user can
On Monday, 7 March 2016 at 10:40:15 UTC, ZombineDev wrote:
Which I don't think will cause ambiguity with delegates:
auto tuple3 = { getInt() }; tuple
auto tuple3 = { getInt(); }; lambda
Unfortunately this will not work. There was a tuple proposal
sometime back in 2012 or 2013. I can't
On Sunday, 6 March 2016 at 19:10:50 UTC, Chris Wright wrote:
On Sun, 06 Mar 2016 17:35:38 +, Seb wrote:
[...]
We want something to let people provide arguments sparsely and
unambiguously, and if possible in arbitrary order. The existing
DIP just lets you provide compiler-checked
On Sunday, 6 March 2016 at 20:35:49 UTC, Jacob Carlborg wrote:
On 2016-03-06 18:35, Seb wrote:
Hey all,
I wanted to relive the discussion on named arguments and ping
for its
current status.
There is a bunch of examples to show how needed a unified
solution for
this problem is, let me give
On 2016-03-06 18:35, Seb wrote:
Hey all,
I wanted to relive the discussion on named arguments and ping for its
current status.
There is a bunch of examples to show how needed a unified solution for
this problem is, let me give you one from phobos [2].
```
// I want to allow downsizing
On Sun, 06 Mar 2016 17:35:38 +, Seb wrote:
> Hey all,
>
> I wanted to relive the discussion on named arguments and ping for its
> current status.
We want something to let people provide arguments sparsely and
unambiguously, and if possible in arbitrary order. The existing DIP just
lets
Hey all,
I wanted to relive the discussion on named arguments and ping for
its current status.
There is a bunch of examples to show how needed a unified
solution for this problem is, let me give you one from phobos [2].
```
// I want to allow downsizing
30 matches
Mail list logo
