On Friday, 28 October 2016 at 11:53:16 UTC, Nick Treleaven wrote:
In the unittest, using with(Color) should help, but I couldn't
get that to compile (visit thinks invalid lambdas are being
passed).
https://issues.dlang.org/show_bug.cgi?id=16655
Someone may be, it will be interesting, in the C# 7 `switch` will
be extended syntax for pattern matching:
https://github.com/dotnet/roslyn/blob/features/patterns/docs/features/patterns.md
Original post:
https://github.com/dotnet/roslyn/issues/206
On Monday, 24 October 2016 at 04:14:52 UTC, Nick Sabalausky wrote:
It's just...I mean, yea, it works, and you could probably DRY
it up a little with a type contructing template ("alias
RgbColor = DoMagic!RgbColor_"), but...meh...
I think the following should be better. Instead of Proxy we
On 10/23/2016 11:55 PM, Nick Sabalausky wrote:
// An equivalent std.variant.Algebraic would be clunky by comparison:
variant RgbColor {
| Red
| Yellow
| Green
| Different {
red : float;
green : float;
blue : float;
On 10/23/2016 03:38 PM, Chris M wrote:
On Friday, 21 October 2016 at 19:00:55 UTC, Nick Sabalausky wrote:
What I've been really wanting for a long time is the one-two combo of
Nemerle's variants and pattern matching:
https://github.com/rsdn/nemerle/wiki/Grok-Variants-and-matching
There is
On Friday, 21 October 2016 at 19:00:55 UTC, Nick Sabalausky wrote:
On 10/20/2016 10:16 PM, Chris M. wrote:
So I know you can do some pattern matching with templates in
D, but has
there been any discussion about implementing it as a language
feature,
maybe something similar to Rust's match
On 10/20/2016 10:16 PM, Chris M. wrote:
So I know you can do some pattern matching with templates in D, but has
there been any discussion about implementing it as a language feature,
maybe something similar to Rust's match keyword
(https://doc.rust-lang.org/stable/book/patterns.html)? What would
On Friday, 21 October 2016 at 12:17:30 UTC, default0 wrote:
Unless you find a way to convince Walter and Andrei that its
not gonna result in everyone defining their own sub-language
within D, making D code harder to read for others and/or have
good reasons for things they enable that currently
On Friday, 21 October 2016 at 11:49:42 UTC, Mark wrote:
On Friday, 21 October 2016 at 06:50:26 UTC, Dennis Ritchie
wrote:
Previously, there were ideas on the implementation of macros
in D, but now they are no longer relevant:
http://s3.amazonaws.com/dconf2007/WalterAndrei.pdf
AST macros are
On Friday, 21 October 2016 at 06:50:26 UTC, Dennis Ritchie wrote:
Previously, there were ideas on the implementation of macros in
D, but now they are no longer relevant:
http://s3.amazonaws.com/dconf2007/WalterAndrei.pdf
AST macros are permanently off the table?
On Friday, 21 October 2016 at 02:40:45 UTC, Stefan Koch wrote:
On Friday, 21 October 2016 at 02:16:44 UTC, Chris M. wrote:
So I know you can do some pattern matching with templates in
D, but has there been any discussion about implementing it as
a language feature, maybe something similar to
On Friday, 21 October 2016 at 06:50:26 UTC, Dennis Ritchie wrote:
The problem is that D is not macros, and the implementation of
pattern matching without macros will not be very good. In turn,
the implementation of macros in D - this is also not a good
idea.
Agreed. D has not macro, this
On Friday, 21 October 2016 at 02:16:44 UTC, Chris M. wrote:
So I know you can do some pattern matching with templates in D,
but has there been any discussion about implementing it as a
language feature, maybe something similar to Rust's match
keyword
So I know you can do some pattern matching with templates in D,
but has there been any discussion about implementing it as a
language feature, maybe something similar to Rust's match keyword
(https://doc.rust-lang.org/stable/book/patterns.html)? What would
your guys' thoughts be?
On Friday, 21 October 2016 at 02:16:44 UTC, Chris M. wrote:
So I know you can do some pattern matching with templates in D,
but has there been any discussion about implementing it as a
language feature, maybe something similar to Rust's match
keyword
On Friday, 21 October 2016 at 02:40:45 UTC, Stefan Koch wrote:
On Friday, 21 October 2016 at 02:16:44 UTC, Chris M. wrote:
So I know you can do some pattern matching with templates in
D, but has there been any discussion about implementing it as
a language feature, maybe something similar to
On Friday, 21 October 2016 at 02:40:45 UTC, Stefan Koch wrote:
How is this diffrent from "switch-case" ?
A more laconic and convenient form of the recording conditions:
* No need to constantly write "case", "break", "case", "break",
...
* You can use the "|", it facilitates the matching also
On 6/5/15 10:15 AM, Dennis Ritchie wrote:
On Friday, 5 June 2015 at 13:13:15 UTC, Steven Schveighoffer wrote:
string foo(string mode, string value)
{
return `writefln(mode ` ~ mode ~ `: %s, ` ~ value ~ `);`;
}
void main()
{
mixin(foo(Y, 3));
mixin(foo(X, 2));
}
Thanks. It looks
Sun, 07 Mar 2010 22:05:19 -0800, Walter Bright wrote:
BCS wrote:
I think what retard was asking was what types are legal as the argument
for a switch?
IIRC the list is: all the arithmetic types and the string types.
The value pattern matching that is being asked for would allow just
retard wrote:
I've thought more than once about adding that, but it just seems
pointless. I've never run into a use case for it. If you do run into
one,
if (ar == [1,2,3]) ...
else if (ar == [1,2,4]) ...
else if (ar == [1,3,2]) ...
will work just fine.
The same can be said
Mon, 08 Mar 2010 03:35:56 -0800, Walter Bright wrote:
retard wrote:
I've thought more than once about adding that, but it just seems
pointless. I've never run into a use case for it. If you do run into
one,
if (ar == [1,2,3]) ...
else if (ar == [1,2,4]) ...
else if (ar ==
Walter Bright newshou...@digitalmars.com wrote:
foo match {
case b: Bar = b.doBarMethod
case b: Bar2 = b.doBar2Method
case _ = println(Oh no!)
}
(1, (1,2)) match {
case (1, (1, _)) = println(nice tuple)
case _ =
}
def main(args: Array[Byte]) =
args(0) match {
case -help =
Hello Walter,
(Note: switching on floating point values is worse than useless, as
floating point computations rarely produce exact results, and
supporting such a capability will give a false sense that it should
work.)
What about allowing switch on FP but only allowing CaseRangeStatements?
BCS wrote:
What about allowing switch on FP but only allowing CaseRangeStatements?
Is there really a compelling use case for that?
I really think we need to focus on what is needed to be done, not what
can be done. Otherwise we wind up with a huge boatload of features yet
have an unuseful
retard wrote:
Sun, 07 Mar 2010 11:17:46 -0800, Walter Bright wrote:
retard wrote:
- Pattern matching (extension to enum/string/integer accepting switch)
Andrei and Sean have shown how to do that nicely with existing language
features.
Really? I'd really like to see how this is done.
Hello Walter,
retard wrote:
Sun, 07 Mar 2010 11:17:46 -0800, Walter Bright wrote:
retard wrote:
- Pattern matching (extension to enum/string/integer accepting
switch)
Andrei and Sean have shown how to do that nicely with existing
language features.
Really? I'd really like to see how
BCS wrote:
I think (from context in other strands) that the OP was referring to
value, not type, pattern matching.
Value pattern matching is just a regular switch statement.
Sun, 07 Mar 2010 15:38:07 -0800, Walter Bright wrote:
retard wrote:
Sun, 07 Mar 2010 11:17:46 -0800, Walter Bright wrote:
retard wrote:
- Pattern matching (extension to enum/string/integer accepting
switch)
Andrei and Sean have shown how to do that nicely with existing
language features.
Sun, 07 Mar 2010 15:59:37 -0800, Walter Bright wrote:
BCS wrote:
I think (from context in other strands) that the OP was referring to
value, not type, pattern matching.
Value pattern matching is just a regular switch statement.
So what types does the regular switch accept in D 2 ?
retard:
So what types does the regular switch accept in D 2 ?
It accepts all integral values, including all chars and true enums. It accepts
strings but not arrays.
It doesn't accept floating point values, complex numbers (that are FP),
structs, objects and associative arrays.
Eventually
retard wrote:
Sun, 07 Mar 2010 15:59:37 -0800, Walter Bright wrote:
BCS wrote:
I think (from context in other strands) that the OP was referring to
value, not type, pattern matching.
Value pattern matching is just a regular switch statement.
So what types does the regular switch accept in
retard wrote:
The matching is all done at compile time, of course, and the delegate
can be inlined.
I guess this tells a lot. No feature is added to D unless it can do
something statically with zero runtime cost.
You did mention in another post in this thread that you were concerned
about
Hello Walter,
retard wrote:
Sun, 07 Mar 2010 15:59:37 -0800, Walter Bright wrote:
BCS wrote:
I think (from context in other strands) that the OP was referring
to value, not type, pattern matching.
Value pattern matching is just a regular switch statement.
So what types does the
BCS wrote:
I think what retard was asking was what types are legal as the argument
for a switch?
IIRC the list is: all the arithmetic types and the string types.
The value pattern matching that is being asked for would allow just
about anything that has a compile time literal syntax:
void
34 matches
Mail list logo
