App.create_window() to accept any Into<String> type (fix #2290)

[chippers]

What kind of change does this PR introduce? (check at least one)

• Bugfix
• Feature
• Docs
• New Binding Issue #___
• Code style update
• Refactor
• Build-related changes
• Other, please describe:

Does this PR introduce a breaking change? (check one)

• Yes. Issue [Feature request] Make App.create_window() accept any Into<String> type for the label #2290
• No

The PR fulfills these requirements:

• When resolving a specific issue, it's referenced in the PR's title (e.g. fix: #xxx[,#xxx], where "xxx" is the issue number)
• A change file is added if any packages will require a version bump due to this PR per the instructions in the readme.

If adding a new feature, the PR's description includes:

• A convincing reason for adding this feature (to avoid wasting your time, it's best to open a suggestion issue first and wait for approval before working on it)

Other information:
See #2290.

[woubuc]

I've updated the changefile to reflect both changed functions, like @chippers suggested in #2290.

I do want to note that this may be considered a breaking change (which is why I marked it as 'major' in the changefile). Especially because @chippers said this isn't a major change and I don't entirely agree. (I was going to comment in the issue but I feel it's more appropriate to continue this conversation here in the PR).

One thing to be changed is the changefile level, this should be a patch not major change

Because while the type is technically backwards-compatible (since String is also Into<String>), in practice most developers who use this function will need to update their code.

The current create_window() function takes a String for the label. So when a developer uses that function to create a window, they'll do something like this:

app.create_window("my_label".into(), [...]);

Note the .into(). This is also how it's done in the example.

With this PR, create_window() accepts any Into<String> type for the label, so developers will be able to just do this:

app.create_window("my_label", [...]);

However, when trying to use the original code with .into() after applying this change, you get the following error:

error[E0283]: type annotations needed
  --> examples\api\src-tauri\src\main.rs:84:14
   |
84 |             .create_window(
   |              ^^^^^^^^^^^^^ cannot infer type for type parameter `impl Into<String>` declared on the associated function `create_window`
85 |               "new".into(),
   |               ------------ this method call resolves to `T`
   |
   = note: cannot satisfy `_: Into<std::string::String>`

So because the impl Into<String> type doesn't point to a concrete type, .into() can't determine what type to convert the value into. This means that most (if not all) developers who use this function will be presented with these errors when they upgrade their Tauri version and they'll have to fix them to get their app to compile. Theoretically the function still accepts the same type as before and this PR just expands the accepted types a bit, but I would in fact consider this a major change because it will break code.

If you don't consider this a breaking change, let me know and I'll bring the changefile down to a patch level.

[chippers]

I've updated the changefile to reflect both changed functions, like @chippers suggested in #2290.

I do want to note that this may be considered a breaking change (which is why I marked it as 'major' in the changefile). Especially because @chippers said this isn't a major change and I don't entirely agree. (I was going to comment in the issue but I feel it's more appropriate to continue this conversation here in the PR).

One thing to be changed is the changefile level, this should be a patch not major change

Because while the type is technically backwards-compatible (since String is also Into<String>), in practice most developers who use this function will need to update their code.

The current create_window() function takes a String for the label. So when a developer uses that function to create a window, they'll do something like this:

app.create_window("my_label".into(), [...]);

Note the .into(). This is also how it's done in the example.

With this PR, create_window() accepts any Into<String> type for the label, so developers will be able to just do this:

app.create_window("my_label", [...]);

However, when trying to use the original code with .into() after applying this change, you get the following error:

error[E0283]: type annotations needed
  --> examples\api\src-tauri\src\main.rs:84:14
   |
84 |             .create_window(
   |              ^^^^^^^^^^^^^ cannot infer type for type parameter `impl Into<String>` declared on the associated function `create_window`
85 |               "new".into(),
   |               ------------ this method call resolves to `T`
   |
   = note: cannot satisfy `_: Into<std::string::String>`

So because the impl Into<String> type doesn't point to a concrete type, .into() can't determine what type to convert the value into. This means that most (if not all) developers who use this function will be presented with these errors when they upgrade their Tauri version and they'll have to fix them to get their app to compile. Theoretically the function still accepts the same type as before and this PR just expands the accepted types a bit, but I would in fact consider this a major change because it will break code.

If you don't consider this a breaking change, let me know and I'll bring the changefile down to a patch level.

This is a fair point, but we are kind of abusing the patch level while we are in beta. A recent change that also did this is the Params removal which had a similar resolution of just removing unnecessary code. We are still pre-audit for a short amount of time, so necessary breaking changes that align with a stable future API are still currently marked patch.

Good point about the breaking change however, and I'll update the PR original comment to specify it

[woubuc]

I've updated the changefile to patch level.