Skip to content

[QUESTION] Is there any difference between 10 as int and :int = 10? #306

New issue

Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? # to your account

Closed
msadeqhe opened this issue Mar 29, 2023 · 15 comments
Closed

[QUESTION] Is there any difference between 10 as int and :int = 10? #306

msadeqhe opened this issue Mar 29, 2023 · 15 comments

Comments

@msadeqhe
Copy link

msadeqhe commented Mar 29, 2023

The following as and :type examples do the same thing:

#include <optional>

main :() = {
    number := 10;

    x1 := (number as int);
    y1 := (:int = number);

    x2 := (number as int as long);
    y2 := (:long = :int = number);

    x3 := (number as std::optional<int>);
    y3 := (:std::optional<int> = number);
}

I'm thinking can we consider they are the same but in different syntaxes?

@filipsajdak
Copy link
Contributor

number as int is casting number to int.

:int = number is creating anonymous int and initializes it with the number value.

It is just a matter of your intentions. In general, the syntax is as follows:

{name}: {type} = {value};
  1. You can skip the {name} (: {type} = {value};) and create anonymous {value} of {type} aka temporary variable.
  2. You can skip the {value} ({name}: {type};) and create the uninitialized variable.
  3. You can skip the {type} ({name}:= {value};) and create a variable with deduced type.

You cannot mix the above points - you can skip only one part at a time. And this syntax works everywhere (one of the goals of cppfront: is to have context-free syntax).

The cool thing I have discovered in the past is:

@JohelEGP
Copy link
Contributor

Maybe not for those types. :type = value probably compiles to some form of direct-initialization. But as can do more than that. See https://wg21.link/P2392 §2.2.

@AbhinavK00
Copy link

Question: What is the preferred way of declaring variables out of these two ways?

number1 := 10 as u64;
number2 : u64 = 10;

or for contructor calls

vec1 := (1,2) as std::vector;
vec2 : std::vector = (1,2);

Which is the preferred and faster (if any) way?

Plus, how do I create a vector of N elements with each value k? Can't figure that out

@JohelEGP
Copy link
Contributor

Which is the preferred and faster (if any) way?

If as performs a direct-initialization, like T(v), they should be the same. If the target type is something more complicated, like a reference type, as might do something else (check the linked proposal).

Plus, how do I create a vector of N elements with each value k? Can't figure that out

I think this was discussed at #193.

@filipsajdak
Copy link
Contributor

I cannot check it now but I think that

vec1 := (1,2) as std::vector;

Might not compile.

@AbhinavK00
Copy link

I think this was discussed at #193.

Seems like no real solution was reached. This kind of problem would've been easily solved by named contructors as described in the parameter passing paper. But here's one solution I want to propose from one of the options Herb describes in issue #193:

Use [ ] for lists

Herb says that the problem with this is that it is difficult to distinguish it from subscript operator, so we can try this:

arr := [,1,2,3,4];

An extra comma at the start!
This would be easily distinguishable and would probably work fine.
I also proposed for an inbuilt better-behaved array type in cpp2 in #286 (there's inbuilt tuples too, give feedback pls) so that these types could default to inbuilt cpp2 array. On cpp1 side, we can have a function to cast these 'cpp2 arrays' into initialiser lists whenever required.

@filipsajdak
Copy link
Contributor

@AbhinavK00 in the Suggestion template @hsutter emphasise:

Please do not suggest syntax changes. I accept there are hundreds of opinions and everyone will prefer something a little different. Syntax isn't the big thing, fixing semantics is -- reducing concept count, increasing toolability, are the big payoff.

I am not against it but please don't expect them to be included as it is not supporting Herb goals.

@AbhinavK00
Copy link

I'm sorry but they're actual features not just syntax change. I'm trying a way to do away with initialiser lists, can't think of a full proposal so I just suggest small changes.

@JohelEGP
Copy link
Contributor

Plus, how do I create a vector of N elements with each value k? Can't figure that out

std::vector(N, k), which has the same meaning as in C++1. See #193 (comment).

@filipsajdak
Copy link
Contributor

Do we have initializer lists in cpp2?

@JohelEGP
Copy link
Contributor

We have parentheses. With Cpp2 initialization, it compiles down to a braced-init-list.

std::vector(N, k) is an usual C++1 expression, so it's left alone, and calls a non-std::initializer_list constructor.

@AbhinavK00
Copy link

std::vector(N, k), which has the same meaning as in C++1.

Yea, but it's the cpp1 way. Cpp2 way would be something like

y : std::vector = SOMETHING;

That's how we do it with classes in cpp2, the only one and right way.

@JohelEGP
Copy link
Contributor

std::vector(2, 3) != (: std::vector = (2, 3)), the former is $(2, 2, 2)$ or $(3, 3)$, and the latter is $(2, 3)$.

@msadeqhe
Copy link
Author

Maybe not for those types. :type = value probably compiles to some form of direct-initialization. But as can do more than that. See https://wg21.link/P2392 §2.2.

So in a nutshell, as is for pattern matching and dynamic cast in addition to static cast similarity with :type = variable, right?

@msadeqhe
Copy link
Author

number as int is casting number to int.

:int = number is creating anonymous int and initializes it with the number value.

It is just a matter of your intentions.

Therefore the result of both is the same but in different approaches for static casting.

@hsutter hsutter closed this as completed Apr 1, 2023
# for free to join this conversation on GitHub. Already have an account? # to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants